Looking forward to trying out with the fix - not sure if I'm allowed to do this as a non-contributor but:

@typescript-bot pack this.

@typescript-bot pack this

Heya @orta, I've started to run the tarball bundle task on this PR at d69f2b0. You can monitor the build here.

Hey @orta, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/84753/artifacts?artifactName=tgz&fileId=458CBB664D3CE9EFA165B438F01414D55349C27455F3F7CE2CC288A173FC410B02&fileName=/typescript-4.1.0-insiders.20200910.tgz"
    }
}

and then running npm install.

There is also a playground for this build.

Idea: Find a way to "match" the error string into the typescript diagnostic object, to reuse the translation of diagnostic message.

A possible solution:

throw {diagnostic: "Did_you_mean_0", args: [T] }

That will match the Diagnostic.Did_you_mean_0 and therefore it will be automatically translated by the compiler.

Idea: Find a way to emit other kinds of diagnostic, like suggestions or warning. If so, there should be another mechanism to offer a underlying type like

throw {message: T, type: T2, kind: "suggestion"}

Oh I just realized we can throw a object type so it can include more details! Please help me to investigate the possibility of this to find a good shape of the error object.

Possible properties:

• underlying type (what should this throw type resolve to)
• diagnosis level (error, suggestions, warning, deprecation)
• reference to typescript built in diagnosis message to provide translated message
• provide refactor suggestions

Idea: Allow throw type to be handled by conditional type. This allows some error recovery or composing multiple errors.

T extends throw infer E1 ?
    U extends throw infer E2 ?
        throw `\n    ${E1}\n    ${E2}`
    : T : never

Idea: Find a way to "match" the error string into the typescript diagnostic object, to reuse the translation of diagnostic message.

A possible solution:

throw {diagnostic: "Did_you_mean_0", args: [T] }

That will match the Diagnostic.Did_you_mean_0 and therefore it will be automatically translated by the compiler.

Idea: Find a way to emit other kinds of diagnostic, like suggestions or warning. If so, there should be another mechanism to offer a underlying type like

throw {message: T, type: T2, kind: "suggestion"}

To be honest the initial idea is great - but adding diagnostics types and formatting feels like an overkill. It might even step into the linters world. The syntax is more complex too. I think having the ability to throw is already great as is.

The syntax is more complex too.

Hmm, I didn't introduce a new syntax for a "detailed" throw. It's a plain object literal type. I need some advice from the TypeScript team. If they think it's no need to do this, I'll stop working on that feature sets and focus on what will be accepted.

Now I still have two complex ideas:

• Detailed throw (throw { ... }) (#40468 (comment))
• Conditional type support (#40468 (comment))

Is there anything I mentioned above that the TS team doesn't want? cc @RyanCavanaugh @orta @Kingwl

Just as a data point - this PR makes my expect-type library for writing type-level assertions considerably better. The implementation no longer depends on rest-parameter hacks, and the error messages are much more useful.

Error messages before:

Error messages after:

Re being able to use diagnostic objects, I'm inclined to agree with @Harpush - plain string messages being supported is a must-have, but supporting complex objects, probably needs more design and consideration, and are more of a nice-to-have. I'd expect trying to include them from the get-go will make it harder for this PR to be accepted - so purely selfishly, as someone who wants to use some form of this feature ASAP, my two cents: complex diagnostic object support should be split out into another PR.

Thanks! I have already paused my work on the complex diagnostic messages and waiting for the TS team language meeting to decide.
Now currently I'm focusing on improving the basic throw string case. If they don't want the complex diagnostic feature I'll remove them later.

Should this work?

type MustNumber<T> = T extends number ? T : throw `"Expected, but found "${typeof T}"`
type MustNumber2<T> = T extends number ? T : throw `"Expected, but found "${typeof T}"`

function foo<T>(x: MustNumber<T>, y: MustNumber2<T>) {
    x = y; // error now
}

Playground

hi, @jack-williams the playground has been outdated. The latest error message is on x in x = y saying:

Type 'MustNumber2<T>' is not assignable to type 'MustNumber<T>'.
  Type 'T | never' is not assignable to type 'MustNumber<T>'.
    Type 'number & T' is not assignable to type 'MustNumber<T>'.
      Type 'never' is not assignable to type 'never'. Two different types with this name exist, but they are unrelated.ts(2322)

I'll try to handle this later Fixed. @orta Hi, can you let the bot to re-pack the latest commit?

Can somebody pack this again please? And also could it be possible that printing unions is not possible?

Also I try to type a database migration using the following code:

let a = {
    posts: {
        content: {

        },
        name: {}
    }
}

let b = {
    posts: {
        content: {
            
        },
        namfe: {}
    }
}

type SafeMerge<A, B> =
{
    [K in Exclude<keyof A, keyof B>]: A[K]
}
&
{
    [K in Exclude<keyof B, keyof A>]: B[K]
}
&
{
    [K in keyof A & keyof B]: 
        keyof A[K] & keyof B[K] extends never ?
        {
            [K1 in keyof A[K]]: A[K][K1]
        }
        &
        {
            [K1 in keyof B[K]]: B[K][K1]
        }
        : throw `the following additions contain already existing columns: ${K}.${typeof B[K]}}`
}

let fdsfione: SafeMerge<typeof a, typeof b> = null as any

fdsfione.posts

In this case a nonlazy error would be useful. Do you have another solution and if not would you be interested in implementing this? Or do you think it's not worth it for such special usages?

Hi @mohe2015, since this is a type-level operation, I think I have no idea about how to handle union cause it is representing "one of" those errors. Maybe intersections can be represented as multiple errors.

Your latter example does work on the latest commit, error on fdsfione.posts says:

Type instantiated results in a throw type saying: 
    the following additions contain already existing columns: posts.{ content: {}; namfe: {}; }}
ts(2794)

Oh do you mean it should error on let fdsfione? I'll investigate it later

@Jack-Works thanks for the fast reply. My initial idea was to do

throw `the following additions contain already existing columns: ${K}.${keyof A[K] & keyof B[K]}`

which would produce a really nice error message if only one column is duplicate. But it fails for multiple ones. The problem with the current solution (in my last comment) is that it also shows unrelated objects that aren't duplicates and also shows all children which are unrelated to the problem.

Regarding the second part - yes I would love if it could error on let fdsfione although there may be completely different solutions to my problem I don't know of.

@typescript-bot pack this

Heya @orta, I've started to run the tarball bundle task on this PR at 56bfcd7. You can monitor the build here.

Hey @orta, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/85710/artifacts?artifactName=tgz&fileId=08A5EC3BE4780859520BB416BFE0B51DDB7C552F415DA933BD0766A1E2060B9E02&fileName=/typescript-4.1.0-insiders.20200917.tgz"
    }
}

and then running npm install.

There is also a playground for this build.

@mohe2015 I have re-investigate your case, it is by design. Because your throw type is on the object property, the SafeMerge itself never returns a throw type. So, it will only throw when you access the property that is marked as to throw type. And also, declaration of throw type doesn't make the declaration itself invalid. It makes all access to it invalid.

I have improved the intersection case. Any (throw T) & U will be eliminated to throw T (the first throw type in the intersection).

@Jack-Works In the case of this example playground,

Type 'MustNumber2<T>' is not assignable to type 'MustNumber<T>'.

my concern was not with the error message, but rather that I think it is wrong that two identical types are not assignable to each other.

@jack-williams Now currently I didn't handle the assignability of throw types, which means they behave like unique symbol, every throw type is not assignable to each other even they containing the same error message. I don't know if throw type should be structural type checked.

Merged with master, due to #40580, now the typeof T string modifier (not type operator!) has been removed. Maybe I'll add it back as an new intrinsic string mapping type later?

#40779

Hi, I have read the meeting note! I have something to reply to and question about.

• Issue: "if it ever gets evaluated" leaks implementation details of instantiation.
  • Our type system's instantiation semantics aren't strictly evaluated, but it's not always lazily evaluated either!
    • Basically non-strict is the best you can say.
  • Lots of places where instantiation can also be surprising (e.g. looking at constraints).

