<div dir="ltr">This: <a href="https://twitter.com/slava_pestov/status/874394132340289536">https://twitter.com/slava_pestov/status/874394132340289536</a><div>seems to suggest that the current Swift 4 behavior will not change much in this domain. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S <span dir="ltr">&lt;<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12.06.2017 23:17, Jens Persson via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule.<br>
And it is not a step towards resolving the many parentheses-related inconsistencies that still remain.<br>
<br>
Here is an example of one such remaining inconsistency, it&#39;s still in (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2) and 4:<br>
func foo() -&gt; Void {}<br>
func foo(_: Void) -&gt; Void {} // This is OK<br>
func bar(fn: () -&gt; Void) {}<br>
func bar(fn: (_: Void) -&gt; Void) {} // ERR: Invalid redecl.<br>
<br>
I think the least surprising behavior here would be no error, rather than two.<br>
The current behavior with one error is very surprising.<br>
</blockquote>
<br></span>
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&#39;ve asked John McCall in this thread about *planned* behavior of some Swift 4 release code related to function types, let&#39;s see what will be the reply.<br>
<br>
(I&#39;d suggest to create a bug on <a href="http://bugs.swift.org" rel="noreferrer" target="_blank">bugs.swift.org</a> for this particular issue - probably this will help to improve Swift 4 compiler)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;&gt; wrote:<br>
<br>
    On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault &lt;<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.com</a><br></span><span class="">
    &lt;mailto:<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a>&gt;&gt; wrote:<br>
<br>
        Exactly, that means that your implementation of the tuple splatting operator<br>
        is out of the type system.<br>
        Can you expose it’s signature ?<br>
<br>
        If you want the operator to be “compiler-magic” it’s possible. <br>
<br>
    Yes, it requires compiler support.<br>
<br>
        This proposal is an alternate solution.<br>
<br>
        My point is that updating Void according to this proposal would<br>
          - preserve the type system in a better way<br>
          - have better source compatibility (in time for swift 4 release, were we<br>
        probably won’t see tuple splatting)<br>
          - also keep the elegant original syntax of swift instead of stacking<br>
        parenthesis<br>
<br>
        The impact for code writers would be minimized on time for swift 4 release<br>
<br>
        As for return values: this proposition does not intend to change the how<br>
        return value of Void functions works.<br>
<br>
        —<br></span>
        very short reply expected - <a href="http://vsre.info" rel="noreferrer" target="_blank">vsre.info</a> &lt;<a href="http://vsre.info" rel="noreferrer" target="_blank">http://vsre.info</a>&gt;<span class=""><br>
        Jérémie Girault<br>
<br>
        On 12 juin 2017 at 21:45:08, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a><br></span>
        &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
        On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault&lt;<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a><br></span>
        &lt;mailto:<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a>&gt;&gt;wrote:<span class=""><br>
<br>
            @xiaodi<br>
            I disagree on many points, for example what is the type of x when we<br>
            type `let x = *Void` ?<br>
<br>
<br>
        That would not be a legal statement. Exploding a tuple is an operation that<br>
        only makes sense inside an argument list. Likewise `let x = &amp;Void` will not<br>
        compile.<br>
<br>
            This is the essence of the problem and this proposition wants to solve<br>
            this.<br>
<br>
            The regression is due to both reason combined : typealias Void = () AND<br>
            SE-0110<br>
<br>
            My proposition is to change the meaning of Void from () to “something<br>
            else” that is type-compatible with SE-0110 (and splatting in the future).<br>
<br>
<br>
        I&#39;m not sure I understand your motivation. Void is just a typealias. If<br>
        tomorrow Void meant something else, all functions must still return (), and<br>
        there is still no implicit tuple splatting.<br>
</span></blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
            If you want an example of the changes needed to migrate to swift4, just<br>
            look at the 42 files of handling parenthesis PR of RxSwift needed for<br>
            swift4 upgrade : <a href="https://github.com/ReactiveX/RxSwift/pull/1282/files" rel="noreferrer" target="_blank">https://github.com/ReactiveX/R<wbr>xSwift/pull/1282/files</a><br>
            &lt;<a href="https://github.com/ReactiveX/RxSwift/pull/1282/files" rel="noreferrer" target="_blank">https://github.com/ReactiveX/<wbr>RxSwift/pull/1282/files</a>&gt;<br>
<br>
<br>
        Indeed, that&#39;s the result of SE-0110; these parentheses are needed because<br>
        there is no implicit tuple splatting. They would be required even if `Void`<br>
        did not exist in the language at all.<br>
<br>
<br>
            —<br></span>
            very short reply expected -<a href="http://vsre.info" rel="noreferrer" target="_blank">vsre.info</a> &lt;<a href="http://vsre.info" rel="noreferrer" target="_blank">http://vsre.info</a>&gt;<span class=""><br>
            Jérémie Girault<br>
<br>
            On 12 juin 2017 at 21:18:06, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a><br></span>
            &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
            On Mon, Jun 12, 2017 at 2:05 PM, David Hart&lt;<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a><br></span>
            &lt;mailto:<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>&gt;&gt;wro<wbr>te:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
                On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution<br></span><div><div class="h5">
                &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;&gt; wrote:<br>
<br>
                Unfortunately, I think this proposal appears to be mistaken as to<br>
                this key premise: Void was never (IIUC) meant to model the<br>
                absence of arguments; it is a type with one possible value.<br>
<br>
                If I recall, a number of conversations have been raised about<br>
                Void being a typealias of (), and the definitive response has<br>
                been that this falls into the ship-has-sailed category of<br>
                out-of-scope changes.<br>
<br>
                More generally, the recent spate of complaints about regressions<br>
                to a particular coding style have to do with loss of implicit<br>
                tuple splatting, the cure for which is a proper implementation of<br>
                tuple splatting, not poking holes into settled parts of the type<br>
                system.<br>
</div></div></blockquote><div><div class="h5">
<br>
                But you can’t deny that SE-0110 has also caused regressions in the<br>
                use of Void as generic argument because Void is modelled as the<br>
                empty tuple.<br>
<br>
<br>
            I&#39;m not sure I understand this statement. Void is a synonym for the<br>
            empty tuple, and that hasn&#39;t ever changed, so it can&#39;t be the root<br>
            cause of any regressions.<br>
<br>
                And tuple splatting will not fix those regressions.<br>
<br>
<br>
            How come? If `*` is the splat operator, then it would be legal to call<br>
            a function `foo` that takes no arguments with `foo(*Void)`; if<br>
            implicit tuple splatting returns in fully implemented form, then it<br>
            would be legal to call it once again with `foo(Void)`.<br>
<br>
                And contrary to what some people might think, this is not an<br>
                “edge-case”. Most useful monads modelled with generics have good<br>
                reasons to use Void:<br>
<br></div></div>
                *The Result&lt;T&gt; monad:*Result&lt;Void&gt; represents the result of an<span class=""><br>
                operation with no return value<br></span>
                *The Promise&lt;T&gt; monad:*Promise&lt;Void&gt; represents the result of an<span class=""><br>
                asynchronous operation with no return value<br></span>
                *The Observable&lt;T&gt; monad (in functional reactive<br>
                programming):*Observable&lt;Void&gt; represents a stream of events with<span class=""><br>
                no values<br>
<br>
                I use all three monads in my code and I’ve had to modify a lot of<br>
                code when migrating to Swift 4 beta1 because of Void.<br>
<br>
<br>
            Can you give examples of the modifications needed during migration?<br>
            From here, I can only see that the reason any code needs modification<br>
            is the complete removal of implicit tuple splatting. Nothing has<br>
            changed about Void being a synonym for the empty tuple; even if you<br>
            rename Void, functions will still return () by some other name, and<br>
            unless there is tuple splatting in some form, the migration you<br>
            performed is inevitable.<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
                On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution<br></span>
                &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;&gt; wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
                    On Jun 12, 2017, at 4:48 AM, Jérémie Girault via<br>
                    swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br></span><span class="">
                    &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;&gt; wrote:<br>
<br>
                    Hi here,<br>
<br>
                    As I tested swift4 in xcode9b1 I noticed a lot of<br>
                    regressions about tuples usage.<br>
<br>
                    After documenting myself about the changes which happened, I<br>
                    thought that they could be improved. Instead of fighting<br>
                    these propositions (which make sense), I wanted create a few<br>
                    proposal which would improve these recent changes with a few<br>
                    simple rules.<br>
<br>
                    My propositions are based on the recent decisions and in the<br>
                    continuation of SE-0110. The first one is about Void.<br>
                    Void is historically defined as the type of the empty tuple.<br>
                    The reason of this is that arguments were initially<br>
                    considered as tuple.<br>
</span></blockquote><span class="">
<br>
                    The dominant consideration here was always return types, not<br>
                    parameters.  I&#39;m not sure there was ever much point in<br>
                    writing Void in a parameter list, but whatever reasons there<br>
                    were surely vanished with SE-0066.<br>
<br>
                    Note that &#39;void&#39; in C was originally exclusively a return<br>
                    type.  ANSI gave it a new purpose it with void*, but the<br>
                    meaning is totally unrelated.<br>
<br>
                    John.<br>
                    ______________________________<wbr>_________________<br>
                    swift-evolution mailing list<br></span>
                    <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;<br>
                    <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><span class=""><br>
                    &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>&gt;<br>
<br>
                ______________________________<wbr>_________________<br>
                swift-evolution mailing list<br></span>
                <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;<br>
                <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
                &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>&gt;<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
    ______________________________<wbr>_________________<br>
    swift-evolution mailing list<br>
    <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;<br>
    <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><span class=""><br>
    &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>&gt;<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>