- Void as arguments is pretty common when using generics, that’s a core point of this proposal. An maybe that’s why we misunderstood ourselves (around 0110 / 0066). This proposal addresses arguments. - maybe it should be revised around this ? Simple example :
`typealias Callback<T> = (T) -> Void` -> `Callback<Void>` will give `(Void) => Void`. It was acceptable before swift4 but no more. However nobody cares about this `Void` argument and actually we know it’s value. So why let the developer type it ? My point here is that `Void` should be “striped” by “reducing” argument list signatures. — very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 19:15:18, John McCall ([email protected]) wrote: On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution < [email protected]> wrote: Hi here, As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage. After documenting myself about the changes which happened, I thought that they could be improved. Instead of fighting these propositions (which make sense), I wanted create a few proposal which would improve these recent changes with a few simple rules. My propositions are based on the recent decisions and in the continuation of SE-0110. The first one is about Void. Void is historically defined as the type of the empty tuple. The reason of this is that arguments were initially considered as tuple. The dominant consideration here was always return types, not parameters. I'm not sure there was ever much point in writing Void in a parameter list, but whatever reasons there were surely vanished with SE-0066. Note that 'void' in C was originally exclusively a return type. ANSI gave it a new purpose it with void*, but the meaning is totally unrelated. John.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
