+1 to this
I not only support the case in question, but I 100% support any proposal that
would push to compiler to completely remove any distinction from isomorphic
tuples, by always reducing the tuple to the simplest form (this kind of
discussion also took place in the thread about the SE110 rollback).
In case of:
enum Foo<T> {
case bar(T)
case baz()
}
if Foo<T>.bar is to be considered a function of type "(T) -> Foo<T>", and
Foo<T>.baz a function of type "() -> Foo<T>", then when "T == ()" the two
function must be considered of the same type, and there's no real reason from
the user standpoint to consider them of different type.
And not just that, because in the case of:
enum Foo<T> {
case bar(Int,T)
case baz()
}
if "T == ()" the two functions should be respectively of type "(Int) ->
Foo<()>" and "() -> Foo<()>", while the first one is currently of type
"(Int,()) -> Foo<()>" which makes absolutely no sense.
A function that has a value of type "()" in the inputs makes no sense at all.
The following function signature is meaningless and its avoidance should be
enforced by the compiler
func wat(_ value: ()) -> Int {
return 42
}
let a = wat
let b = a() /// compiler error
The empty tuple should be automatically removed by the compiler for generics,
or an error should be emitted in non-generic cases, simply because it is a
singleton and it can always be produced out of thin air. It shouldn't be a
valid argument of a function, and it should be stripped by any tuple like
"(A,(),B)" or similar.
I made several more points in the SE110 discussion, and answered to most of the
objections, so if you're interested you can read my answers there.
Thanks
Elviro
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
