not operator (anything but)

[Mouvedia]

tl;dr:

(param: Any) => not String
// shorthand
(param: Any) => !String

// union case
(param: Any) => not(String | Array)
// short hand
(param: Any) => !(String | Array)

Sometimes it's way easier and convenient to define the type by discarding one or several.
There's also the possibility to define it as a substraction—e.g. Any - String—but that would not be very conventional.

TypeScript approaches

• substraction: Subtraction types microsoft/TypeScript#4183
• exclude: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#predefined-conditional-types
• negation: Allow negated types + F-bounded mapped types microsoft/TypeScript#18280

[ericelliott]

I like it.

[Mouvedia]

After thinking about it I think that introducing a new keyword is not a good idea: we should be as JS compatible as possible. It's not ruby after all. Ill do a PR if I find an acceptable title for the chapter.

Still Iv got a problem:

// if & is introduced
!(A | B)
// could be expanded to
!A | !B
// which is not
!A & !B

Ill have to poke #132 in this PR.

[ericelliott]

After thinking about it I think that introducing a new keyword is not a good idea: we should be as JS compatible as possible. It's not ruby after all.

I'm not sure what you mean by this. JavaScript has a logical ! operator which behaves similarly.

// if & is introduced
!(A | B)
// could be expanded to
!A | !B
// which is not
!A & !B

I don't see this as a problem, as long as it is well documented.

[ericelliott]

My biggest problem with this proposal is that ! type declarations can't be future-compatible. Because they blacklist instead of whitelist types, newly introduced types may be considered acceptable by the type system, even if they're not acceptable types in practice.

[Mouvedia]

I'm not sure what you mean by this.

I was talking about not.

I don't see this as a problem, as long as it is well documented.

Do you have an example in mind?

[Mouvedia]

newly introduced types may be considered acceptable by the type system, even if they're not acceptable types in practice

That's to be expected. Let's say you had !Array before typed arrays were introduced and it doesn't cover Int16Array, I wouldn't blame rtype. The type will have to be updated to !Array & !TypedArray; it's such a rare occurence that I don't mind.