Omitting generics from the end is not allowed

[Ciantic]

I don't see why omitting (or leaving remaining generics for type inference) is not allowed:

interface SomeInterface<M, T> {
    other: T
    validate(): M
}

function test<M,T>(t: T): SomeInterface<M, T> {
    return <any> null;
}

interface Thingie {
    first: string
    second: string
}

test<Thingie, string>("test"); // Works just fine
test<Thingie>("test"); // ERROR: Supplied parameters do not match any signature of call target.

Now this is trivial in case of string, but if the argument is something like object literal, then I have to retype everything from that object literal to two places.

Another syntax proposal could be allowing have empty comma, like this: test<Thingie,>("test");

It would signify that second parameter is left empty, intentionally.

[mhegazy]

The compiler can not know the intention. so either you left it off by mistake or intentionally to mean any. The design favors conservativness here. also the compiler will try to infer the generic type arguments from your normal arguments. the example above is a bit artificial though, as the type parameter M is not manifested in any argument, but rather passed through to the return type, which is identical to casting the result <SomeInterface<Thingie, string>>test("test");

[Ciantic]

It's not artificial example, I'm creating a validator and it requires me to type both generics even though the second one is always much better as type inferred.

It's hard to explain this succintly, but I suspect there is whole lot of other use cases for leaving rest of the generics for type inference.

Did you look at this edit I added: the intentional syntax test<Thingie,>("test"); makes it clear programmer actually wants the second argument inferred.

[danquirk]

Could you post an example of code where you need to explicitly specify some type arguments which aren't inferred correctly while others are? The better fix from my perspective would be to fix the inference process so that you don't have to specify any of the type arguments explicitly.

[Ciantic]

@danquirk and @mhegazy

This example would be prohibitively long, so I'll try again with use case. But the use case is so cool and useful that I really want this to work! This is basically Django class fields syntax as object literal, and with interfaces, no classes was abused!

It allowes to create nested validator in fully readable format, check this out:

interface Address {
    city : string
    street : string
}

interface User {
    id: number
    name: string
    email: string
    address: Address
}

var userValidator = V.objectField<User>({ // Here is the GIST of the problem!
    id : V.integerField(),
    name : V.stringField(required=true),
    email : V.stringField(),
    address : V.objectField<Address>({
        city : V.stringField(),
        street : V.stringField(),
    })
});

userValidator
    .validate({...}) // Some User object from FORM data etc. you want to validate
    .then(function (valid) {
        // Valid is User!
    })
    .catch(function (errors) { // errors is {[name: string} : string[]}

    });

// Or I can fully typedly validate part of the tree:
userValidator.$.address
    .validate({...}) // Address
    .then(function (valid) {
        // Valid is Address!
    })
    .catch(function (errors) { // errors is {[name: string} : string[]}

    });

// or nested
userValidator.$.address.$.street.validate(...) // This *is* same stringField as in the definition

Get it? The V.objectField is the test function in my first example. It passes the User to interface, it doesn't use it as argument at first.

The use case I have here is really amazing! Unfortunately to get this thing working right now I have to write it something like this :(

var userValidator = V.objectField<User, {
    id : IntegerField,
    name : StringField,
    email : StringField,
    address : ObjectField<Address, {
        street : StringField,
        city : StringField,
    }>
}>({ // Here is the GIST of the problem!
    id : V.integerField(),
    name : V.stringField(required=true),
    email : V.stringField(),
    address : V.objectField<Address>({
        city : V.stringField(),
        street : V.stringField(),
    })
});

Because if I put that User in there it requires me to to insert the second parameter too.

Edit IF you are wondering why the second generic is there at all it's because it has important use cases. E.g. I have special variable $ I have added it's use case to above example.

[mhegazy]

looks like this is a dupe of #3423 then?

[Ciantic]

In my case the User is not inferrable from anywhere, it's tight to the validator object when validator is defined. I mean this:

var userValidator = V.objectField<User>({ // Here is the GIST of the problem!
    id : V.integerField(),
    name : V.stringField(required=true),
    email : V.stringField(),
    address : V.objectField<Address>({
        city : V.stringField(),
        street : V.stringField(),
    })
});

Can't be simplified anymore in any way. It already contains everything it needs to. This "User" can't be inferred from anywhere. Because the above syntax defines the validator for User, inferring it when using the validator would be dangerous because the point is to validate User and not arbitrary objects.

But I do agree however that maybe optional generics is not a good thing and I propose either alternative syntax:

var userValidator = V.objectField<User,>(...) or something like it var userValidator = V.objectField<User,*>() to signify the programmer wants the generic to be inferred.

[Ciantic]

Edit I must say this is a hack, and not a real solution. It is awful to use, I've tried really hard.

I just discovered a way to "omit" generics using a function, that returns a function:

// Trick is the definition in here:
function objectField<C>(v: C): <M>() => ObjectField<M, C> {
    return <any> null; // This implementation is not relevant
}

// Now I can define it neatly as two, with this first one type inferred, and second one as typed
var validator = V.objectField({
    id : V.numberField(),
    name : V.stringField(),
    addresses : V.arrayField(V.objectField({
        id : V.numberField(),
        street : V.stringField(),
        city  : V.stringField()
    }))
})<{
    id : number,
    name : string,
    addresses : {
        id : number,
        street : string,
        city : string
    }[]
}>();

validator.$.id // Auto completes as id, numberField
validator.validate(<any>{}).then(v => {
    v.id // Auto completes as id, number
});

[mhegazy]

#2175 provides a safer way to achieve the desired output. the declarations will need to opt-in into this by specifying a default type.