There is no syntax for explicitly specifying type arguments to a function. Instead, you're supposed to use type inference. From Generics.rst:
We require that all type parameters for a generic function be deducible. We introduce this restriction so that we can avoid introducing a syntax for explicitly specifying type arguments to a generic function, e.g.,:
var y : Int = cast<Int>(x) // not permitted: < is the less-than operator
This syntax is horribly ambiguous in C++, and with good type argument deduction, should not be necessary in Swift.
This is a good solution, and probably the one I'd use. Another possible solution is to use the return type to aid type deduction:
let processedStrings: [String] = aString.map { ... }
With that being said, I think the diagnostic for aString.map<String> { could be made a bit more clear. Perhaps Function calls do not allow explicit type arguments could be a better message?
The bad diagnostic appears to be related to literals:
extension ExpressibleByIntegerLiteral {
func f<T>(_ t: T) { }
}
let s = ""
let i = 0
i.f<String>(s) // Cannot explicitly specialize a generic function
1.f<String>(s) // Cannot specialize a non-generic definition
Thanks for the info! That rationale kind of makes sense to me, even though it's a bit inconsistent that I'm allowed to use the explicit syntax with type names like Set<Int>.
Another possible solution is to use the return type to aid type deduction
I actually also have .joined() chained in my code so that doesn't work.
Perhaps Function calls do not allow explicit type arguments could be a better message?