[swift-evolution] [Proposal] Change Void meaning

[Xiaodi Wu]

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

> @Xiaodi Wu
> Disagree, and we would need the original designer here to help us, but my
> understanding of the original meaning of tuples-as-arguments is that when I
> define:
> `func foo(_ arg0: Any, _ arg1: Any) {}`
> I can afterwards “apply” a tuple to a function named `foo` and therefore
> execute the function on this tuple.
> Calling a function syntax was equivalent to put a tuple next to a function
> name:
> `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42,
> “hello")` is the tuple.
>
> The same way if I have
> `func foo()`
> `foo()` means calling `foo` with argument `()` and there we have our
> original `Void`
>
> That meaning changed recently due to multiple SE implementations actually.
>

Tuples-as-arguments never shipped in any version of Swift, and the ability
to "apply" a tuple like that was removed by SE-0029--the original goal was
to implement this change in time for Swift 2.2.


> The parenthesis around the call don't have a tuple meaning anymore.
> Therefore it breaks a lot of code relying on this feature of the language,
> which was quite elegant, but could not handle advanced functions features.
>

Yes, this is an intentional and approved part of SE-0029. The drawbacks
were enumerated in that proposal and were deemed acceptable.


> @john: Void can happen easily in parameters due to generics, the easiest
> example that breaks with swift4 is
> `typealias Callback<T> = (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(())
> ```
>

`Callback<T> = (T) -> Void` refers to a callback that takes exactly one
argument. Since argument lists are not tuples, it is not possible to invoke
such a callback with zero arguments, or for that matter with two, three,
four, or five arguments.

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

I'm not sure what you mean by this. No change in `Void` can cause a
function of type (T) -> Void to accept zero arguments: it requires one
argument of type T.


On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi.wu 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/844fda21/attachment-0001.html>