@Howard
my IDE immediately flags a warning for the cast: "unchecked cast from Integer to Output" which is correct and the root of the problem. Unchecked casts are cheating the type system, effectively disabling it at that location and introducing the possibility of type errors.
Let's change the main method a bit:
public static void main(String args) {
Double x = Foo.foo();
System.out.println(x);
}
No warnings in the main method as everything is ok for the type system: we are calling Foo.foo() as is inferred correctly by the type checker.
But due to the cast we now get a runtime error:
Exception in thread "main"
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Double
This only could happen because the cast did break the type checker.
Actually it is impossible to write an implementation for
static Output foo()
because you simply cannot create an instance of Output (where the concrete type value for Output is defined by the caller and so cannot be known to the implementation beforehand; you only know that it will be a subtype of Number but not which; heck, the type used for Output can even be defined by the client and therefore does not even have to exist when you write foo()).
Interesting side note: you can write an implementation for
static T identity(T x)
but only one implementation is possible here, which is strictly following from the types (I'm still assuming pure functions with no access to external state here, of course):
static T identity(T x) { return x; }
-Thorsten
···
Am 10. März 2016 um 22:34 schrieb Howard Lovatt howard.lovatt@gmail.com:
@Thorsten,
No it doesn't, the following Java code:
public class GenericReturnTypes {
interface Foo {
static 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@icloud.com wrote:
Am 10.03.2016 um 05:35 schrieb Howard Lovatt via swift-evolution swift-evolution@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) -> Outputcannot be implemented, it would be nice if the compiler flagged this as an error and suggested that you meantfunc foo(input: Any) -> Any.
-- Howard.
On 10 March 2016 at 13:07, Joe Groff jgroff@apple.com wrote:
On Mar 9, 2016, at 6:02 PM, Howard Lovatt howard.lovatt@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) -> Outputunless 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
- 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?
- 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.
- 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?
- 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution