[swift-evolution] [Manifesto] Completing Generics
Howard Lovatt
howard.lovatt at gmail.com
Thu Mar 10 15:34:14 CST 2016
@Thorsten,
No it doesn't, the following Java code:
public class GenericReturnTypes {
interface Foo {
static <Output extends Number> Output foo() {
return (Output)(new Integer(0));
}
}
public static void main(String[] args) {
System.out.println(Foo.foo());
}
}
Compiles without error or warning, runs, and prints 0.
-- Howard.
On 11 March 2016 at 02:18, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>
>
> Am 10.03.2016 um 05:35 schrieb Howard Lovatt via swift-evolution <
> swift-evolution at swift.org>:
>
> I am sure you know the answer for Swift; but in other languages it
> doesn't, e.g. Java.
>
> With Java semantics:
>
> func foo<Input, Output>(input: Input) -> Output
>
>
> Would be the same as:
>
> func foo(input: Any) -> Any
>
>
> Because the only constraint on both Input and Output is Any. Since the
> Java compiler erases generics, the two would literally be the same to the
> JVM!
>
>
> To the JVM at runtime, but not to the typechecker at compile time. There
> it works just as in Swift.
>
> -Thorsten
>
>
> Since Swift doesn't allow overloading on return type and therefore as it
> stands `func foo<Input, Output>(input: Input) -> Output` cannot
> be implemented, it would be nice if the compiler flagged this as an error
> and suggested that you meant `func foo(input: Any) -> Any`.
>
> -- Howard.
>
> 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/ae3b655c/attachment.html>
More information about the swift-evolution
mailing list