[swift-evolution] [Manifesto] Completing Generics
howard.lovatt at gmail.com
Thu Mar 10 15:43:02 CST 2016
Swift does not allow overloading on return type. You cannot write:
func f() -> Int
func f() -> String
This is different than Scala, which does allow the equivalent of the above,
and the type signatures above in Scala would be:
respectively (note how type signatures retain their return type) and
therefore you could write:
let i: Int = f()
let s: String = f()
and the compiler would call the correct versions.
It is not that useful in Scala, more a by product of their type inference
(carried over from Haskell), and therefore I am not suggesting that it
should be added to Swift.
On 11 March 2016 at 03:05, T.J. Usiyan <griotspeak at gmail.com> wrote:
> Since Swift doesn't allow overloading on return type
> Swift definitely allows overloading on return type.
>> On 10 March 2016 at 13:07, Joe Groff <jgroff at apple.com> wrote:
>>> > On Mar 9, 2016, at 6:02 PM, Howard Lovatt <howard.lovatt at gmail.com>
>>> > Wow, I would never have guessed that syntax :)
>>> > It makes no sense to me to interpret a generic constraint as meaning
>>> all instead of any. How could anything either accept or return all possible
>>> implementations of something simultaneously, surely it only ever accepts or
>>> returns one of all the possible implementations at a time.
>>> A type variable in angle brackets always means "all". It's like a
>>> function parameter, but at type level—it's in the caller's hands what it
>>> gets bound to. You couldn't write a function `func foo<Input,
>>> Output>(Input) -> Output` unless that function was able to generate a value
>>> of every possible type a caller might pass in for Output, just like you
>>> couldn't write e.g. 'absolute value' as taking its result as a second
>>> > If the interpretation for output is that at time 1 it returns one of
>>> all the possible implementations at at time 2 returns another - then that
>>> is what I want. However I would describe that as returning one of the
>>> possible implementations, not all.
>>> > But no doubt you are correct, since you probably wrote that bit of the
>>> compiler :(
>>> > More practical points
>>> > 1. My compiler, 7.3 beta (7D152p), rejects the syntax, it doesn't
>>> like where inside Any<> saying it expects > to complete generic argument
>>> list. When will this be available, so that I can try it out?
>>> > 2. Will the declarations inside protocols also change to the Any<...>
>>> form or will all the generics remain following the function name rather in
>>> a returned Any<...>? Currently -> Any<...> doesn't work in protocols for me.
>>> > 3. In the construct Any<Protocol where Type == Type>, i.e. same type
>>> name used in protocol and enclosing struct/class/extension, does the left
>>> Type refer to the protocol or the enclosing struct/class/extension?
>>> > 4. Is there any documentation of all of this?
>>> Sorry, this is all possible future syntax and features. It's not
>>> implemented today. You'd need to write your own equivalent of the "Any"
>>> wrapper by hand right now.
>> swift-evolution mailing list
>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution