[Proposal] Change Void meaning


(Jérémie Girault) #1

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

Let me know what you think about it,

···


very short reply expected - vsre.info
Jérémie Girault


(Tino) #2

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).


(John McCall) #3

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 <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.


(Vladimir) #4

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

Let me know what you think about it,


very short reply expected - 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


(David Hart) #5

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<T>(_ a: T) {}
func foo() {}

foo() // are we calling foo() or foo<Void>()

···

On 12 Jun 2017, at 10:48, 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/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


(Jens Persson) #6

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<A>(_ 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/
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


(Jérémie Girault) #7

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.
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md
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

Let me know what you think about it,


very short reply expected - 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


(Jérémie Girault) #8

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<A>(_ 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/
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


(Jérémie Girault) #9

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.


(Jérémie Girault) #10

- 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> = (T) -> Void` -> `Callback<Void>` 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.


(Xiaodi Wu) #11

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


(Vladimir) #12

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<T>(_ 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 >> <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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jérémie Girault) #13

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


(David Sweeris) #14

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 <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 !


#15

The name Unit is used in Foundation for that exact meaning: https://developer.apple.com/documentation/foundation/unit.

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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #16

- 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> = (T) -> Void` -> `Callback<Void>` 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 <jeremie.girault@gmail.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.


(Xiaodi Wu) #17

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 <jeremie.girault@gmail.com> 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


(Xiaodi Wu) #18

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.

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(John McCall) #19

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 <svabox@gmail.com> 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<T>(_ 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 <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
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #20

It’s from type theory:

https://en.wikipedia.org/wiki/Unit_type

···

On 12 Jun 2017, at 19:57, 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 <mailto: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