My early implementation does work on type instantiation, but I really found some problems (type get instantiation at the position I don't want to throw errors). The current implementation is case-by-case to raise errors on the evaluated type (for example, PropertyAccess, Identifier access, a function call, ...etc).

• Two potential directions of "signaling never" and signaling "anti-any".

I don't understand what is "anti-`any`". But the type currently work in this way: it is printed as "never" (but actually not so it is not compatible with never.). It behaves like unique symbol cause I don't know how they should be compared about.

Question:

• Does the team discussion about the complex throw type? (Partly implemented now #40468 (comment)) Should I complete this or revert this?
• Should throw type supports conditional types and infer?
• What should I change next?

@DanielRosenwasser

@typescript-bot pack this

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at cdd5cd0. You can monitor the build here.

It behaves like unique symbol cause I don't know how they should be compared about.

This is close to what we meant by "anti-any" - that it is a type that is assignable to/from nothing else.

Does the team discussion about the complex throw type?

We do like the idea about signaling a reason. It's kind of strange that this isn't localizable, but it's reasonable given that the code itself is written with some language in mind.

Should throw type supports conditional types and infer?

I'm not necessarily sure, do you mean being able to throw conditionals? Or support conditionals in a way that special-cases throw? I think that the case-by-case nature that you mentioned is something we're a little bit wary of. But it wouldn't be the first time we've added special cases in every type operation. @ahejlsberg might have thoughts here.

What should I change next?

I would hold off on any changes - we're not necessarily sure this is something we want in the language. If you're doing this mostly for the sake of experimentation, then it's really up to you.

I'm not necessarily sure, do you mean being able to throw conditionals?

I'm meaning the ability of type MessageOfThrowType<T> = T extends throw infer T ? T : ''

I would hold off on any changes - we're not necessarily sure this is something we want in the language. If you're doing this mostly for the sake of experimentation, then it's really up to you.

😢 I'd really like to have this in the language, not an experimental forever, hope I can get a clear thought on how the TS team wants and let it get merged in future

Just wanted to share my temporary solution based on anti-any pattern:

invalid.ts

const TypeErrorTag: unique symbol = Symbol('TypeErrorTag'); // don't export it!

export type invalid<Message> = {
  [x in keyof Message | typeof TypeErrorTag]: x extends keyof Message
    ? Message[x & keyof Message]
    : { readonly [TypeErrorTag]: unique symbol }; // anonymous unique symbol
};

extend.ts

How to use it in hypothetical extend library (usage example)

import { invalid } from './invalid';

export type Extend<
  Base extends object | null,
  Key extends string | number | symbol,
  Value
> = { [K in Exclude<keyof Base, Key>]: Base[K] } &
  {
    [K in Key]: Value extends Base[Key & keyof Base]
      ? Value
      : Base[Key & keyof Base] extends never
      ? Value
      : invalid<{
          message: 'Incorrectly overridden';
          key: Key;
          originalType: Base[Key & keyof Base];
          newType: Value;
        }>;
  };

export function extend<
  Base extends object | null,
  Key extends string | number | symbol,
  Value
>(base: Base, key: Key, value: Value): Extend<Base, Key, Value> {
  return Object.create(base, {
    [key]: { value, enumerable: true }
  });
}

Usage

What gets a final user when uses a library written with help of invalid<Message> type:

import { extend } from './extend';

const a = extend(null, "x", 10);           //   typeof a === {x: number}        
const b = extend(a, "y", true);            //   typeof b === {x: number, y: boolean}
const c = extend(b, "z", "Hello");         //   typeof c === {x: number, y: boolean, z: string}
const d = extend(c, "y", false as const);  //   typeof d === {x: number, y: false, z: string }
const e = extend(d, "z", 123);             //   typeof e === {x: number, y: false, z: {
                                           //        [TypeErrorTag]: unique symbol;
                                           //        message: "Incorrectly overridden";
                                           //        key: "z";
                                           //        originalType: string;
                                           //        newType: number;
                                           //   }}

let x = e.z + 1;  // in runtime x === 124
                  // yet in compile time it produces an error

let test: invalid<{}> = {}   // {} !== invalid<{}>

playground link

Forgery protection

Users are unable to to access ErrorTypeTag and even if they will extract they will not be able to provide a correct value for the corresponding property. It's not existing at all. It's anonymous unique symbol.

Drawbacks

Compile time error occurs lazily only when corresponding invalid type is compared (and thus instantiated) with something else. So if nobody used that type value, it will not produce any errors. As it was mentioned it would be cool to have an early errors. Yet it exposes type instantiation time, that was previously hidden.

Conclusion

While still waiting for eager throw types, this could be a nice temporary solution.