Enhanced type system

[ghost]

Search Terms

enhanced type system

Suggestion

Support to create type with custom detection function in TS

Use Cases

I hope to strengthen the type system of TS,

To meet more complex requirements (such as creating a string type with limited length), and simplify code operation.

(there is a drawback and that can be made up:)

1. The high uncertainty brought by the custom detection function (especially the unknown performance overhead required to execute the function during type checking).
   (this can be achieved by limiting the custom detection function to: type will be further checked when typescript is compiled to JavaScript, and only type structure existing in the current version will be checked when writing code; to maintain the experience when writing code)

2. It may take a lot of work to realize it.

And I have a gradual proposal, which can completely avoid the above shortcomings, but also castrate the function I proposed:
Instead of adding a custom detection function to a compiler or type check, you can simply add an optional "validation function" property to the type, and then you can reference its validation function while referencing the type

Examples

//old
type T_Second = number

//new
supertype T_Second = (p:number)=>{
    return (p > 0 && p < 60)
}

/*
let s = somefn() //s = 2
T_Second testfn(s) // true
*/

Supertype receives a function whose parameter is unique and must indicate the type (the function parameter is the basic type), and the return value of this function can only be Boolean (used to further verify the type)

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[MartinJohns]

Essentially a duplicate of #202.

[RyanCavanaugh]

We've seen a number of proposals like this; all of them run afoul of at least one core constraint:

• The typechecker should not execute user code
• No type-directed emit
• No new runtime syntax

This proposal is somewhat underspecific but it's definitely violating at least one of those constraints.

[ghost]

@RyanCavanaugh I suddenly have an accurate implementation method, as follows:

supertype MyNumber (p:number):boolean{
    return (p > 0 && p < 60)
}
//type MyNumber = number | Error
//use example
function use_example(num:MyNumber):MyNumber{
    return num-1
}
let i = use_example(0) as (Error | number)

convert to current ts:

type __supertype_MyNumber = number
function MyNumber(p:number):number|Error{
    function _(p:number):boolean{
        return (p > 0 && p < 60)
    }
    return _(p)  === true ? p : new Error("supertype MyNumber returned false")
}

//use example
function use_example(__supertype_num:number):number|Error{
    let num = MyNumber(num)
    return MyNumber(num-1)
}
let i = use_example(0) as (Error | number)

[RyanCavanaugh]

That is type-directed emit.