[swift-evolution] [Proposal] Change Void meaning

[Xiaodi Wu]

On Mon, Jun 12, 2017 at 5:38 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Mon, Jun 12, 2017 at 5:25 PM, Jérémie Girault <
> jeremie.girault at gmail.com> wrote:
>
>>
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 23:56:37, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 4:47 PM, Jérémie Girault <jeremie.girault at gmail
>> .com> wrote:
>>
>>> - Void as arguments is pretty common when using generics, that’s a core
>>> point of this proposal. An maybe that’s why we misunderstood ourselves
>>> (around 0110 / 0066). This proposal addresses arguments.
>>> - maybe it should be revised around this ? Simple example :
>>>
>>> `typealias Callback<T> = (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.
>>
>> It is still be typechecked and appropriate errors should be reported to
>> the user so _nobody_ will ignore it.
>>
>> But with the proposal the code will be striped out of Void arguments at
>> compile-time. I think it's a win for the developer on a lot of grounds. The
>> fact that this proposal integrates with the type-system is also important.
>>
>> If you are not comfortable about Void being stripped, we can also discuss
>> alternatives: someone was suggesting me that it would be possible to
>> replace :
>>
>> ```
>>
>> func foo<T, U, V>(t: T, u: U) -> V {
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> with
>>
>> ```
>>
>> func foo<Void, Int, String>(u: Int) -> String { let t = ()
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> or
>>
>> ```
>>
>> func foo<Void, Int, String>(t: Void = (), u: Int) -> String {
>>
>>   // do something with t and u
>>
>>   // return some V
>>
>> }
>>
>> ```
>>
>> I don’t know what you would consider more effective or elegant (at an
>> implementation level) but it’s the same result for the developper.
>>
>
Ah, but I think I catch your drift with the last example. Is this a more
general point that the compiler should treat every parameter of type Void
as having an implied default value of Void? That would be an interesting
idea.

What is the goal of such changes? Is it to allow you to write `foo()`
> instead of `foo(())` for a function `foo` of type `(T) -> Void`?
>
> If so, then I think what you're seeking to do is reverse SE-0066 (as
> Vladimir points out), which explicits details how it's is an intentional
> change to require such a spelling. I think you're starting from the premise
> that this is unintended or undesirable, when in fact it is deliberate and
> approved.
>
> It is also, unless I'm mistaken, not the issue that was raised initially
> with respect to SE-0110, which had to do with the extra boilerplate of
> destructuring a tuple inside a closure, something that was not so obvious
> before implementation.
>
> My point here is that `Void` should be “striped” by “reducing” argument
>>> list signatures.
>>>
>>> —
>>> very short reply expected - vsre.info
>>> Jérémie Girault
>>>
>>> On 12 juin 2017 at 19:15:18, John McCall (rjmccall at apple.com) 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.
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/8fa16b5d/attachment.html>