[swift-evolution] [Proposal] Change Void meaning

Jens Persson jens at bitcycle.com
Mon Jun 12 18:24:30 CDT 2017


This: https://twitter.com/slava_pestov/status/874394132340289536
seems to suggest that the current Swift 4 behavior will not change much in
this domain.

On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S <svabox at gmail.com> wrote:

> On 12.06.2017 23:17, Jens Persson via swift-evolution wrote:
>
>> I think this proposal would be complicating rather than simplifying the
>> type system, it would be adding a special rule.
>> And it is not a step towards resolving the many parentheses-related
>> inconsistencies that still remain.
>>
>> Here is an example of one such remaining inconsistency, it's still in
>> (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2)
>> and 4:
>> func foo() -> Void {}
>> func foo(_: Void) -> Void {} // This is OK
>> func bar(fn: () -> Void) {}
>> func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.
>>
>> I think the least surprising behavior here would be no error, rather than
>> two.
>> The current behavior with one error is very surprising.
>>
>
> As I understand, currently in Swift 4 there are a number of bugs related
> to function types, so I believe it is incorrect to make conclusions based
> on current behavior of Swift 4 code. I've asked John McCall in this thread
> about *planned* behavior of some Swift 4 release code related to function
> types, let's see what will be the reply.
>
> (I'd suggest to create a bug on bugs.swift.org for this particular issue
> - probably this will help to improve Swift 4 compiler)
>
>
>>
>> On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>     On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <
>> jeremie.girault at gmail.com
>>     <mailto:jeremie.girault at gmail.com>> wrote:
>>
>>         Exactly, that means that your implementation of the tuple
>> splatting operator
>>         is out of the type system.
>>         Can you expose it’s signature ?
>>
>>         If you want the operator to be “compiler-magic” it’s possible.
>>
>>     Yes, it requires compiler support.
>>
>>         This proposal is an alternate solution.
>>
>>         My point is that updating Void according to this proposal would
>>           - preserve the type system in a better way
>>           - have better source compatibility (in time for swift 4
>> release, were we
>>         probably won’t see tuple splatting)
>>           - also keep the elegant original syntax of swift instead of
>> stacking
>>         parenthesis
>>
>>         The impact for code writers would be minimized on time for swift
>> 4 release
>>
>>         As for return values: this proposition does not intend to change
>> the how
>>         return value of Void functions works.
>>
>>>>         very short reply expected - vsre.info <http://vsre.info>
>>         Jérémie Girault
>>
>>         On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi.wu at gmail.com
>>         <mailto:xiaodi.wu at gmail.com>) wrote:
>>
>>         On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault<
>>> jeremie.girault at gmail.com
>>>         <mailto:jeremie.girault at gmail.com>>wrote:
>>>
>>>             @xiaodi
>>>             I disagree on many points, for example what is the type of x
>>> when we
>>>             type `let x = *Void` ?
>>>
>>>
>>>         That would not be a legal statement. Exploding a tuple is an
>>> operation that
>>>         only makes sense inside an argument list. Likewise `let x =
>>> &Void` will not
>>>         compile.
>>>
>>>             This is the essence of the problem and this proposition
>>> wants to solve
>>>             this.
>>>
>>>             The regression is due to both reason combined : typealias
>>> Void = () AND
>>>             SE-0110
>>>
>>>             My proposition is to change the meaning of Void from () to
>>> “something
>>>             else” that is type-compatible with SE-0110 (and splatting in
>>> the future).
>>>
>>>
>>>         I'm not sure I understand your motivation. Void is just a
>>> typealias. If
>>>         tomorrow Void meant something else, all functions must still
>>> return (), and
>>>         there is still no implicit tuple splatting.
>>>
>>
>>
>>
>>>             If you want an example of the changes needed to migrate to
>>> swift4, just
>>>             look at the 42 files of handling parenthesis PR of RxSwift
>>> needed for
>>>             swift4 upgrade : https://github.com/ReactiveX/R
>>> xSwift/pull/1282/files
>>>             <https://github.com/ReactiveX/RxSwift/pull/1282/files>
>>>
>>>
>>>         Indeed, that's the result of SE-0110; these parentheses are
>>> needed because
>>>         there is no implicit tuple splatting. They would be required
>>> even if `Void`
>>>         did not exist in the language at all.
>>>
>>>
>>>>>>             very short reply expected -vsre.info <http://vsre.info>
>>>             Jérémie Girault
>>>
>>>             On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi.wu at gmail.com
>>>             <mailto:xiaodi.wu at gmail.com>) wrote:
>>>
>>>             On Mon, Jun 12, 2017 at 2:05 PM, David Hart<
>>>> david at hartbit.com
>>>>             <mailto:david at hartbit.com>>wrote:
>>>>
>>>>
>>>>                 On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution
>>>>>                 <swift-evolution at swift.org <mailto:
>>>>> swift-evolution at swift.org>> 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.
>>>>>
>>>>
>>>>                 But you can’t deny that SE-0110 has also caused
>>>> regressions in the
>>>>                 use of Void as generic argument because Void is
>>>> modelled as the
>>>>                 empty tuple.
>>>>
>>>>
>>>>             I'm not sure I understand this statement. Void is a synonym
>>>> for the
>>>>             empty tuple, and that hasn't ever changed, so it can't be
>>>> the root
>>>>             cause of any regressions.
>>>>
>>>>                 And tuple splatting will not fix those regressions.
>>>>
>>>>
>>>>             How come? If `*` is the splat operator, then it would be
>>>> legal to call
>>>>             a function `foo` that takes no arguments with `foo(*Void)`;
>>>> if
>>>>             implicit tuple splatting returns in fully implemented form,
>>>> then it
>>>>             would be legal to call it once again with `foo(Void)`.
>>>>
>>>>                 And contrary to what some people might think, this is
>>>> not an
>>>>                 “edge-case”. Most useful monads modelled with generics
>>>> have good
>>>>                 reasons to use Void:
>>>>
>>>>                 *The Result<T> monad:*Result<Void> represents the
>>>> result of an
>>>>                 operation with no return value
>>>>                 *The Promise<T> monad:*Promise<Void> represents the
>>>> result of an
>>>>                 asynchronous operation with no return value
>>>>                 *The Observable<T> monad (in functional reactive
>>>>                 programming):*Observable<Void> represents a stream of
>>>> events with
>>>>                 no values
>>>>
>>>>                 I use all three monads in my code and I’ve had to
>>>> modify a lot of
>>>>                 code when migrating to Swift 4 beta1 because of Void.
>>>>
>>>>
>>>>             Can you give examples of the modifications needed during
>>>> migration?
>>>>             From here, I can only see that the reason any code needs
>>>> modification
>>>>             is the complete removal of implicit tuple splatting.
>>>> Nothing has
>>>>             changed about Void being a synonym for the empty tuple;
>>>> even if you
>>>>             rename Void, functions will still return () by some other
>>>> name, and
>>>>             unless there is tuple splatting in some form, the migration
>>>> you
>>>>             performed is inevitable.
>>>>
>>>>                 On Mon, Jun 12, 2017 at 12:15 John McCall via
>>>>> swift-evolution
>>>>>                 <swift-evolution at swift.org <mailto:
>>>>> 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
>>>>>>                     <mailto: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 <mailto:
>>>>> swift-evolution at swift.org>
>>>>>                     https://lists.swift.org/mailma
>>>>> n/listinfo/swift-evolution
>>>>>                     <https://lists.swift.org/mailm
>>>>> an/listinfo/swift-evolution>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 swift-evolution mailing list
>>>>>                 swift-evolution at swift.org <mailto:
>>>>> swift-evolution at swift.org>
>>>>>                 https://lists.swift.org/mailma
>>>>> n/listinfo/swift-evolution
>>>>>                 <https://lists.swift.org/mailm
>>>>> an/listinfo/swift-evolution>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>     _______________________________________________
>>     swift-evolution mailing list
>>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>     <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170613/87502223/attachment.html>


More information about the swift-evolution mailing list