[Pitch] Lifting restriction on explicit specialization in function calls

Evolution Pitches
41

Yeah, that's the case where we would need to introduce new cases to the heuristic to let that parse as a generic argument list.

3 Likes
42

What about the common case where the type arguments are defaulted? func f<T>(type: T.Type = T.self)?

43

Unapplied references erase default arguments, so for your f, let fn = f<Int> would produce a value of type (Int.Type) -> ().

44

I wasn’t referring to the unapplied reference case. I thought the whole point of this pitch was to move the type incantation from the parameter list to the angle brackets. People already use defaulted type arguments to avoid having to spell the type parameter in the parameter list, but if you’re saying that putting it in the angle brackets would require spelling it in the parameter list, regardless of whether the API author has defaulted it for convenience, that actually sounds like an anti-feature.

45

I believe type parameters in angle brackets are not always required but are optional. They should only be specified when the compiler cannot infer the type or when explicit type specification is necessary.

For example:

func foo<T>(value: T) -> T {
    //...
}
foo(value: 123)            //T is Int
foo(value: 123 as Int64)   //OK, but not good
foo<Int64>(value: 123)     //I think this way of writing is better.