[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault]

@Xiaodi Wu
Disagree, and we would need the original designer here to help us, but my
understanding of the original meaning of tuples-as-arguments is that when I
define:
`func foo(_ arg0: Any, _ arg1: Any) {}`
I can afterwards “apply” a tuple to a function named `foo` and therefore
execute the function on this tuple.
Calling a function syntax was equivalent to put a tuple next to a function
name:
`foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
“hello")` is the tuple.

The same way if I have
`func foo()`
`foo()` means calling `foo` with argument `()` and there we have our
original `Void`

That meaning changed recently due to multiple SE implementations actually.
The parenthesis around the call don't have a tuple meaning anymore.
Therefore it breaks a lot of code relying on this feature of the language,
which was quite elegant, but could not handle advanced functions features.

@john: Void can happen easily in parameters due to generics, the easiest
example that breaks with swift4 is
`typealias Callback<T> = (T) -> Void`
here
`Callback<Void>` which is perfectly reasonable introduces Void in the
argument list and forces the caller to introduces an empty partenthesis set
when invoking:
```
let foo: Callback<Void> = { }
foo(())
```

That’s were the proposal shines in my opinion: adapting the meaning of Void
to the current context of swift4 gives back the language the elegant syntax
it had while preserving the type system

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

On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:

On Mon, Jun 12, 2017 at 12:44 Jérémie Girault <jeremie.girault at gmail.com>
wrote:

> Void was the empty tuple because arguments were tuples.
>

As John explained, that is _not_ correct. Void was not motivated by
anything to do with argument lists.

So no arguments meant empty tuple.
>
> If we consider the empty tuple to be an argument, then the type for the
> type of empty tuple should be `Unit`
>

It has been suggested to rename Void to Unit. I do believe it’s on the
commonly rejected ideas list (and if it’s not, it ought to be).

Void, however, seem naturally fitted for the absence of argument.
>
> Should `func foo(Void)` be different from `func foo()`?
>

SE-0110 determined that the two should in fact be different.

I don’t think so. But different from `func foo(Unit)` ? Yes !
>

It sounds like your quarrel is with the name of the typealias. I don’t see
how that solves any issues with the loss of tuple splatting. Functions will
still return (), and you foo(()) is not foo().

My point here is that we probably won’t have splatting for swift4.
>
>
> But if we consider the type system as a guide, we can consider 3 simple
> set of rules and restore almost 100% source compatibility while keeping the
> improvement of SE-0110
> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4
> (this proposition)
> - Rules for swift3 tuples-arguments of cardinality one in swift 4
> (proposition to be done)
> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4
> (proposition to be done)
>
> —
> very short reply expected - vsre.info
> Jérémie Girault
>
> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>
> Unfortunately, I think this proposal appears to be mistaken as to this key
> premise: Void was never (IIUC) meant to model the absence of arguments; it
> is a type with one possible value.
>
>
>
> If I recall, a number of conversations have been raised about Void being a
> typealias of (), and the definitive response has been that this falls into
> the ship-has-sailed category of out-of-scope changes.
>
> More generally, the recent spate of complaints about regressions to a
> particular coding style have to do with loss of implicit tuple splatting,
> the cure for which is a proper implementation of tuple splatting, not
> poking holes into settled parts of the type system.
>
>
>
>
> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Hi here,
>>
>> As I tested swift4 in xcode9b1 I noticed a lot of regressions about
>> tuples usage.
>>
>> After documenting myself about the changes which happened, I thought that
>> they could be improved. Instead of fighting these propositions (which make
>> sense), I wanted create a few proposal which would improve these recent
>> changes with a few simple rules.
>>
>> My propositions are based on the recent decisions and in the continuation
>> of SE-0110. The first one is about Void.
>> Void is historically defined as the type of the empty tuple. The reason
>> of this is that arguments were initially considered as tuple.
>>
>>
>> The dominant consideration here was always return types, not parameters.
>> I'm not sure there was ever much point in writing Void in a parameter list,
>> but whatever reasons there were surely vanished with SE-0066.
>>
>> Note that 'void' in C was originally exclusively a return type.  ANSI
>> gave it a new purpose it with void*, but the meaning is totally unrelated.
>>
>> John.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/c0a19180/attachment.html>