[swift-evolution] [Proposal] Change Void meaning

[Vladimir.S]

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 
SE-0110 implementation.

> 
>     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
>     proposition)
>     - 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
>>>         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 at swift.org <mailto:swift-evolution at swift.org>
>>         https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>