[swift-evolution] [Proposal] Change Void meaning
jeremie.girault at gmail.com
Mon Jun 12 12:44:58 CDT 2017
Void was the empty tuple because arguments were tuples. So no arguments
meant empty tuple.
If we consider the empty tuple to be an argument, then the type for the
type of empty tuple should be `Unit`
Void, however, seem naturally fitted for the absence of argument.
Should `func foo(Void)` be different from `func foo()`? I don’t think so.
But different from `func foo(Unit)` ? Yes !
My point here is that we probably won’t have splatting for swift4.
But if we consider the type system as a guide, we can consider 3 simple set
of rules and restore almost 100% source compatibility while keeping the
improvement of SE-0110
- Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
- Rules for swift3 tuples-arguments of cardinality one in swift 4
(proposition to be done)
- Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
(proposition to be done)
very short reply expected - vsre.info
On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
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 at swift.org> wrote:
> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
> swift-evolution at swift.org> wrote:
> Hi here,
> As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution