# \[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:** 1
**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:48am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/1 "2017-06-12T08:48:55Z")
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. If this is no more the case, then it’s no more a reason to keep Void as an empty tuple. I think that by having a few rules around tuples of cardinality 0 and 1 and also arguments list, we could greatly improve source compatibility and keep a lot of what makes swift great when using functional style and generics. I drafted a proposal that would allow more source compatibility and type consistency and would enjoy discussing it with you, in order to improve it : [https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md](https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md) Let me know what you think about it, > **···** > > — > very short reply expected - vsre.info > Jérémie Girault ---
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [June 12, 2017, 9:01am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/2 "2017-06-12T09:01:46Z")
> The reason of this is that arguments were initially considered as tuple. If this is no more the case, then it’s no more a reason to keep Void as an empty tuple. Didn't have the time to look into the draft yet, but at first thought, your idea makes much sense to me — although my current standpoint is more moderate: At least it's time to question Void as an empty tuple, and I appreciate discussions about cleaning up fundamentals of the language (hope that I can add something later this week). ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 12, 2017, 5:15pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/3 "2017-06-12T17:15:15Z")
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. > **···** > > > 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. ---
**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, 11:21am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/4 "2017-06-12T11:21:16Z")
> 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. If this is no more the case, then it’s no more a reason to keep Void as an empty tuple. Could you clarify, do yo propose to change meaning of this code: func foo() {} from "implicitly returns Void" to "returns nothing" ? So, this valid Swift 3 and Swift 4 code will be invalid: func foo(){} let x : Void = foo() ? In this case I believe your proposal introduces new source breaking change that makes transition from Swift 3 to Swift 4 even more difficult for some code. There were short discussions in this list if implicit Void return should also be removed and IIRC was rejected by common opinion or by some one's authoritative opinion. Also, I'd like to suggest you to read text of SE-0066 proposal, where you can see that it clearly separated functions accepting Void parameter and accepting no parameters. So, IMO you should also refer to SE-0066 proposal in your text and it seems(correct me if I understood your proposal incorrectly) you should propose to revisit SE-0066 in this detail. Vladimir. > **···** > > On 12.06.2017 11:48, Jérémie Girault via swift-evolution wrote: > > > I think that by having a few rules around tuples of cardinality 0 and 1 and also arguments list, we could greatly improve source compatibility and keep a lot of what makes swift great when using functional style and generics. > > > > I drafted a proposal that would allow more source compatibility and type consistency and would enjoy discussing it with you, in order to improve it : > > > > [https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md](https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md) > > > > Let me know what you think about it, > > > > — > > very short reply expected - vsre.info \<[http://vsre.info](http://vsre.info)\> > > Jérémie Girault > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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:** ![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, 4:57pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/5 "2017-06-12T16:57:35Z")
Hi there, While I also feel it's kind of odd to have Void defined as the empty tuple with the latest changes like SE-0110, I also see issues with your proposal. For example, your change will cause ambiguity when calling generic functions and functions that contain all the arguments but the generic one: func foo\(\_ a: T) {} func foo() {} foo() // are we calling foo() or foo\() > **···** > > > On 12 Jun 2017, at 10:48, 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. If this is no more the case, then it’s no more a reason to keep Void as an empty tuple. > > > > I think that by having a few rules around tuples of cardinality 0 and 1 and also arguments list, we could greatly improve source compatibility and keep a lot of what makes swift great when using functional style and generics. > > > > I drafted a proposal that would allow more source compatibility and type consistency and would enjoy discussing it with you, in order to improve it : > > > > [https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md](https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md) > > > > Let me know what you think about it, > > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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, 5:03pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/6 "2017-06-12T17:03:49Z")
I have just had a quick look but I'm interested in what you think about the following example, which currently behaves like the comments say: func foo\(\_ fn: (A) -\> Void) {} func fnA() {} func fnB(\_ a: Int) {} func fnC(\_ a: Int, \_ b: Int) {} foo(fnA) // Compiles in Swift 3, error in Swift 4 foo(fnB) // Compiles in both Swift 3 and Swift 4 foo(fnC) // Compiles in Swift 3, error in Swift 4 > From what I read in your proposal, I assume that you want foo(fnA) to compile in both. But if so, don't you think foo(fnC) should also compile in both? /Jens > **···** > > On Mon, Jun 12, 2017 at 10: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. If this is no > > more the case, then it’s no more a reason to keep Void as an empty tuple. > > > > I think that by having a few rules around tuples of cardinality 0 and 1 > > and also arguments list, we could greatly improve source compatibility and > > keep a lot of what makes swift great when using functional style and > > generics. > > > > I drafted a proposal that would allow more source compatibility and type > > consistency and would enjoy discussing it with you, in order to improve it > > : > > > > [https://github.com/jeremiegirault/swift-evolution/blob/master/](https://github.com/jeremiegirault/swift-evolution/blob/master/) > > proposals/NNNN-flatten-void.md > > > > Let me know what you think about it, > > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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, 4:45pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/7 "2017-06-12T16:45:29Z")
Interesting use-case, Actually, after double-checking the rules I proposed, it seem to be possible, to do `let x: Void = foo()` but all “pseudo-instances” of Void would be stripped at compile time. Therefore this does not introduces source-breaking changes even if this use case is quite convoluted (but could happen easily in generics case). I do not propose that implicit Void should be removed, it’s more of a sample of the “magic” around Void. My proposition consist to “extend" this magic a bit using given rules and in consequence, allow more source-compatibility, readability. I just read the SE-0066 and don’t see any conflicting point (nor relation) with this proposition. > If you see any conflicting point, I would be interested to know which one specifically. > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 13:21:24, Vladimir.S (svabox@gmail.com) wrote: > > On 12.06.2017 11:48, 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. If this is no more the > > case, then > > > it’s no more a reason to keep Void as an empty tuple. > > Could you clarify, do yo propose to change meaning of this code: > func foo() {} > from "implicitly returns Void" to "returns nothing" ? > > So, this valid Swift 3 and Swift 4 code will be invalid: > > func foo(){} > let x : Void = foo() > ? > > In this case I believe your proposal introduces new source breaking change > that makes > transition from Swift 3 to Swift 4 even more difficult for some code. > > There were short discussions in this list if implicit Void return should > also be > removed and IIRC was rejected by common opinion or by some one's > authoritative opinion. > > Also, I'd like to suggest you to read text of SE-0066 proposal, where you > can see > that it clearly separated functions accepting Void parameter and accepting > no > parameters. So, IMO you should also refer to SE-0066 proposal in your text > and it > seems(correct me if I understood your proposal incorrectly) you should > propose to > revisit SE-0066 in this detail. > > Vladimir. > > > I think that by having a few rules around tuples of cardinality 0 and 1 > > and also > > > arguments list, we could greatly improve source compatibility and keep a > > lot of what > > > makes swift great when using functional style and generics. > > > > I drafted a proposal that would allow more source compatibility and type > > consistency > > > and would enjoy discussing it with you, in order to improve it : > > [https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md](https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md) > > > Let me know what you think about it, > > > > — > > very short reply expected - vsre.info \<[http://vsre.info](http://vsre.info)\> > > Jérémie Girault > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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, 5:21pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/8 "2017-06-12T17:21:38Z")
At the moment I’m only considering the zero-cardinality tuple and don’t want to address the implicit destructuring issues. Therefore you are right with foo(fnA) and foo(fnB); but foo(fnC) won’t compile. My goal is to add small propositions with simple rules to have better compatilibty and a more natural way to approach the code. This could be addressed by another proposition (not on this topic) > **···** > > — > very short reply expected - vsre.info > Jérémie Girault > > On 12 juin 2017 at 19:03:51, Jens Persson (jens@bitcycle.com) wrote: > > I have just had a quick look but I'm interested in what you think about the > following example, which currently behaves like the comments say: > > func foo\(\_ fn: (A) -\> Void) {} > func fnA() {} > func fnB(\_ a: Int) {} > func fnC(\_ a: Int, \_ b: Int) {} > foo(fnA) // Compiles in Swift 3, error in Swift 4 > foo(fnB) // Compiles in both Swift 3 and Swift 4 > foo(fnC) // Compiles in Swift 3, error in Swift 4 > > > From what I read in your proposal, I assume that you want foo(fnA) to > > compile in both. > But if so, don't you think foo(fnC) should also compile in both? > > /Jens > > On Mon, Jun 12, 2017 at 10: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. If this is no > > more the case, then it’s no more a reason to keep Void as an empty tuple. > > > > I think that by having a few rules around tuples of cardinality 0 and 1 > > and also arguments list, we could greatly improve source compatibility and > > keep a lot of what makes swift great when using functional style and > > generics. > > > > I drafted a proposal that would allow more source compatibility and type > > consistency and would enjoy discussing it with you, in order to improve it > > : > > > > [https://github.com/jeremiegirault/swift-evolution/blob/master/](https://github.com/jeremiegirault/swift-evolution/blob/master/) > > proposals/NNNN-flatten-void.md > > > > Let me know what you think about it, > > > > — > > very short reply expected - vsre.info > > Jérémie Girault > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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, 5:34pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/9 "2017-06-12T17:34:09Z")
Still I don’t understand your point about SE-0066, and maybe we are not talking about the same thing ? This new proposal basically tries to address that in Swift4 : `func foo() {}` is different from `func foo(Void) {}`, and cannot be coerced. That does not seem a natural thing from the developer point of view. This is a consequence of 1/ SE-0110 specifying that function arguments-as-tuple exist no more and are differentiated from tuple-as-arguments 2/ the fact that Void is historically a tuple This new proposition tries to address regressions happening when arguments are “Void” only. > **···** > > — > 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:** ![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:47pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/10 "2017-06-12T21:47:42Z")
- 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 ? My point here is that `Void` should be “striped” by “reducing” argument 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:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 5:25pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/11 "2017-06-12T17:25:19Z")
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:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [June 12, 2017, 10:42pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/12 "2017-06-12T22:42:03Z")
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. 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, 5:44pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/13 "2017-06-12T17:44:58Z")
Void was the empty tuple because arguments were tuples. So no arguments meant empty tuple. If we consider the empty tuple to be an argument, then the type for the type of empty tuple should be `Unit` Void, however, seem naturally fitted for the absence of argument. Should `func foo(Void)` be different from `func foo()`? I don’t think so. But different from `func foo(Unit)` ? Yes ! My point here is that we probably won’t have splatting for swift4. But if we consider the type system as a guide, we can consider 3 simple set of rules and restore almost 100% source compatibility while keeping the improvement of SE-0110 - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4 (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:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [June 12, 2017, 5:57pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/14 "2017-06-12T17:57:43Z")
To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've not come across it being used as analog for something like the empty tuple. - Dave Sweeris > **···** > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution \ wrote: > > > > Void was the empty tuple because arguments were tuples. So no arguments meant empty tuple. > > > > If we consider the empty tuple to be an argument, then the type for the type of empty tuple should be `Unit` > > > > Void, however, seem naturally fitted for the absence of argument. > > > > Should `func foo(Void)` be different from `func foo()`? I don’t think so. But different from `func foo(Unit)` ? Yes ! ---
**Author:** ![bob](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@bob](https://forums.swift.org/u/bob)\ **Post date:** [June 12, 2017, 6:01pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/15 "2017-06-12T18:01:39Z")
The name Unit is used in Foundation for that exact meaning: [https://developer.apple.com/documentation/foundation/unit\](https://developer.apple.com/documentation/foundation/unit%5C). I like the name `Nothing` for the empty tuple. func foo(Nothing) {} > **···** > > > On Jun 12, 2017, at 1:57 PM, David Sweeris via swift-evolution \ wrote: > > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution \\> wrote: > > > > > Void was the empty tuple because arguments were tuples. So no arguments meant empty tuple. > > > > > > If we consider the empty tuple to be an argument, then the type for the type of empty tuple should be `Unit` > > > > > > Void, however, seem naturally fitted for the absence of argument. > > > > > > Should `func foo(Void)` be different from `func foo()`? I don’t think so. But different from `func foo(Unit)` ? Yes ! > > > > To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've not come across it being used as analog for something like the empty tuple. > > > > - Dave Sweeris > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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:56pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/16 "2017-06-12T21:56:16Z")
> - 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. My point here is that `Void` should be “striped” by “reducing” argument > **···** > > On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault \ 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:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 12, 2017, 6:04pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/17 "2017-06-12T18:04:07Z")
> 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. > **···** > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault \ wrote: > > > 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, 6:06pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/18 "2017-06-12T18:06:20Z")
Nothing, Unit, and other names have been frequently suggested in the past, but changing the name of Void was said to be out of scope even for Swift 3. > **···** > > On Mon, Jun 12, 2017 at 13:02 Robert Bennett via swift-evolution \< swift-evolution@swift.org\> wrote: > > > The name Unit is used in Foundation for that exact meaning: > > [https://developer.apple.com/documentation/foundation/unit\](https://developer.apple.com/documentation/foundation/unit%5C). > > > > I like the name `Nothing` for the empty tuple. func foo(Nothing) {} > > > > On Jun 12, 2017, at 1:57 PM, David Sweeris via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > Void was the empty tuple because arguments were tuples. So no arguments > > meant empty tuple. > > > > If we consider the empty tuple to be an argument, then the type for the > > type of empty tuple should be `Unit` > > > > Void, however, seem naturally fitted for the absence of argument. > > > > Should `func foo(Void)` be different from `func foo()`? I don’t think so. > > But different from `func foo(Unit)` ? Yes ! > > > > To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've > > not come across it being used as analog for something like the empty tuple. > > > > - Dave Sweeris > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > 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:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 13, 2017, 12:35am UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/19 "2017-06-13T00:35:57Z")
> 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. John. > **···** > > > On Jun 12, 2017, at 6:42 PM, Vladimir.S \ wrote: > > > 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:** ![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, 6:47pm UTC](https://forums.swift.org/t/proposal-change-void-meaning/6100/20 "2017-06-12T18:47:08Z")
It’s from type theory: > **[Unit type](https://en.wikipedia.org/wiki/Unit_type)** > > In the area of mathematical logic and computer science known as type theory, a unit type is a type that allows only one value (and thus can hold no information). The carrier (underlying set) associated with a unit type can be any singleton set. There is an isomorphism between any two such sets, so it is customary to talk about the unit type and ignore the details of its value. One may also regard the unit type as the type of 0-tuples, i.e. the product of no types. > The unit type is the terminal o... > **···** > > > On 12 Jun 2017, at 19:57, David Sweeris via swift-evolution \ wrote: > > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution \\> wrote: > > > > > Void was the empty tuple because arguments were tuples. So no arguments meant empty tuple. > > > > > > If we consider the empty tuple to be an argument, then the type for the type of empty tuple should be `Unit` > > > > > > Void, however, seem naturally fitted for the absence of argument. > > > > > > Should `func foo(Void)` be different from `func foo()`? I don’t think so. But different from `func foo(Unit)` ? Yes ! > > > > To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've not come across it being used as analog for something like the empty tuple. > > > > - Dave Sweeris > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Next page](https://forums.swift.org/t/proposal-change-void-meaning/6100.md?page=2)