[swift-evolution] [Proposal] Change Void meaning
svabox at gmail.com
Mon Jun 12 16:53:52 CDT 2017
On 12.06.2017 21:04, Xiaodi Wu via swift-evolution wrote:
> On Mon, Jun 12, 2017 at 12:44 Jérémie Girault <jeremie.girault at gmail.com
> <mailto:jeremie.girault at gmail.com>> wrote:
> Void was the empty tuple because arguments were tuples.
> As John explained, that is _not_ correct. Void was not motivated by anything to do
> with argument lists.
> 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`
> It has been suggested to rename Void to Unit. I do believe it’s on the commonly
> rejected ideas list (and if it’s not, it ought to be).
> Void, however, seem naturally fitted for the absence of argument.
> Should `func foo(Void)` be different from `func foo()`?
> SE-0110 determined that the two should in fact be different.
Actually *SE-0066* determinate this first:
(code example in *Proposed solution* section)
let f: () -> Int // function with no parameters
let g: (()) -> Int // function taking a single () parameter
let h: ((())) -> Int // function taking a single () parameter
f(); g(()); h(()) // correct
f(()); g(); h() // errors
Seems like it's just SE-0066 *more correctly* implemented in Swift 4 *in addition* to
> I don’t think so. But different from `func foo(Unit)` ? Yes !
> It sounds like your quarrel is with the name of the typealias. I don’t see how that
> solves any issues with the loss of tuple splatting. Functions will still return (),
> and you foo(()) is not foo().
> 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 (this
> - 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 <http://vsre.info>
> Jérémie Girault
> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu at gmail.com
> <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution