[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault]

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

On 12 juin 2017 at 23:27:31, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:

On Mon, Jun 12, 2017 at 4:10 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 22:34:45, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>
> On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault <jeremie.girault@
> gmail.com> wrote:
>
>> I invite you to read the proposal rules again with a fresh mindset and
>> benevolence spirit.
>> It’s my first one and may not be very clear but the rules are
>> straightforward.
>>
>> Especially try to forget that Void is a tuple or anything.
>> Void is Nothing in the programmer’s mind. An instance of Void shouldn’t
>> even exist.
>>
>
> Sorry, that's not correct. Void is what's called Unit in other languages.
> It exists. That is why functions with "no return value" return Void. OTOH,
> Never does not exist. This discussion was had in great detail during the
> naming debate over Never.
>
> Let’s put facts in front of correctness assertions. Is Void = Unit in C or
> c++ ? can you create instances of void in java ? you have Void for generics.
>  https://en.wikipedia.org/wiki/Unit_type
>

Sorry, I don't understand your line of argumentation. Fact: in Swift, Void
is the name of the unit type. Are you objecting to the naming of the unit
type in Swift? Do you want the unit type to have other features? Is there
some other way of modeling the unit type other than a tuple of arity 0 that
you prefer?

As I’m saying I’m not discussing the name. I propose to replace Void with
another mechanism so that source compatibility is improved. Defining a unit
type and names is trivial afterwards.




> And if you look at assembly, sending void or returning void actually means
> "nothing to push on the stack / nothing to pop”. Seems like having this
> stripping on signatures at compile-time could be great !
>
> Actually, in my opinion we could discuss naming when we agree that the
> mechanism works, using this name is just a way to not impact the developer
> with code changes.
>
> So either we agree on the fact that the mechanism works and we can move on
> to naming, or we get back on the topic : do you see a flaw in the proposal
> rules ? It elegantly transforms signature arity and provides the programmer
> a natural syntax to express it’s code.
>

I have read your proposal three times, but I do not understand what it is
proposing, in part because your proposal contains factual errors in the
premises. For instance, it claims repeatedly that Void is a typealias for
() because of something to do with argument lists, which is not true. It is
therefore unclear to me what it is you are proposing to do and what is
motivating such a proposal.

All I am saying is that, in previous conversations on this list, people who
actually do the work of implementing features in the compiler have stated
that `typealias Void = ()` is a fait accompli. With that as a starting
point, what do you propose to do?

You probably know the original designer intent better than me because you
are here for a longer time, but that’s not the point. And thank you for
trying to understand it again :

- The goal of the proposal is to replace Void by an intrinsic which would
reduce the arity of argument list it is present in.

- Why ? Because, especially when using generics, Void will easily be
introduced in parameter lists. Actually it introduces useless arguments. If
you follow the rules in Detailed design, you will see that the reduction of
arity will lead to a better source compatibility and syntax. Moreover the
expected result, from a developer point of view, feels more natural.




>
>
>> The proposed meaning of Void is to be a “lack” of arguments. It means
>> that each “Void” argument reduces the arity of the function by one, at its
>> exact position. Especially look at the canonical signature definition, and
>> the proposed rules of reduction.
>>
>
> I don't understand why you propose to name this new idea "Void". You're
> proposing something that's not even a lack of an argument, but an
> anti-argument, like anti-matter! I'm not sure I understand why this is
> necessary. It seems to be a very strange workaround for one specific issue
> arising from disallowing implicit tuple splatting.
>
>
> Look at other languages, when you put Void in functions in C or java, do
> you need to add a value ? Ease of use is important.
>
> You imply that I disagree with splatting were I don’t, let’s not make it
> personal. This proposal is even compatible with tuple splatting !
>
> The proposal rules seem to work and provides great user value. Let’s try
> to consider this !
>
>
>
>
>> That proposal, if implemented, would effectively allow `Callback<Void>`
>> to be called without arguments in the context of swift4.
>>
>> —
>> very short reply expected - vsre.info
>> Jérémie Girault
>>
>> On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>>
>> On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault <jeremie.girault@
>> 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/4692c1c4/attachment.html>