And as a corollary, a user sees
func f(i: Int) { }
where the caller gets to provide the value for the Int but
func g() -> Int { }
and rightfully assumes that the caller gets to decide what the value is?
Values flowing into function parameters and out the return type is the natural way we think of functions. A function like this foo you argue for above
is most likely a terrible API. A better API design for this thing that is parameterized over T and returns a T would have a parameter where one specifies the type as one of the parameters:
`func betterFoo<T: P>(type: T.Type) -> T {}`
You see this in APIs like unsafeBitCast(_:to:) because relying on backward type inference is poor API design.
So, I'm having trouble with this hypothetical person that is using some P in the return type, misinterpreting it as generics, and manages to go more than a few minutes further into their confusion without bumping into the type checker and learning the proper interpretation.
And I am having a lot of trouble justifying the introduction of a third completely different syntax (generic T) in the hope that it will save that person those few minutes, because there's a much higher cognitive overload to new keywords than there is to making existing concepts work in new places, so long as there is a decent reason why it's the same concept. We have that explanation already in this proposal.
Doug