<div dir="ltr"><div>Just adding this here for reference:</div><div>func foo(_: Void) {}</div><div>func bar() {}</div><div>// All these compile in Swift 3:</div><div>foo()</div><div>foo(())</div><div>bar()</div><div>bar(())</div><div>// But only these two compile in Swift 4:</div><div>foo(())</div><div>bar()</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault <span dir="ltr"><<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">@xiaodi </div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I disagree on many points, for example what is the type of x when we type `let x = *Void` ?</div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">This is the essence of the problem and this proposition wants to solve this.</div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">The regression is due to both reason combined : typealias Void = () AND SE-0110</div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">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).</div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"></div><div id="m_-7716074133638540605m_-3005406717236171156bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">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 : <a href="https://github.com/ReactiveX/RxSwift/pull/1282/files" target="_blank">https://github.com/ReactiveX<wbr>/RxSwift/pull/1282/files</a></div></div></blockquote><div><br></div></span><div>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.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span> <br> <div id="m_-7716074133638540605m_-3005406717236171156bloop_sign_1497295426021404928" class="m_-7716074133638540605m_-3005406717236171156bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">—</div><div><font face="Helvetica" size="1">very short reply expected - <a href="http://vsre.info" target="_blank">vsre.info</a></font></div><div style="font-family:helvetica,arial;font-size:13px">Jérémie Girault<br></div></div> <br></span><div><div class="m_-7716074133638540605h5"><p class="m_-7716074133638540605m_-3005406717236171156airmail_on">On 12 juin 2017 at 21:18:06, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) wrote:</p> <blockquote type="cite" class="m_-7716074133638540605m_-3005406717236171156clean_bq"><span><div><div></div><div>
<div dir="ltr">On Mon, Jun 12, 2017 at 2:05 PM, David Hart
<span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div>
<blockquote type="cite">
<div><span>On 12 Jun 2017, at 19:25, Xiaodi Wu via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></div>
<span><br class="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463Apple-interchange-newline"></span>
<div>
<div><span>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.<br>
<br>
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.<br>
<br>
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.</span></div>
</div>
</blockquote>
<div><span><br></span></div>
<div>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.</div>
</div>
</div>
</blockquote>
<div><br></div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>And tuple splatting will not fix those regressions.</div>
</div>
</div>
</blockquote>
<div><br></div>
<div>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)`.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>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:</div>
<div><br></div>
<div><b>The Result<T> monad:</b> Result<Void>
represents the result of an operation with no return value</div>
<div><b>The Promise<T> monad:</b> Promise<Void>
represents the result of an asynchronous operation with no return
value</div>
<div><b>The Observable<T> monad (in functional reactive
programming):</b> Observable<Void> represents a stream of
events with no values</div>
<div><br></div>
<div>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.</div>
</div>
</div>
</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<blockquote type="cite">
<div>
<div>
<div class="gmail_quote">
<div><span>On Mon, Jun 12, 2017 at 12:15 John McCall via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:<br></span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><span><br></span>
<div>
<blockquote type="cite">
<div><span>On Jun 12, 2017, at 4:48 AM, Jérémie Girault
via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></div>
<span><br class="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274Apple-interchange-newline">
</span>
<div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span>Hi here,</span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span><br></span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span>As I tested swift4 in xcode9b1 I noticed a lot of
regressions about tuples usage.</span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span><br></span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span>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.</span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span><br></span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span>My propositions are based on the recent decisions
and in the continuation of SE-0110. The first one is about
Void.</span></div>
<div id="m_-7716074133638540605m_-3005406717236171156m_-2753128709184820463m_7884169765734884326m_-2000047954192297274bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px">
<span>Void is historically defined as the type of the
empty tuple. The reason of this is that arguments were initially
considered as tuple.</span></div>
</div>
</blockquote>
<span><br></span></div>
</div>
<div style="word-wrap:break-word">
<div><span>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.</span></div>
<div><span><br></span></div>
<div><span>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.</span></div>
</div>
<div style="word-wrap:break-word">
<div><span><br></span></div>
<div><span>John.</span></div>
</div>
<span>______________________________<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>
</span></blockquote>
</div>
</div>
<span>______________________________<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" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</span></div>
</blockquote>
</div>
<br></div>
</blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote></div></div></div>
</blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>