# \[Proposal\] Change Void meaning **URL:** \ **Category:** Discussion\ **Created:** [June 12, 2017, 8:48am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100 "2017-06-12T08:48:55Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\ **Post date:** [June 12, 2017, 7:05pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/21 "2017-06-12T19:05:16Z")
> 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. But you can’t deny that SE-0110 has also caused regressions in the use of Void as generic argument because Void is modelled as the empty tuple. And tuple splatting will not fix those regressions. And contrary to what some people might think, this is not an “edge-case”. Most useful monads modelled with generics have good reasons to use Void: The Result\ monad: Result\ represents the result of an operation with no return value The Promise\ monad: Promise\ represents the result of an asynchronous operation with no return value The Observable\ monad (in functional reactive programming): Observable\ represents a stream of events with no values I use all three monads in my code and I’ve had to modify a lot of code when migrating to Swift 4 beta1 because of Void. David. > **···** > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \ wrote: > > > On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution \\> wrote: > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution \\> 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [June 13, 2017, 11:23am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/22 "2017-06-13T11:23:23Z")
Thank you for reply, but actually I was trying to figure out if I understand correctly "what any of these \*should\* do in Swift 4". Also, it will be great if we have a record of how such code at least \*should\* work in Swift 4, so we can refer to this. So, again, I'm asking you or some one from core team to spent 1 minute to reply so we all have a clear view of expected results for this code. Thank you. I do believe this is very important in lights of current debates regarding SE-0110 changes(actually, I insist, more correct implementations of SE-0066) and probably can help to avoid the same problem after "bugs" will be fixed. Btw, it is \*very\* strange for me that you are calling current behavior as "bugs", and even strange that these long-running "bugs" can be still with us in Swift 4 (note: SE-0066 and SE-0110 was accepted to be implemented in \*Swift 3\*). And more important, as I understand, fixing these "bugs" will lead to \*source breaking\* changes, that is not possible for long time after Swift 4 release. Plus, keeping these "bugs" leaves Swift in very broken state : we broke what was allowed in Swift 3 to fix the type system, but still have type system broken \*in the same exact place\*. I really can't understand this. It is fundamentally that type(of: fooParam) == type(of: fooTuple) even in Swift 4, it is not just a little "bug", code \*will\* use this "feature" and then we'll have a very loud voices about regressions in Swift if such "bug" will be "fixed". The same is for fooParam is ((Int,Int))-\>() and fooTuple is (Int,Int)-\>() and so on. I can't see how this could be a bug fixing - it is fundamental changes in allowed syntax and in type system. And so this couldn't be done after Swift 4 release. No? About this: > **···** > > On 13.06.2017 3:35, John McCall wrote: > > > > On Jun 12, 2017, at 6:42 PM, Vladimir.S \ wrote: > > > > > > John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations \*planned\* for Swift 4 release? I believe all these are important questions to be answered to understand the near feature of Swift and to be prepared for changes. > > > > It's not hard to figure out what any of these \*should\* do in Swift 4. I'm not going to commit to promising that Swift 4 will not have bugs that cause deviations from that. If the Core Team decides that something needs to happen with parameter destructuring in Swift 4, that will not go without comment here. > > ---- > On 13.06.2017 2:24, Jens Persson wrote: > \> This: [https://twitter.com/slava\_pestov/status/874394132340289536](https://twitter.com/slava_pestov/status/874394132340289536) > \> seems to suggest that the current Swift 4 behavior will not change much in this domain. > \> > ---- > > It will be really \*nice\* to have a more detailed reply from core team regarding all this situation with SE-0025, SE-0066, SE-0110 implementations in Swift 4 and the "bugs" mentioned in my message, here in official swift evolution email list. > > Vladimir. > > > John. > > > > > Given : > > > > > > func fooParam(\_ x: Int, \_ y: Int){} > > > func fooTuple(\_ x: (Int, Int)) {} > > > > > > and > > > > > > var closureParam = { (x: Int, y: Int) in print("in closureParam") } > > > var closureTuple = { (x: (Int, Int)) in } > > > > > > \* What will be the result in Swift 4 release? : > > >   1. type(of:fooParam) > > >   2. type(of:fooTuple) > > >   3. type(of:closureParam) > > >   4. type(of:closureTuple) > > > > > > \* Will this be true in Swift 4 release? : > > >   1. type(of: fooParam) == type(of: fooTuple) > > >   2. fooParam is ((Int,Int))-\>() > > >   3. fooTuple is (Int,Int)-\>() > > >   4. type(of: closureParam) == type(of: closureTuple) > > >   5. closureParam is ((Int,Int))-\>() > > >   6. closureTuple is (Int,Int)-\>() > > > > > > \* Will this code still be valid in Swift 4 release? : > > >   1. > > >   closureTuple = closureParam > > >   closureTuple((1,2)) // prints "in closureParam" > > > > > >   2. > > >   var f: () -\> Int = { 5 } // function with no parameters > > >   var g: (()) -\> Int = { 5 } // function taking a single () parameter > > >   f = g > > >   f() > > > > > > \* Does core team plan to introduce some syntactic sugar for tuple argument destructuring in closures \*before\* Swift 4 release? > > > If so, what do you think about a suggestion to allow type inference for currently allowed syntax for tuple argument destructuring? I.e. > > > allowed: .filter {(friend: (name: String, age: Int)) in friend.age \>= 18 } > > > proposed: .filter {(friend: (name, age)) in friend.age \>= 18 } > > > > > > \* And the same for passing function with no parameters if function with single Void parameter is expected? I.e. in such situation: > > > func foo\(\_ callback: (T)-\>Void) {} > > > func bar(){} > > > foo(bar) > > > > > > Thank you for your time. > > > Vladimir. > > > > > > On 12.06.2017 20:15, John McCall via swift-evolution wrote: > > > > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution \\> 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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 7:32pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/23 "2017-06-12T19:32:54Z")
@xiaodi I disagree on many points, for example what is the type of x when we type `let x = *Void` ? This is the essence of the problem and this proposition wants to solve this. The regression is due to both reason combined : typealias Void = () AND SE-0110 My proposition is to change the meaning of Void from () to “something else” that is type-compatible with SE-0110 (and splatting in the future). If you want an example of the changes needed to migrate to swift4, just look at the 42 files of handling parenthesis PR of RxSwift needed for swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> 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. > > > > But you can’t deny that SE-0110 has also caused regressions in the use of > > Void as generic argument because Void is modelled as the empty tuple. > > I'm not sure I understand this statement. Void is a synonym for the empty > tuple, and that hasn't ever changed, so it can't be the root cause of any > regressions. > > > And tuple splatting will not fix those regressions. > > How come? If `*` is the splat operator, then it would be legal to call a > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > splatting returns in fully implemented form, then it would be legal to call > it once again with `foo(Void)`. > > And contrary to what some people might think, this is not an “edge-case”. > > > Most useful monads modelled with generics have good reasons to use Void: > > > > \*The Result\ monad:\* Result\ represents the result of an operation > > with no return value > > \*The Promise\ monad:\* Promise\ represents the result of an > > asynchronous operation with no return value > > \*The Observable\ monad (in functional reactive programming):\* > > Observable\ represents a stream of events with no values > > > > I use all three monads in my code and I’ve had to modify a lot of code > > when migrating to Swift 4 beta1 because of Void. > > Can you give examples of the modifications needed during migration? From > here, I can only see that the reason any code needs modification is the > complete removal of implicit tuple splatting. Nothing has changed about > Void being a synonym for the empty tuple; even if you rename Void, > functions will still return () by some other name, and unless there is > tuple splatting in some form, the migration you performed is inevitable. > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 7:56pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/24 "2017-06-12T19:56:26Z")
@Xiaodi Wu Disagree, and we would need the original designer here to help us, but my understanding of the original meaning of tuples-as-arguments is that when I define: `func foo(_ arg0: Any, _ arg1: Any) {}` I can afterwards “apply” a tuple to a function named `foo` and therefore execute the function on this tuple. Calling a function syntax was equivalent to put a tuple next to a function name: `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, “hello")` is the tuple. The same way if I have `func foo()` `foo()` means calling `foo` with argument `()` and there we have our original `Void` That meaning changed recently due to multiple SE implementations actually. The parenthesis around the call don't have a tuple meaning anymore. Therefore it breaks a lot of code relying on this feature of the language, which was quite elegant, but could not handle advanced functions features. @john: Void can happen easily in parameters due to generics, the easiest example that breaks with swift4 is `typealias Callback\ = (T) -\> Void` here `Callback\` which is perfectly reasonable introduces Void in the argument list and forces the caller to introduces an empty partenthesis set when invoking: ```swift let foo: Callback = { } foo(()) ``` That’s were the proposal shines in my opinion: adapting the meaning of Void to the current context of swift4 gives back the language the elegant syntax it had while preserving the type system > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ 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. > > 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 > > Jérémie Girault > > > > On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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@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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 8:04pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/25 "2017-06-12T20:04:18Z")
Exactly, that means that your implementation of the tuple splatting operator is out of the type system. Can you expose it’s signature ? If you want the operator to be “compiler-magic” it’s possible. This proposal is an alternate solution. My point is that updating Void according to this proposal would - preserve the type system in a better way - have better source compatibility (in time for swift 4 release, were we probably won’t see tuple splatting) - also keep the elegant original syntax of swift instead of stacking parenthesis The impact for code writers would be minimized on time for swift 4 release As for return values: this proposition does not intend to change the how return value of Void functions works. > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault \ wrote: > > > @xiaodi > > I disagree on many points, for example what is the type of x when we type > > `let x = *Void` ? > > That would not be a legal statement. Exploding a tuple is an operation that > only makes sense inside an argument list. Likewise `let x = &Void` will not > compile. > > > This is the essence of the problem and this proposition wants to solve > > this. > > > > The regression is due to both reason combined : typealias Void = () AND > > SE-0110 > > > > My proposition is to change the meaning of Void from () to “something > > else” that is type-compatible with SE-0110 (and splatting in the future). > > I'm not sure I understand your motivation. Void is just a typealias. If > tomorrow Void meant something else, all functions must still return (), and > there is still no implicit tuple splatting. > > > If you want an example of the changes needed to migrate to swift4, just > > look at the 42 files of handling parenthesis PR of RxSwift needed for > > swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) > > Indeed, that's the result of SE-0110; these parentheses are needed because > there is no implicit tuple splatting. They would be required even if `Void` > did not exist in the language at all. > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \>\> swift-evolution@swift.org\> 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. > > > > > > But you can’t deny that SE-0110 has also caused regressions in the use of > > > Void as generic argument because Void is modelled as the empty tuple. > > > > I'm not sure I understand this statement. Void is a synonym for the empty > > tuple, and that hasn't ever changed, so it can't be the root cause of any > > regressions. > > > > > And tuple splatting will not fix those regressions. > > > > How come? If `*` is the splat operator, then it would be legal to call a > > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > > splatting returns in fully implemented form, then it would be legal to call > > it once again with `foo(Void)`. > > > > And contrary to what some people might think, this is not an “edge-case”. > > > > > Most useful monads modelled with generics have good reasons to use Void: > > > > > > \*The Result\ monad:\* Result\ represents the result of an > > > operation with no return value > > > \*The Promise\ monad:\* Promise\ represents the result of an > > > asynchronous operation with no return value > > > \*The Observable\ monad (in functional reactive programming):\* Observable\ > > > represents a stream of events with no values > > > > > > I use all three monads in my code and I’ve had to modify a lot of code > > > when migrating to Swift 4 beta1 because of Void. > > > > Can you give examples of the modifications needed during migration? From > > here, I can only see that the reason any code needs modification is the > > complete removal of implicit tuple splatting. Nothing has changed about > > Void being a synonym for the empty tuple; even if you rename Void, > > functions will still return () by some other name, and unless there is > > tuple splatting in some form, the migration you performed is inevitable. > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 8:16pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/26 "2017-06-12T20:16:50Z")
I invite you to read the proposal rules again with a fresh mindset and benevolence spirit. It’s my first one and may not be very clear but the rules are straightforward. Especially try to forget that Void is a tuple or anything. Void is Nothing in the programmer’s mind. An instance of Void shouldn’t even exist. The proposed meaning of Void is to be a “lack” of arguments. It means that each “Void” argument reduces the arity of the function by one, at its exact position. Especially look at the canonical signature definition, and the proposed rules of reduction. That proposal, if implemented, would effectively allow `Callback\` to be called without arguments in the context of swift4. > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault \ wrote: > > > @Xiaodi Wu > > Disagree, and we would need the original designer here to help us, but my > > understanding of the original meaning of tuples-as-arguments is that when I > > define: > > `func foo(_ arg0: Any, _ arg1: Any) {}` > > I can afterwards “apply” a tuple to a function named `foo` and therefore > > execute the function on this tuple. > > Calling a function syntax was equivalent to put a tuple next to a function > > name: > > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, > > “hello")` is the tuple. > > > > The same way if I have > > `func foo()` > > `foo()` means calling `foo` with argument `()` and there we have our > > original `Void` > > > > That meaning changed recently due to multiple SE implementations actually. > > Tuples-as-arguments never shipped in any version of Swift, and the ability > to "apply" a tuple like that was removed by SE-0029--the original goal was > to implement this change in time for Swift 2.2. > > > The parenthesis around the call don't have a tuple meaning anymore. > > Therefore it breaks a lot of code relying on this feature of the language, > > which was quite elegant, but could not handle advanced functions features. > > Yes, this is an intentional and approved part of SE-0029. The drawbacks > were enumerated in that proposal and were deemed acceptable. > > > @john: Void can happen easily in parameters due to generics, the easiest > > example that breaks with swift4 is > > `typealias Callback\ = (T) -\> Void` > > here > > `Callback\` which is perfectly reasonable introduces Void in the > > argument list and forces the caller to introduces an empty partenthesis set > > when invoking: > > > > ```swift > > let foo: Callback = { } > > foo(()) > > > > ``` > > `Callback\ = (T) -\> Void` refers to a callback that takes exactly one > argument. Since argument lists are not tuples, it is not possible to invoke > such a callback with zero arguments, or for that matter with two, three, > four, or five arguments. > > That’s were the proposal shines in my opinion: adapting the meaning of Void > > > to the current context of swift4 gives back the language the elegant syntax > > it had while preserving the type system > > I'm not sure what you mean by this. No change in `Void` can cause a > function of type (T) -\> Void to accept zero arguments: it requires one > argument of type T. > > On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ \> 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. > > > > 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 > > > Jérémie Girault > > > > > > On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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@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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 9:10pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/27 "2017-06-12T21:10:49Z")
> **···** > > — > > very short reply expected - [vsre.info](http://vsre.info) > > Jérémie Girault > > On 12 juin 2017 at 22:34:45, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > I invite you to read the proposal rules again with a fresh mindset and benevolence spirit. > > > > It’s my first one and may not be very clear but the rules are straightforward. > > > > > > > > Especially try to forget that Void is a tuple or anything. > > > > Void is Nothing in the programmer’s mind. An instance of Void shouldn’t even exist. > > > > > > Sorry, that's not correct. Void is what's called Unit in other languages. It exists. That is why functions with "no return value" return Void. OTOH, Never does not exist. This discussion was had in great detail during the naming debate over Never. > > Let’s put facts in front of correctness assertions. Is Void = Unit in C or c++ ? can you create instances of void in java ? you have Void for generics. [https://en.wikipedia.org/wiki/Unit\_type](https://en.wikipedia.org/wiki/Unit_type) > > And if you look at assembly, sending void or returning void actually means "nothing to push on the stack / nothing to pop”. Seems like having this stripping on signatures at compile-time could be great ! > > Actually, in my opinion we could discuss naming when we agree that the mechanism works, using this name is just a way to not impact the developer with code changes. > > So either we agree on the fact that the mechanism works and we can move on to naming, or we get back on the topic : do you see a flaw in the proposal rules ? It elegantly transforms signature arity and provides the programmer a natural syntax to express it’s code. > > > > > > > The proposed meaning of Void is to be a “lack” of arguments. It means that each “Void” argument reduces the arity of the function by one, at its exact position. Especially look at the canonical signature definition, and the proposed rules of reduction. > > > > > > I don't understand why you propose to name this new idea "Void". You're proposing something that's not even a lack of an argument, but an anti-argument, like anti-matter! I'm not sure I understand why this is necessary. It seems to be a very strange workaround for one specific issue arising from disallowing implicit tuple splatting. > > Look at other languages, when you put Void in functions in C or java, do you need to add a value ? Ease of use is important. > > You imply that I disagree with splatting were I don’t, let’s not make it personal. This proposal is even compatible with tuple splatting ! > > The proposal rules seem to work and provides great user value. Let’s try to consider this ! > > > > > > > That proposal, if implemented, would effectively allow `Callback` to be called without arguments in the context of swift4. > > > > — > > > > very short reply expected - [vsre.info](http://vsre.info) > > > > Jérémie Girault > > > > On 12 juin 2017 at 22:06:54, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > > > > > @Xiaodi Wu > > > > > > Disagree, and we would need the original designer here to help us, but my understanding of the original meaning of tuples-as-arguments is that when I define: > > > > > > `func foo(_ arg0: Any, _ arg1: Any) {}` > > > > > > I can afterwards “apply” a tuple to a function named `foo` and therefore execute the function on this tuple. > > > > > > Calling a function syntax was equivalent to put a tuple next to a function name: > > > > > > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, “hello")` is the tuple. > > > > > > > > > > > > The same way if I have > > > > > > `func foo()` > > > > > > `foo()` means calling `foo` with argument `()` and there we have our original `Void` > > > > > > > > > > > > That meaning changed recently due to multiple SE implementations actually. > > > > > > > > > > Tuples-as-arguments never shipped in any version of Swift, and the ability to "apply" a tuple like that was removed by SE-0029--the original goal was to implement this change in time for Swift 2.2. > > > > > > The parenthesis around the call don't have a tuple meaning anymore. Therefore it breaks a lot of code relying on this feature of the language, which was quite elegant, but could not handle advanced functions features. > > > > > > > > > > Yes, this is an intentional and approved part of SE-0029. The drawbacks were enumerated in that proposal and were deemed acceptable. > > > > > > @john: Void can happen easily in parameters due to generics, the easiest example that breaks with swift4 is > > > > > > `typealias Callback = (T) -> Void` > > > > > > here > > > > > > `Callback` which is perfectly reasonable introduces Void in the argument list and forces the caller to introduces an empty partenthesis set when invoking: > > > > > > ```swift > > > > > > > > > > ``` > > > > > > let foo: Callback = { } > > > > > > foo(()) > > > > > > ```swift > > > > > > > > > > ``` > > > > > > > > > > `Callback = (T) -> Void` refers to a callback that takes exactly one argument. Since argument lists are not tuples, it is not possible to invoke such a callback with zero arguments, or for that matter with two, three, four, or five arguments. > > > > > > > > > > > That’s were the proposal shines in my opinion: adapting the meaning of Void to the current context of swift4 gives back the language the elegant syntax it had while preserving the type system > > > > > > > > > > I'm not sure what you mean by this. No change in `Void` can cause a function of type (T) -\> Void to accept zero arguments: it requires one argument of type T. > > > > > > > > > > > > > > > > On 12 juin 2017 at 20:04:18, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > > > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@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. > > > > > > > > > > > > > > > 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@gmail.com](mailto:xiaodi.wu@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@swift.org](mailto:swift-evolution@swift.org) wrote: > > > > > > > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution [swift-evolution@swift.org](mailto: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](mailto:swift-evolution@swift.org) > > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 7:17pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/28 "2017-06-12T19:17:45Z")
> 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. > > But you can’t deny that SE-0110 has also caused regressions in the use of > Void as generic argument because Void is modelled as the empty tuple. I'm not sure I understand this statement. Void is a synonym for the empty tuple, and that hasn't ever changed, so it can't be the root cause of any regressions. > And tuple splatting will not fix those regressions. How come? If `*` is the splat operator, then it would be legal to call a function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple splatting returns in fully implemented form, then it would be legal to call it once again with `foo(Void)`. And contrary to what some people might think, this is not an “edge-case”. > Most useful monads modelled with generics have good reasons to use Void: > > \*The Result\ monad:\* Result\ represents the result of an operation > with no return value > \*The Promise\ monad:\* Promise\ represents the result of an > asynchronous operation with no return value > \*The Observable\ monad (in functional reactive programming):\* > Observable\ represents a stream of events with no values > > I use all three monads in my code and I’ve had to modify a lot of code > when migrating to Swift 4 beta1 because of Void. Can you give examples of the modifications needed during migration? From here, I can only see that the reason any code needs modification is the complete removal of implicit tuple splatting. Nothing has changed about Void being a synonym for the empty tuple; even if you rename Void, functions will still return () by some other name, and unless there is tuple splatting in some form, the migration you performed is inevitable. > **···** > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 9:40pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/29 "2017-06-12T21:40:31Z")
> **···** > > — > > very short reply expected - [vsre.info](http://vsre.info) > > Jérémie Girault > > On 12 juin 2017 at 23:27:31, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > On Mon, Jun 12, 2017 at 4:10 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > > > > > — > > > > very short reply expected - [vsre.info](http://vsre.info) > > > > Jérémie Girault > > > > On 12 juin 2017 at 22:34:45, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > > > On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > > > > > I invite you to read the proposal rules again with a fresh mindset and benevolence spirit. > > > > > > It’s my first one and may not be very clear but the rules are straightforward. > > > > > > > > > > > > Especially try to forget that Void is a tuple or anything. > > > > > > Void is Nothing in the programmer’s mind. An instance of Void shouldn’t even exist. > > > > > > > > > > Sorry, that's not correct. Void is what's called Unit in other languages. It exists. That is why functions with "no return value" return Void. OTOH, Never does not exist. This discussion was had in great detail during the naming debate over Never. > > > > Let’s put facts in front of correctness assertions. Is Void = Unit in C or c++ ? can you create instances of void in java ? you have Void for generics. [https://en.wikipedia.org/wiki/Unit\_type](https://en.wikipedia.org/wiki/Unit_type) > > > > > > Sorry, I don't understand your line of argumentation. Fact: in Swift, Void is the name of the unit type. Are you objecting to the naming of the unit type in Swift? Do you want the unit type to have other features? Is there some other way of modeling the unit type other than a tuple of arity 0 that you prefer? > > As I’m saying I’m not discussing the name. I propose to replace Void with another mechanism so that source compatibility is improved. Defining a unit type and names is trivial afterwards. > > > > > > > And if you look at assembly, sending void or returning void actually means "nothing to push on the stack / nothing to pop”. Seems like having this stripping on signatures at compile-time could be great ! > > > > Actually, in my opinion we could discuss naming when we agree that the mechanism works, using this name is just a way to not impact the developer with code changes. > > > > So either we agree on the fact that the mechanism works and we can move on to naming, or we get back on the topic : do you see a flaw in the proposal rules ? It elegantly transforms signature arity and provides the programmer a natural syntax to express it’s code. > > > > > > I have read your proposal three times, but I do not understand what it is proposing, in part because your proposal contains factual errors in the premises. For instance, it claims repeatedly that Void is a typealias for () because of something to do with argument lists, which is not true. It is therefore unclear to me what it is you are proposing to do and what is motivating such a proposal. > > > > > > All I am saying is that, in previous conversations on this list, people who actually do the work of implementing features in the compiler have stated that `typealias Void = ()` is a fait accompli. With that as a starting point, what do you propose to do? > > You probably know the original designer intent better than me because you are here for a longer time, but that’s not the point. And thank you for trying to understand it again : > > - The goal of the proposal is to replace Void by an intrinsic which would reduce the arity of argument list it is present in. > > - Why ? Because, especially when using generics, Void will easily be introduced in parameter lists. Actually it introduces useless arguments. If you follow the rules in Detailed design, you will see that the reduction of arity will lead to a better source compatibility and syntax. Moreover the expected result, from a developer point of view, feels more natural. > > > > > > > > > > > > > > The proposed meaning of Void is to be a “lack” of arguments. It means that each “Void” argument reduces the arity of the function by one, at its exact position. Especially look at the canonical signature definition, and the proposed rules of reduction. > > > > > > > > > > I don't understand why you propose to name this new idea "Void". You're proposing something that's not even a lack of an argument, but an anti-argument, like anti-matter! I'm not sure I understand why this is necessary. It seems to be a very strange workaround for one specific issue arising from disallowing implicit tuple splatting. > > > > > > > > Look at other languages, when you put Void in functions in C or java, do you need to add a value ? Ease of use is important. > > > > You imply that I disagree with splatting were I don’t, let’s not make it personal. This proposal is even compatible with tuple splatting ! > > > > The proposal rules seem to work and provides great user value. Let’s try to consider this ! > > > > > > > > > > > That proposal, if implemented, would effectively allow `Callback` to be called without arguments in the context of swift4. > > > > > > — > > > > > > very short reply expected - [vsre.info](http://vsre.info) > > > > > > Jérémie Girault > > > > > > On 12 juin 2017 at 22:06:54, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > > > > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > > > > > > > > > @Xiaodi Wu > > > > > > > > Disagree, and we would need the original designer here to help us, but my understanding of the original meaning of tuples-as-arguments is that when I define: > > > > > > > > `func foo(_ arg0: Any, _ arg1: Any) {}` > > > > > > > > I can afterwards “apply” a tuple to a function named `foo` and therefore execute the function on this tuple. > > > > > > > > Calling a function syntax was equivalent to put a tuple next to a function name: > > > > > > > > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, “hello")` is the tuple. > > > > > > > > > > > > > > > > The same way if I have > > > > > > > > `func foo()` > > > > > > > > `foo()` means calling `foo` with argument `()` and there we have our original `Void` > > > > > > > > > > > > > > > > That meaning changed recently due to multiple SE implementations actually. > > > > > > > > > > > > > > Tuples-as-arguments never shipped in any version of Swift, and the ability to "apply" a tuple like that was removed by SE-0029--the original goal was to implement this change in time for Swift 2.2. > > > > > > > > The parenthesis around the call don't have a tuple meaning anymore. Therefore it breaks a lot of code relying on this feature of the language, which was quite elegant, but could not handle advanced functions features. > > > > > > > > > > > > > > Yes, this is an intentional and approved part of SE-0029. The drawbacks were enumerated in that proposal and were deemed acceptable. > > > > > > > > @john: Void can happen easily in parameters due to generics, the easiest example that breaks with swift4 is > > > > > > > > `typealias Callback = (T) -> Void` > > > > > > > > here > > > > > > > > `Callback` which is perfectly reasonable introduces Void in the argument list and forces the caller to introduces an empty partenthesis set when invoking: > > > > > > > > ```swift > > > > > > > > > > > > > > ``` > > > > > > > > let foo: Callback = { } > > > > > > > > foo(()) > > > > > > > > ```swift > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > `Callback = (T) -> Void` refers to a callback that takes exactly one argument. Since argument lists are not tuples, it is not possible to invoke such a callback with zero arguments, or for that matter with two, three, four, or five arguments. > > > > > > > > > > > > > > > That’s were the proposal shines in my opinion: adapting the meaning of Void to the current context of swift4 gives back the language the elegant syntax it had while preserving the type system > > > > > > > > > > > > > > I'm not sure what you mean by this. No change in `Void` can cause a function of type (T) -\> Void to accept zero arguments: it requires one argument of type T. > > > > > > > > > > > > > > > > > > > > > > On 12 juin 2017 at 20:04:18, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > > > > > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@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. > > > > > > > > > > > > > > > > > > > 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@gmail.com](mailto:xiaodi.wu@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@swift.org](mailto:swift-evolution@swift.org) wrote: > > > > > > > > > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution [swift-evolution@swift.org](mailto: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](mailto:swift-evolution@swift.org) > > > > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > > > > > > > > > > ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 7:44pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/30 "2017-06-12T19:44:47Z")
> @xiaodi > I disagree on many points, for example what is the type of x when we type > `let x = *Void` ? That would not be a legal statement. Exploding a tuple is an operation that only makes sense inside an argument list. Likewise `let x = &Void` will not compile. > This is the essence of the problem and this proposition wants to solve > this. > > The regression is due to both reason combined : typealias Void = () AND > SE-0110 > > My proposition is to change the meaning of Void from () to “something > else” that is type-compatible with SE-0110 (and splatting in the future). I'm not sure I understand your motivation. Void is just a typealias. If tomorrow Void meant something else, all functions must still return (), and there is still no implicit tuple splatting. > If you want an example of the changes needed to migrate to swift4, just > look at the 42 files of handling parenthesis PR of RxSwift needed for > swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) Indeed, that's the result of SE-0110; these parentheses are needed because there is no implicit tuple splatting. They would be required even if `Void` did not exist in the language at all. > **···** > > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault \ wrote: > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \>\> swift-evolution@swift.org\> 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. > > > > > > But you can’t deny that SE-0110 has also caused regressions in the use of > > > Void as generic argument because Void is modelled as the empty tuple. > > > > I'm not sure I understand this statement. Void is a synonym for the empty > > tuple, and that hasn't ever changed, so it can't be the root cause of any > > regressions. > > > > > And tuple splatting will not fix those regressions. > > > > How come? If `*` is the splat operator, then it would be legal to call a > > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > > splatting returns in fully implemented form, then it would be legal to call > > it once again with `foo(Void)`. > > > > And contrary to what some people might think, this is not an “edge-case”. > > > > > Most useful monads modelled with generics have good reasons to use Void: > > > > > > \*The Result\ monad:\* Result\ represents the result of an > > > operation with no return value > > > \*The Promise\ monad:\* Promise\ represents the result of an > > > asynchronous operation with no return value > > > \*The Observable\ monad (in functional reactive programming):\* > > > Observable\ represents a stream of events with no values > > > > > > I use all three monads in my code and I’ve had to modify a lot of code > > > when migrating to Swift 4 beta1 because of Void. > > > > Can you give examples of the modifications needed during migration? From > > here, I can only see that the reason any code needs modification is the > > complete removal of implicit tuple splatting. Nothing has changed about > > Void being a synonym for the empty tuple; even if you rename Void, > > functions will still return () by some other name, and unless there is > > tuple splatting in some form, the migration you performed is inevitable. > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 8:06pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/31 "2017-06-12T20:06:33Z")
> @Xiaodi Wu > Disagree, and we would need the original designer here to help us, but my > understanding of the original meaning of tuples-as-arguments is that when I > define: > `func foo(_ arg0: Any, _ arg1: Any) {}` > I can afterwards “apply” a tuple to a function named `foo` and therefore > execute the function on this tuple. > Calling a function syntax was equivalent to put a tuple next to a function > name: > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, > “hello")` is the tuple. > > The same way if I have > `func foo()` > `foo()` means calling `foo` with argument `()` and there we have our > original `Void` > > That meaning changed recently due to multiple SE implementations actually. Tuples-as-arguments never shipped in any version of Swift, and the ability to "apply" a tuple like that was removed by SE-0029--the original goal was to implement this change in time for Swift 2.2. > The parenthesis around the call don't have a tuple meaning anymore. > Therefore it breaks a lot of code relying on this feature of the language, > which was quite elegant, but could not handle advanced functions features. Yes, this is an intentional and approved part of SE-0029. The drawbacks were enumerated in that proposal and were deemed acceptable. > @john: Void can happen easily in parameters due to generics, the easiest > example that breaks with swift4 is > `typealias Callback\ = (T) -\> Void` > here > `Callback\` which is perfectly reasonable introduces Void in the > argument list and forces the caller to introduces an empty partenthesis set > when invoking: > > ```swift > let foo: Callback = { } > foo(()) > > ``` `Callback\ = (T) -\> Void` refers to a callback that takes exactly one argument. Since argument lists are not tuples, it is not possible to invoke such a callback with zero arguments, or for that matter with two, three, four, or five arguments. That’s were the proposal shines in my opinion: adapting the meaning of Void > to the current context of swift4 gives back the language the elegant syntax > it had while preserving the type system I'm not sure what you mean by this. No change in `Void` can cause a function of type (T) -\> Void to accept zero arguments: it requires one argument of type T. > **···** > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault \ wrote: > > On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ \> 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. > > > > 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 > > > Jérémie Girault > > > > > > On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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@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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 8:09pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/32 "2017-06-12T20:09:25Z")
> Exactly, that means that your implementation of the tuple splatting > operator is out of the type system. > Can you expose it’s signature ? > > If you want the operator to be “compiler-magic” it’s possible. Yes, it requires compiler support. > **···** > > On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault \ wrote: > > > This proposal is an alternate solution. > > > > My point is that updating Void according to this proposal would > > - preserve the type system in a better way > > - have better source compatibility (in time for swift 4 release, were we > > probably won’t see tuple splatting) > > - also keep the elegant original syntax of swift instead of stacking > > parenthesis > > > > The impact for code writers would be minimized on time for swift 4 release > > > > As for return values: this proposition does not intend to change the how > > return value of Void functions works. > > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault \ gmail.com\> wrote: > > > > > @xiaodi > > > I disagree on many points, for example what is the type of x when we type > > > `let x = *Void` ? > > > > That would not be a legal statement. Exploding a tuple is an operation > > that only makes sense inside an argument list. Likewise `let x = &Void` > > will not compile. > > > > > This is the essence of the problem and this proposition wants to solve > > > this. > > > > > > The regression is due to both reason combined : typealias Void = () AND > > > SE-0110 > > > > > > My proposition is to change the meaning of Void from () to “something > > > else” that is type-compatible with SE-0110 (and splatting in the future). > > > > I'm not sure I understand your motivation. Void is just a typealias. If > > tomorrow Void meant something else, all functions must still return (), and > > there is still no implicit tuple splatting. > > > > > If you want an example of the changes needed to migrate to swift4, just > > > look at the 42 files of handling parenthesis PR of RxSwift needed for > > > swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) > > > > Indeed, that's the result of SE-0110; these parentheses are needed because > > there is no implicit tuple splatting. They would be required even if `Void` > > did not exist in the language at all. > > > > > — > > > very short reply expected - vsre.info > > > Jérémie Girault > > > > > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \>\>\> swift-evolution@swift.org\> 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. > > > > > > > > But you can’t deny that SE-0110 has also caused regressions in the use > > > > of Void as generic argument because Void is modelled as the empty tuple. > > > > > > I'm not sure I understand this statement. Void is a synonym for the empty > > > tuple, and that hasn't ever changed, so it can't be the root cause of any > > > regressions. > > > > > > > And tuple splatting will not fix those regressions. > > > > > > How come? If `*` is the splat operator, then it would be legal to call a > > > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > > > splatting returns in fully implemented form, then it would be legal to call > > > it once again with `foo(Void)`. > > > > > > And contrary to what some people might think, this is not an “edge-case”. > > > > > > > Most useful monads modelled with generics have good reasons to use Void: > > > > > > > > \*The Result\ monad:\* Result\ represents the result of an > > > > operation with no return value > > > > \*The Promise\ monad:\* Promise\ represents the result of an > > > > asynchronous operation with no return value > > > > \*The Observable\ monad (in functional reactive programming):\* Observable\ > > > > represents a stream of events with no values > > > > > > > > I use all three monads in my code and I’ve had to modify a lot of code > > > > when migrating to Swift 4 beta1 because of Void. > > > > > > Can you give examples of the modifications needed during migration? From > > > here, I can only see that the reason any code needs modification is the > > > complete removal of implicit tuple splatting. Nothing has changed about > > > Void being a synonym for the empty tuple; even if you rename Void, > > > functions will still return () by some other name, and unless there is > > > tuple splatting in some form, the migration you performed is inevitable. > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jeremie\_Girault](https://avatars.discourse-cdn.com/v4/letter/j/8e7dd6/32.png) [@Jeremie\_Girault](https://forums.swift.org/u/Jeremie_Girault)\ **Post date:** [June 12, 2017, 10:25pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/33 "2017-06-12T22:25:36Z")
> **···** > > — > > very short reply expected - [vsre.info](http://vsre.info) > > Jérémie Girault > > On 12 juin 2017 at 23:56:37, Xiaodi Wu ([xiaodi.wu@gmail.com](mailto:xiaodi.wu@gmail.com)) wrote: > > > On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault [jeremie.girault@gmail.com](mailto:jeremie.girault@gmail.com) wrote: > > > > > - 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) -> Void` -\> `Callback` 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 ? > > > > > > Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to distinguish an argument list `(Void)` from an argument list `()`. This does cause some verbosity where previously users relied on implicit tuple splatting. Ideally, we would bring back some syntactic sugar to make this more ergonomic. But, whether or not the spelling is made more user-friendly, the point here is that _everybody_ should care about this `Void` argument. > > It is still be typechecked and appropriate errors should be reported to the user so _nobody_ will ignore it. > > But with the proposal the code will be striped out of Void arguments at compile-time. I think it's a win for the developer on a lot of grounds. The fact that this proposal integrates with the type-system is also important. > > If you are not comfortable about Void being stripped, we can also discuss alternatives: someone was suggesting me that it would be possible to replace : > > ```swift > > func foo(t: T, u: U) -> V { > > // do something with t and u > > // return some V > > } > > ``` > > with > > ```swift > > func foo(u: Int) -> String { let t = () > > // do something with t and u > > // return some V > > } > > ``` > > or > > ```swift > > func foo(t: Void = (), u: Int) -> String { > > // do something with t and u > > // return some V > > } > > ``` > > I don’t know what you would consider more effective or elegant (at an implementation level) but it’s the same result for the developper. > > > > > > > My point here is that `Void` should be “striped” by “reducing” argument list signatures. > > > > — > > > > very short reply expected - [vsre.info](http://vsre.info) > > > > Jérémie Girault > > > > On 12 juin 2017 at 19:15:18, John McCall ([rjmccall@apple.com](mailto:rjmccall@apple.com)) wrote: > > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution [swift-evolution@swift.org](mailto: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. > > > ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 8:34pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/34 "2017-06-12T20:34:24Z")
> I invite you to read the proposal rules again with a fresh mindset and > benevolence spirit. > It’s my first one and may not be very clear but the rules are > straightforward. > > Especially try to forget that Void is a tuple or anything. > Void is Nothing in the programmer’s mind. An instance of Void shouldn’t > even exist. Sorry, that's not correct. Void is what's called Unit in other languages. It exists. That is why functions with "no return value" return Void. OTOH, Never does not exist. This discussion was had in great detail during the naming debate over Never. > The proposed meaning of Void is to be a “lack” of arguments. It means that > each “Void” argument reduces the arity of the function by one, at its exact > position. Especially look at the canonical signature definition, and the > proposed rules of reduction. I don't understand why you propose to name this new idea "Void". You're proposing something that's not even a lack of an argument, but an anti-argument, like anti-matter! I'm not sure I understand why this is necessary. It seems to be a very strange workaround for one specific issue arising from disallowing implicit tuple splatting. > **···** > > On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault \ wrote: > > > That proposal, if implemented, would effectively allow `Callback\` to > > be called without arguments in the context of swift4. > > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault \< \> jeremie.girault@gmail.com\> wrote: > > > > > @Xiaodi Wu > > > Disagree, and we would need the original designer here to help us, but my > > > understanding of the original meaning of tuples-as-arguments is that when I > > > define: > > > `func foo(_ arg0: Any, _ arg1: Any) {}` > > > I can afterwards “apply” a tuple to a function named `foo` and therefore > > > execute the function on this tuple. > > > Calling a function syntax was equivalent to put a tuple next to a > > > function name: > > > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, > > > “hello")` is the tuple. > > > > > > The same way if I have > > > `func foo()` > > > `foo()` means calling `foo` with argument `()` and there we have our > > > original `Void` > > > > > > That meaning changed recently due to multiple SE implementations actually. > > > > Tuples-as-arguments never shipped in any version of Swift, and the ability > > to "apply" a tuple like that was removed by SE-0029--the original goal was > > to implement this change in time for Swift 2.2. > > > > > The parenthesis around the call don't have a tuple meaning anymore. > > > Therefore it breaks a lot of code relying on this feature of the language, > > > which was quite elegant, but could not handle advanced functions features. > > > > Yes, this is an intentional and approved part of SE-0029. The drawbacks > > were enumerated in that proposal and were deemed acceptable. > > > > > @john: Void can happen easily in parameters due to generics, the easiest > > > example that breaks with swift4 is > > > `typealias Callback\ = (T) -\> Void` > > > here > > > `Callback\` which is perfectly reasonable introduces Void in the > > > argument list and forces the caller to introduces an empty partenthesis set > > > when invoking: > > > > > > ```swift > > > let foo: Callback = { } > > > foo(()) > > > > > > ``` > > > > `Callback\ = (T) -\> Void` refers to a callback that takes exactly one > > argument. Since argument lists are not tuples, it is not possible to invoke > > such a callback with zero arguments, or for that matter with two, three, > > four, or five arguments. > > > > That’s were the proposal shines in my opinion: adapting the meaning of > > > > > Void to the current context of swift4 gives back the language the elegant > > > syntax it had while preserving the type system > > > > I'm not sure what you mean by this. No change in `Void` can cause a > > function of type (T) -\> Void to accept zero arguments: it requires one > > argument of type T. > > > > On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ \>\> 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. > > > > > > 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 > > > > Jérémie Girault > > > > > > > > On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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@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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 9:27pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/35 "2017-06-12T21:27:10Z")
> — > very short reply expected - vsre.info > Jérémie Girault > > > I invite you to read the proposal rules again with a fresh mindset and > > benevolence spirit. > > It’s my first one and may not be very clear but the rules are > > straightforward. > > > > Especially try to forget that Void is a tuple or anything. > > Void is Nothing in the programmer’s mind. An instance of Void shouldn’t > > even exist. > > Sorry, that's not correct. Void is what's called Unit in other languages. > It exists. That is why functions with "no return value" return Void. OTOH, > Never does not exist. This discussion was had in great detail during the > naming debate over Never. > > Let’s put facts in front of correctness assertions. Is Void = Unit in C or > c++ ? can you create instances of void in java ? you have Void for > generics. [Unit type - Wikipedia](https://en.wikipedia.org/wiki/Unit_type) Sorry, I don't understand your line of argumentation. Fact: in Swift, Void is the name of the unit type. Are you objecting to the naming of the unit type in Swift? Do you want the unit type to have other features? Is there some other way of modeling the unit type other than a tuple of arity 0 that you prefer? > And if you look at assembly, sending void or returning void actually means > "nothing to push on the stack / nothing to pop”. Seems like having this > stripping on signatures at compile-time could be great ! > > Actually, in my opinion we could discuss naming when we agree that the > mechanism works, using this name is just a way to not impact the developer > with code changes. > > So either we agree on the fact that the mechanism works and we can move on > to naming, or we get back on the topic : do you see a flaw in the proposal > rules ? It elegantly transforms signature arity and provides the programmer > a natural syntax to express it’s code. I have read your proposal three times, but I do not understand what it is proposing, in part because your proposal contains factual errors in the premises. For instance, it claims repeatedly that Void is a typealias for () because of something to do with argument lists, which is not true. It is therefore unclear to me what it is you are proposing to do and what is motivating such a proposal. All I am saying is that, in previous conversations on this list, people who actually do the work of implementing features in the compiler have stated that `typealias Void = ()` is a fait accompli. With that as a starting point, what do you propose to do? > **···** > > On Mon, Jun 12, 2017 at 4:10 PM, Jérémie Girault \ wrote: > > > On 12 juin 2017 at 22:34:45, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault \ gmail.com\> wrote: > > > > The proposed meaning of Void is to be a “lack” of arguments. It means > > > that each “Void” argument reduces the arity of the function by one, at its > > > exact position. Especially look at the canonical signature definition, and > > > the proposed rules of reduction. > > > > I don't understand why you propose to name this new idea "Void". You're > > proposing something that's not even a lack of an argument, but an > > anti-argument, like anti-matter! I'm not sure I understand why this is > > necessary. It seems to be a very strange workaround for one specific issue > > arising from disallowing implicit tuple splatting. > > > > Look at other languages, when you put Void in functions in C or java, do > > you need to add a value ? Ease of use is important. > > > > You imply that I disagree with splatting were I don’t, let’s not make it > > personal. This proposal is even compatible with tuple splatting ! > > > > The proposal rules seem to work and provides great user value. Let’s try > > to consider this ! > > > > > That proposal, if implemented, would effectively allow `Callback\` > > > to be called without arguments in the context of swift4. > > > > > > — > > > very short reply expected - vsre.info > > > Jérémie Girault > > > > > > On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault \\> gmail.com\> wrote: > > > > > > > @Xiaodi Wu > > > > Disagree, and we would need the original designer here to help us, but > > > > my understanding of the original meaning of tuples-as-arguments is that > > > > when I define: > > > > `func foo(_ arg0: Any, _ arg1: Any) {}` > > > > I can afterwards “apply” a tuple to a function named `foo` and therefore > > > > execute the function on this tuple. > > > > Calling a function syntax was equivalent to put a tuple next to a > > > > function name: > > > > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, > > > > “hello")` is the tuple. > > > > > > > > The same way if I have > > > > `func foo()` > > > > `foo()` means calling `foo` with argument `()` and there we have our > > > > original `Void` > > > > > > > > That meaning changed recently due to multiple SE implementations > > > > actually. > > > > > > Tuples-as-arguments never shipped in any version of Swift, and the > > > ability to "apply" a tuple like that was removed by SE-0029--the original > > > goal was to implement this change in time for Swift 2.2. > > > > > > > The parenthesis around the call don't have a tuple meaning anymore. > > > > Therefore it breaks a lot of code relying on this feature of the language, > > > > which was quite elegant, but could not handle advanced functions features. > > > > > > Yes, this is an intentional and approved part of SE-0029. The drawbacks > > > were enumerated in that proposal and were deemed acceptable. > > > > > > > @john: Void can happen easily in parameters due to generics, the easiest > > > > example that breaks with swift4 is > > > > `typealias Callback\ = (T) -\> Void` > > > > here > > > > `Callback\` which is perfectly reasonable introduces Void in the > > > > argument list and forces the caller to introduces an empty partenthesis set > > > > when invoking: > > > > > > > > ```swift > > > > let foo: Callback = { } > > > > foo(()) > > > > > > > > ``` > > > > > > `Callback\ = (T) -\> Void` refers to a callback that takes exactly one > > > argument. Since argument lists are not tuples, it is not possible to invoke > > > such a callback with zero arguments, or for that matter with two, three, > > > four, or five arguments. > > > > > > That’s were the proposal shines in my opinion: adapting the meaning of > > > > > > > Void to the current context of swift4 gives back the language the elegant > > > > syntax it had while preserving the type system > > > > > > I'm not sure what you mean by this. No change in `Void` can cause a > > > function of type (T) -\> Void to accept zero arguments: it requires one > > > argument of type T. > > > > > > On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ \>\>\> 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. > > > > > > > > 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 > > > > > Jérémie Girault > > > > > > > > > > On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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@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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 10:38pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/36 "2017-06-12T22:38:24Z")
> — > very short reply expected - vsre.info > Jérémie Girault > > > - 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) -\> Void` -\> `Callback\` 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 ? > > Ah, I see. The purpose of SE-0029...SE-0110 was to make it possible to > distinguish an argument list `(Void)` from an argument list `()`. This does > cause some verbosity where previously users relied on implicit tuple > splatting. Ideally, we would bring back some syntactic sugar to make this > more ergonomic. But, whether or not the spelling is made more > user-friendly, the point here is that \_everybody\_ should care about this > `Void` argument. > > It is still be typechecked and appropriate errors should be reported to > the user so \_nobody\_ will ignore it. > > But with the proposal the code will be striped out of Void arguments at > compile-time. I think it's a win for the developer on a lot of grounds. The > fact that this proposal integrates with the type-system is also important. > > If you are not comfortable about Void being stripped, we can also discuss > alternatives: someone was suggesting me that it would be possible to > replace : > > ```swift > > func foo(t: T, u: U) -> V { > > // do something with t and u > > // return some V > > } > > ``` > > with > > ```swift > > func foo(u: Int) -> String { let t = () > > // do something with t and u > > // return some V > > } > > ``` > > or > > ```swift > > func foo(t: Void = (), u: Int) -> String { > > // do something with t and u > > // return some V > > } > > ``` > > I don’t know what you would consider more effective or elegant (at an > implementation level) but it’s the same result for the developper. What is the goal of such changes? Is it to allow you to write `foo()` instead of `foo(())` for a function `foo` of type `(T) -\> Void`? If so, then I think what you're seeking to do is reverse SE-0066 (as Vladimir points out), which explicits details how it's is an intentional change to require such a spelling. I think you're starting from the premise that this is unintended or undesirable, when in fact it is deliberate and approved. It is also, unless I'm mistaken, not the issue that was raised initially with respect to SE-0110, which had to do with the extra boilerplate of destructuring a tuple inside a closure, something that was not so obvious before implementation. My point here is that `Void` should be “striped” by “reducing” argument > **···** > > On Mon, Jun 12, 2017 at 5:25 PM, Jérémie Girault \ wrote: > > > On 12 juin 2017 at 23:56:37, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault \ .com\> wrote: > > > > > list signatures. > > > > > > — > > > very short reply expected - vsre.info > > > Jérémie Girault > > > > > > On 12 juin 2017 at 19:15:18, John McCall (rjmccall@apple.com) 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. ---
**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\ **Post date:** [June 12, 2017, 7:49pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/37 "2017-06-12T19:49:25Z")
Just adding this here for reference: func foo(\_: Void) {} func bar() {} // All these compile in Swift 3: foo() foo(()) bar() bar(()) // But only these two compile in Swift 4: foo(()) bar() > **···** > > On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault \< \> jeremie.girault@gmail.com\> wrote: > > > > > @xiaodi > > > I disagree on many points, for example what is the type of x when we type > > > `let x = *Void` ? > > > > That would not be a legal statement. Exploding a tuple is an operation > > that only makes sense inside an argument list. Likewise `let x = &Void` > > will not compile. > > > > > This is the essence of the problem and this proposition wants to solve > > > this. > > > > > > The regression is due to both reason combined : typealias Void = () AND > > > SE-0110 > > > > > > My proposition is to change the meaning of Void from () to “something > > > else” that is type-compatible with SE-0110 (and splatting in the future). > > > > I'm not sure I understand your motivation. Void is just a typealias. If > > tomorrow Void meant something else, all functions must still return (), and > > there is still no implicit tuple splatting. > > > > > If you want an example of the changes needed to migrate to swift4, just > > > look at the 42 files of handling parenthesis PR of RxSwift needed for > > > swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) > > > > Indeed, that's the result of SE-0110; these parentheses are needed because > > there is no implicit tuple splatting. They would be required even if `Void` > > did not exist in the language at all. > > > > > — > > > very short reply expected - vsre.info > > > Jérémie Girault > > > > > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \>\>\> swift-evolution@swift.org\> 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. > > > > > > > > But you can’t deny that SE-0110 has also caused regressions in the use > > > > of Void as generic argument because Void is modelled as the empty tuple. > > > > > > I'm not sure I understand this statement. Void is a synonym for the empty > > > tuple, and that hasn't ever changed, so it can't be the root cause of any > > > regressions. > > > > > > > And tuple splatting will not fix those regressions. > > > > > > How come? If `*` is the splat operator, then it would be legal to call a > > > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > > > splatting returns in fully implemented form, then it would be legal to call > > > it once again with `foo(Void)`. > > > > > > And contrary to what some people might think, this is not an “edge-case”. > > > > > > > Most useful monads modelled with generics have good reasons to use Void: > > > > > > > > \*The Result\ monad:\* Result\ represents the result of an > > > > operation with no return value > > > > \*The Promise\ monad:\* Promise\ represents the result of an > > > > asynchronous operation with no return value > > > > \*The Observable\ monad (in functional reactive programming):\* > > > > Observable\ represents a stream of events with no values > > > > > > > > I use all three monads in my code and I’ve had to modify a lot of code > > > > when migrating to Swift 4 beta1 because of Void. > > > > > > Can you give examples of the modifications needed during migration? From > > > here, I can only see that the reason any code needs modification is the > > > complete removal of implicit tuple splatting. Nothing has changed about > > > Void being a synonym for the empty tuple; even if you rename Void, > > > functions will still return () by some other name, and unless there is > > > tuple splatting in some form, the migration you performed is inevitable. > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\ **Post date:** [June 12, 2017, 8:17pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/38 "2017-06-12T20:17:30Z")
I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule. And it is not a step towards resolving the many parentheses-related inconsistencies that still remain. Here is an example of one such remaining inconsistency, it's still in (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2) and 4: func foo() -\> Void {} func foo(\_: Void) -\> Void {} // This is OK func bar(fn: () -\> Void) {} func bar(fn: (\_: Void) -\> Void) {} // ERR: Invalid redecl. I think the least surprising behavior here would be no error, rather than two. The current behavior with one error is very surprising. > **···** > > On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault \< \> jeremie.girault@gmail.com\> wrote: > > > > > Exactly, that means that your implementation of the tuple splatting > > > operator is out of the type system. > > > Can you expose it’s signature ? > > > > > > If you want the operator to be “compiler-magic” it’s possible. > > > > Yes, it requires compiler support. > > > > > This proposal is an alternate solution. > > > > > > My point is that updating Void according to this proposal would > > > - preserve the type system in a better way > > > - have better source compatibility (in time for swift 4 release, were we > > > probably won’t see tuple splatting) > > > - also keep the elegant original syntax of swift instead of stacking > > > parenthesis > > > > > > The impact for code writers would be minimized on time for swift 4 release > > > > > > As for return values: this proposition does not intend to change the how > > > return value of Void functions works. > > > > > > — > > > very short reply expected - vsre.info > > > Jérémie Girault > > > > > > On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault \\> .com\> wrote: > > > > > > > @xiaodi > > > > I disagree on many points, for example what is the type of x when we > > > > type `let x = *Void` ? > > > > > > That would not be a legal statement. Exploding a tuple is an operation > > > that only makes sense inside an argument list. Likewise `let x = &Void` > > > will not compile. > > > > > > > This is the essence of the problem and this proposition wants to solve > > > > this. > > > > > > > > The regression is due to both reason combined : typealias Void = () AND > > > > SE-0110 > > > > > > > > My proposition is to change the meaning of Void from () to “something > > > > else” that is type-compatible with SE-0110 (and splatting in the future). > > > > > > I'm not sure I understand your motivation. Void is just a typealias. If > > > tomorrow Void meant something else, all functions must still return (), and > > > there is still no implicit tuple splatting. > > > > > > > If you want an example of the changes needed to migrate to swift4, just > > > > look at the 42 files of handling parenthesis PR of RxSwift needed for > > > > swift4 upgrade : [Compile under Swift 4 by volodg · Pull Request #1282 · ReactiveX/RxSwift · GitHub](https://github.com/ReactiveX/RxSwift/pull/1282/files) > > > > > > Indeed, that's the result of SE-0110; these parentheses are needed > > > because there is no implicit tuple splatting. They would be required even > > > if `Void` did not exist in the language at all. > > > > > > > — > > > > very short reply expected - vsre.info > > > > Jérémie Girault > > > > > > > > On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu@gmail.com) wrote: > > > > > > > > On Mon, Jun 12, 2017 at 2:05 PM, David Hart \ wrote: > > > > > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \< \>\>\>\> swift-evolution@swift.org\> 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. > > > > > > > > > > But you can’t deny that SE-0110 has also caused regressions in the use > > > > > of Void as generic argument because Void is modelled as the empty tuple. > > > > > > > > I'm not sure I understand this statement. Void is a synonym for the > > > > empty tuple, and that hasn't ever changed, so it can't be the root cause of > > > > any regressions. > > > > > > > > > And tuple splatting will not fix those regressions. > > > > > > > > How come? If `*` is the splat operator, then it would be legal to call a > > > > function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple > > > > splatting returns in fully implemented form, then it would be legal to call > > > > it once again with `foo(Void)`. > > > > > > > > And contrary to what some people might think, this is not an > > > > > > > > > “edge-case”. Most useful monads modelled with generics have good reasons to > > > > > use Void: > > > > > > > > > > \*The Result\ monad:\* Result\ represents the result of an > > > > > operation with no return value > > > > > \*The Promise\ monad:\* Promise\ represents the result of an > > > > > asynchronous operation with no return value > > > > > \*The Observable\ monad (in functional reactive programming):\* Observable\ > > > > > represents a stream of events with no values > > > > > > > > > > I use all three monads in my code and I’ve had to modify a lot of code > > > > > when migrating to Swift 4 beta1 because of Void. > > > > > > > > Can you give examples of the modifications needed during migration? From > > > > here, I can only see that the reason any code needs modification is the > > > > complete removal of implicit tuple splatting. Nothing has changed about > > > > Void being a synonym for the empty tuple; even if you rename Void, > > > > functions will still return () by some other name, and unless there is > > > > tuple splatting in some form, the migration you performed is inevitable. > > > > > > > > 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [June 12, 2017, 9:53pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/39 "2017-06-12T21:53:52Z")
>     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. > **···** > > On 12.06.2017 21:04, Xiaodi Wu via swift-evolution wrote: > > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ \\> wrote: > > >     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](http://vsre.info)\> > >     Jérémie Girault > > > >     On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu@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 \>\> \\> wrote: > > > > > > >         On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution \>\>\> \\> 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Anders](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Anders](https://forums.swift.org/u/Anders)\ **Post date:** [June 12, 2017, 7:12pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/40 "2017-06-12T19:12:47Z")
Just want to note that `Void` aka empty tuple is still constructible, so it doesn’t exactly mean “no value” but only “an occurrence without a substantial value”, especially when a stream of voids in FRP can be used as a trigger. To exactly represent “no value”, inhabitable types like `Never` are better as they statically guarantee that no instance would ever exist. Regards, Anders > **···** > > > On 13 Jun 2017, at 3:05 AM, David Hart via swift-evolution \ wrote: > > > > > On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution \ 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. > > > > But you can’t deny that SE-0110 has also caused regressions in the use of Void as generic argument because Void is modelled as the empty tuple. And tuple splatting will not fix those regressions. > > > > And contrary to what some people might think, this is not an “edge-case”. Most useful monads modelled with generics have good reasons to use Void: > > > > The Result\ monad: Result\ represents the result of an operation with no return value > > The Promise\ monad: Promise\ represents the result of an asynchronous operation with no return value > > The Observable\ monad (in functional reactive programming): Observable\ represents a stream of events with no values > > > > I use all three monads in my code and I’ve had to modify a lot of code when migrating to Swift 4 beta1 because of Void. > > > > David. > > > > > On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution \ wrote: > > > > > > > On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution \ 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](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Previous page](https://forums.swift.org/t/proposal-change-void-meaning/6100.md?page=1) [Next page](https://forums.swift.org/t/proposal-change-void-meaning/6100.md?page=3)