[swift-evolution] [Manifesto] Completing Generics

[Howard Lovatt]

@T.J.,

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:

f():Int

f():String

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.



  -- Howard.

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>
>>> wrote:
>>> >
>>> > 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
>>> parameter.
>>>
>>> >
>>> > 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.
>>>
>>> -Joe
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160311/f746ef4b/attachment.html>