[swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

[Elviro Rocca]

+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