<div dir="ltr">@T.J.,<div><br></div><div>Swift does not allow overloading on return type. You cannot write:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>func f() -> Int</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>func f() -> String</div></blockquote></div><div><br></div><div>This is different than Scala, which does allow the equivalent of the above, and the type signatures above in Scala would be: </div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>f():Int</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>f():String</div><div><br></div></blockquote>respectively (note how type signatures retain their return type) and therefore you could write:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>let i: Int = f()</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>let s: String = f()</div></blockquote><div><br></div>and the compiler would call the correct versions.</div><div><br></div><div>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.<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><br></div></blockquote></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 11 March 2016 at 03:05, T.J. Usiyan <span dir="ltr"><<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">Since Swift doesn't allow overloading on return type</span></div></div></blockquote><div><br></div><div><br></div></span><div>Swift definitely allows overloading on return type.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span>
<br><div class="gmail_quote">On 10 March 2016 at 13:07, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Mar 9, 2016, at 6:02 PM, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" target="_blank">howard.lovatt@gmail.com</a>> wrote:<br>
><br>
> Wow, I would never have guessed that syntax :)<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span><br>
><br>
> 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.<br>
><br>
> But no doubt you are correct, since you probably wrote that bit of the compiler :(<br>
><br>
> More practical points<br>
><br>
> 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?<br>
> 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.<br>
> 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?<br>
> 4. Is there any documentation of all of this?<br>
<br>
</span>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.<br>
<span><font color="#888888"><br>
-Joe<br>
<br>
</font></span></blockquote></div><br></span></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div>