Unfortunately, I think this proposal appears to be mistaken as to this key premise: Void was never (IIUC) meant to model the absence of arguments; it is a type with one possible value.
If I recall, a number of conversations have been raised about Void being a typealias of (), and the definitive response has been that this falls into the ship-has-sailed category of out-of-scope changes. More generally, the recent spate of complaints about regressions to a particular coding style have to do with loss of implicit tuple splatting, the cure for which is a proper implementation of tuple splatting, not poking holes into settled parts of the type system. On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
