This (and similar for the overloads below) is needed because null and undefined are allowed and ignored by Object.assign, but the compiler should not infer U as null if null is passed in, as the result T & null is meaningless.

Should I add a comment to that effect?

Actually, on closer look it seems U is still specialized as null instead of {}. But also the resulting type T & null doesn't seem to have any issues either.

Should I remove the | null | undefined from this function?

T & null and T & undefined should not be a problem, because null and undefined add no new member to the type? In fact, I think the type system could (should?) simplify T & null & undefined to just T.

If it were T | null that would be a real problem.

BTW I don't think Object.assign is "meant" to explicitely accept undefined. It reflects the fact the the parameter is optional and that should probably be modelled with assign<T>(target: T): T, so that you can call assign(x); or maybe assign<T, U>(target: T, source?: U).

Note that removing null and undefined from being explicit in the signature doesn't change the fact that assign(x, null) is still valid.

Of course the right thing to do here would be variadics (2.1) since the real signature is assign<T, ...U>(target: T, ...source: ...U): T & ...U.

T & null and T & undefined should not be a problem, because null and undefined add no new member to the type?

Yes, it appears so, but...

In fact, I think the type system could (should?) simplify T & null & undefined to just T.

It doesn't, hence my initial concern that this would be problematic. But it seems to be fine regardless, in that the instances of T & null appear to be usable as T everywhere. I'm waiting for the TS team to confirm / deny if this is expected behavior or a bug.

BTW I don't think Object.assign is "meant" to explicitely accept undefined.

Yes, this is what I thought as well. I'm not familiar with all of assign's uses, so if it's not expected that users will want to use it with null / undefined sources then it would be nice to have a way to specify that U can't be null. Perhaps U extends {} ? I'm not in front of tsc to try at the moment.

Since this is brand new stuff, maybe @ahejlsberg should add a reduction rule from T | null | undefined to T... that may simplify a few other places where this might come up?

do not think this is the correct change here. the current signature declaration is better. i think what you want is a type operator like the expression operator ! (which does not exist) on the return type to indicate that null and undefined are ignored. e.g. assign<T, U>(target: T, source: U): T! & U!;

Reverted.

predicate is incorrect, it should be the same as for find().
See https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/TypedArray/findIndex

Indeed.

@Arnavion feel free to send a separate PR for the predicate changes.

@mhegazy And should I move the other commits after the first one into a separate PR as well?

On a second thought, the commit messages look clear enough, so feel free to include the findIndex chances in this PR if you like or have it in a separate one. up to you.

I've removed them from this PR. Will make another one.

I don't think there is a guarantee that compile returns your subclass if you subclass RegExp, so it should return plain RegExp instead.

According to ES specs it should return the this value of the compile() call.
So using this type here seems like the correct thing to do.

BTW: this method is deprecated so hopefully it won't matter much.

Concur 👍