Aggregate function assertions

[ghost]

Suggestion

🔍 Search Terms

Multi-assertions, function assertion signatures, type assertions, aggregate assertions

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Allow functions that assert a type or condition to assert multiple types or conditions

(Maybe?) Allow functions with "asserts" signatures to return a type other than void.
(Update: the secondary goal is covered by other issues)

💻 Use Cases

It allows multiple type assertions at once.

// declare AssertionError

function assert(x: unknown, y: unknown): (asserts x is number) & (asserts y is number) {
    if (typeof x !== "number" || typeof y !== "number") {
        throw new AssertionError("Assert failed: 'x' and 'y' are not both numbers");
    }
}

or

function safeAdd(x: unknown, y: unknown): (number) & (asserts x is number) & (asserts y is number) {
    if (typeof x !== "number" || typeof y !== "number") {
        throw new AssertionError("`x` and `y` are not both numbers");
    } else {
        return x + y;
    }
}

or

declare function safeAdd(...args: unknown[]): asserts args is [number, number];

No idea what the syntax would be, but this should give the idea.

📃 Motivating Example

My use for this was that I had a function that accepted two parameters. It only operated if the first parameter was of a type (T), it also had an overload for the second parameter being the same type (T) or anything else.

declare function assertIsT (x: unknown): asserts x is T;
declare function isT (x: unknown): x is T;
function f (x: unknown, y: unknown): asserts x is T;
function f (x: T, y: T | H) {
    assertIsT(x);
    // x: T

    if ( isT(y) ) {
        // ... y: T
    } else {
        // ... y: H
    }
}

This was meant to be "JavaScript-compatible" code, as in, it could be used by a non-TS user with relative type safety, but, the assertion seems like extra work, as if I'm being over-cautious, so I wanted to simplify it:

declare function isT (x: unknown, y: unknown): (asserts x is T) & (y is T);
function f (x: unknown, y: unknown): asserts x is T;
function f (x: T, y: T | H) {
    if ( isT(x, y) ) {
        // ... x: T
        // ... y: T
    } else {
        // ... x: T
        // ... y: H
    }
}

Now, it's terse and straightforward, while retaining type-safety.
(I am not advocating any specific syntax for the aggregation/mixing)

I tried to get this to work with function overloads, but it wasn't happening.
Playground link

---

Related issues?
#40562
#34636

[ghost]

Update, just figured out that the following issues already cover the second part of what I'd have like see in TS,

(Maybe?) Allow functions with "asserts" signatures to return a type other than void

• Non‑void returning assertion functions #40562
• ReturnType support for assertions #34636

I guess this should be scoped solely to returning multiple x is T, and asserts x is T.
And of course, multiple asserts x; it wouldn't be of particular use to me as an individual, but plenty of other developers might like to have it too.

[emilioplatzer]

I also need multiple asserts guard type. Here is my Use Case:

I have a class Application (or any class that aquires resources). When is properly connected the class have a database opened connection, a path to /tmp and a "log" resource. When is not connected any of than may be null. 90% of methods apply when de application is properly connected:

class Application{
    database Database | null = null
    log Log | null = null
    tmpPath string | null = null
    async connectToDb(conn:string){
         this.database = pg.connect(conn);
    }
    async setPath(path:string){
         ....
    }
    async logTo(path:string){
         ....
    }
    isProperlyConnected(database:Database|null, log:Log|null, path:string|null) asserts database is Database & log is Log & path is string{
      if(databse == null) throw new Error('database is null'); 
      ...
   }
    async doStuff1(){
        this.isProperlyConnected(this.database, this.log, this.tmpPath);
        this.database.query('select ....') ...
    }
    async doStuff2(){
        this.isProperlyConnected(this.database, this.log, this.tmpPath);
        this.log.redirectTo(this.tmpPath) ...
    }
}

What are the adventages?

If in the feature I need to add other resource to isProperlyConnected I do it and I warn if I forget to change it un some stuff. But if I call separate guards for each resource I do not warn if I forget one.

[Pyrolistical]

Also wrapping individual assertion functions doesn't work. The assertion doesn't seem to be passed up transitively.

function assertNumber(value: unknown): asserts value is number {
    if (typeof value !== 'number') throw new Error('expected value to be a number')
}

// this doesn't work
function assertBothNumber(x: unknown, y: unknown) {
    assertNumber(x)
    assertNumber(y)
}

playground demo

Perhaps it is an easier way forward to propagated assertion functions?

[ghost]

@Pyrolistical Ideally your example of assertBothNumber would have the same (return) type as the poster's assert(x: unknown, y: unknown): (asserts x is number) & (asserts y is number). That is, ideally they should both function and be permitted.

[Pyrolistical]

@phosra I agree, but perhaps the desired behaviour can be delivered without a syntax change. That would reduce the scope.

[sebinsua]

I would also like this.

My use case is wanting to be able to narrow multiple arrays into the same opaque/branded/flavoured type when they are of equal length. This would help us to create type-safe data operations for manipulation of arrays and matrices, etc.

I agree with @Pyrolistical that propagating type assertions would allow us to compose them and might be preferable to creating further syntax. (I also tried doing this naturally, before realising it wasn't supported.)