I can't understand why I need to cast it to the return type, while the following makes it sufficient for the compiler to infer the return type. But as you mentioned, it's illegal to put there, which is I also can't understand why I can't.
Generic manifesto specifically mentions this as a possible future enhancement. It is not unreasonable to ask for this. The problem is: Given the available resources, it is unlikely to ever happen. Unless, of course you (or someone else) cares enough about it to implement it and create an evolution proposal for its inclusion in the language.
I’d argue this change isn’t particularly difficult to implement – it would likely mean adding an extra few constraints per function call and disabling the diagnostic that currently bans the behavior. I’d be willing to take a crack at it and potentially put up a proposal.
The current preferred way to force a specific type parameter is to make a generic and take a parameter of the generic’s metatype.
func unsafeBitCast<Source, Dest>(_ value: Source, to type: Dest.Type) -> Dest
unsafeBitCast(5.0, to: Int.self)
let x = foo() as Int
let x: Int = foo()
let x = foo(Int.self)
But I am personally satisfied with the current options and am neutral about adding explicit function specialization.
The only thing that I don’t like about the current syntax, is that we always have to use .self suffix to refer to a type as value. I think compiler should be able to infer when we intend to use type as value without .self suffix, at least in most cases. So I would be happier if we could omit .self:
I remember that. I would love to revive the discussion but I don’t have time to pursue it myself.
I think the solution to the issues raised in the rationale for differing the proposal is not very complicated. We can continue to support .self and not abolish it altogether, just let us omit it when there is no ambiguity of the kind that was mentioned there.