<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">@john, the proposal is the fruit of my imagination and the goal was to discuss about it.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I’m vastly open to change it with the help of anyone if it can be implemented in a simple way and leads to better compatibility or syntactical improvements.</div><div id="bloop_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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">xiaodi told me that he wouldn’t be available to help me but I’m open to any help and change that would represent an improvement (from the developer or compiler point of view)</div> <br> <div id="bloop_sign_1497429781178794752" class="bloop_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">vsre.info</a></font></div><div style="font-family:helvetica,arial;font-size:13px">Jérémie Girault<br></div></div> <br><p class="airmail_on">On 13 juin 2017 at 19:15:18, John McCall (<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap:break-word" class=""><div></div><div>
<title></title>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 13, 2017, at 4:41 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">On Tue, Jun 13, 2017 at 3:06 AM, John
McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class="">
<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" class="">
<div class="">
<blockquote type="cite" class="">
<div class=""><span class="">On Jun 13, 2017, at 3:30 AM, Jérémie
Girault <<a href="mailto:jeremie.girault@gmail.com" target="_blank" class="">jeremie.girault@gmail.com</a>>
wrote:</span></div>
<span class=""><br class="m_-2644720238882970278Apple-interchange-newline"></span>
<div class="">
<div id="m_-2644720238882970278bloop_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" class=""><span class="">Exactly, </span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">The reflexion behind it
is: </span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class=""><br class=""></span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">- Let's understand that 0110 and other
tuple SE are important for the compiler, we do not want them to
rollback</span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">- However we have number of regressions for
generics / functional programmers</span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">- Let’s solve this step by step like a
typical problem</span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class=""><br class=""></span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">- Step 0 is adressing this Void tuple of
size zero :</span></div>
<div id="m_-2644720238882970278bloop_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" class=""><span class="">- Zero is in many problems of CS an edge
case, so let’s handle this case first</span></div>
<div id="m_-2644720238882970278bloop_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" class="">- The compiler knows what Void is, and its only value (or
non-value)</div>
<div id="m_-2644720238882970278bloop_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" class="">- It was handled historically by the compiler because of
implicit side effects</div>
<div id="m_-2644720238882970278bloop_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" class="">- Let’s handle it explicitely with rules in current
context</div>
<div id="m_-2644720238882970278bloop_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" class="">- one effect of the proposal is source compatibility</div>
<div id="m_-2644720238882970278bloop_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" class="">- but the goal is to build atop and strengthen 0110, 0066
and other tuple-related SE</div>
<div id="m_-2644720238882970278bloop_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" class=""><br class=""></div>
</div>
</blockquote>
<div class=""><br class=""></div>
There are four difficulties I see with this proposal.</div>
<div class=""><br class=""></div>
<div class="">The first is that it is a first step that quite
clearly does not lead to anything. It resolves a difficulty
with exactly one case of function composition, but we would need
completely different solutions to handle any of the other
compositional regressions of SE-0110.</div>
<div class=""><br class=""></div>
<div class="">The second is that it's a huge source of complexity
for the type system. The type checker would not be able to do
even rudimentary type matching, e.g. when checking a call, without
having first resolved all of the argument and parameter types to
prove that they are not Void. This would probably render it
impossible to type-check many programs without some ad-hoc rule of
inferring that certain types are not Void. It would certainly
make type-checking vastly more expensive.</div>
<div class=""><br class=""></div>
<div class="">The third is that it is not possible to prevent
values of Void from existing, because (unlike Never, which cannot
be constructed) they are always created by returning from a
Void-returning function, and a generic function can do anything it
likes with that value — turn it into an Any, store it in an Array,
whatever. The proposal seems to only consider using the value
as a parameter.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Hang on, though. If Jérémie is interested only in
addressing the issue of Void as a parameter and his idea can be
adequately carried out by inferring a default value of Void for
every parameter of type Void, this should be a fairly
self-contained change, should it not? And would the impact on the
cost of type checking really be vastly greater in that case?</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class=""></div>
<div>If the proposal was phrased in terms of defaults, e.g.
"trailing parameters do not require a matching argument if they
have Void type", then yes, that would be implementable because it
still admits a "local" reduction on call constraints, one which
does not need to immediately reason about the actual types of
arguments. It is not clear that this rule allows function
compositions of the sort that Jérémie is looking for, though.</div>
<div><br class=""></div>
<div>Anyway, that is not the proposal; the proposal is that
parameters — in any position — are simply removed from the
parameter sequence if they have Void type. In order to allow
composition (i.e. f(g(x)), where g: X -> Void), you then need a
matching rule that arguments are dropped from the argument sequence
(for purposes of type-checking) if they have Void type.
Either of these rules is sufficient to turn the reduction of
function-type matches into an extremely messy combinatoric matching
problem where e.g. (τ0, Int) can be passed to a function taking
(Int, τ1) if we can decide that τ0 == τ1 == Void.</div>
<div><br class=""></div>
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">This idea is now rather intriguing to me because it
extends beyond just addressing one symptom of SE-0110. Swift allows
us to omit the spelling out of return types that are Void, it
allows warning-free discarding of return values that are Void, etc.
This could add a nice consistency and rationalize some of the
weirdness of passing a value that is stipulated by the parameter
type.</div>
<div class=""><br class=""></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" class="">
<div class=""></div>
<div class="">Finally, it would allow a lot of inadvertent errors
with the use of generic functions, because any argument of
unconstrained type could be accidentally specialized with
Void. For example, if you forgot to pass an argument to this
function, it would simply infer T=Void:</div>
<div class=""> func append<T>(value: T)</div>
<div class="">It seems more likely that this would lead to
unexpected, frustrating bugs than that this would actually be
desired by the programmer. You really just want this to kick
in in more generic situations.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Hmm, at first glance, that seemed like it could be
bad. But if, say, a particular collection can store an element of
type Void, is it so undesirable to allow `append()` to append
Void?</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class=""></div>
append on a Collection is not an unconstrained generic; its
parameter type is determined by the type of the collection.
Perhaps this was a poorly-chosen example.</div>
<div><br class=""></div>
<div>John.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><br class=""></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" class="">
<div class=""><span class="HOEnZb"><font color="#888888" class=""><br class=""></font></span></div>
<div class=""><span class="HOEnZb"><font color="#888888" class="">John.</font></span></div>
<div class="">
<div class="h5">
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">
<div class=""><br 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" class="">
<div id="m_-2644720238882970278bloop_sign_1497338200319793920" class="m_-2644720238882970278bloop_sign" 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">
<div style="font-family:helvetica,arial;font-size:13px" class="">
—</div>
<div class=""><font face="Helvetica" size="1" class="">very short
reply expected -<span class="m_-2644720238882970278Apple-converted-space"> </span><a href="http://vsre.info/" target="_blank" class="">vsre.info</a></font></div>
<div style="font-family:helvetica,arial;font-size:13px" class="">
Jérémie Girault<br class=""></div>
</div>
<br 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" class="">
<p class="m_-2644720238882970278airmail_on" 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">
On 13 juin 2017 at 00:44:52, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>) wrote:</p>
<blockquote type="cite" class="m_-2644720238882970278clean_bq" 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">
<div class="">
<div class=""></div>
<div class="">
<div dir="ltr" class=""><span class="">On Mon, Jun 12, 2017 at 5:38
PM, Xiaodi Wu<span class="m_-2644720238882970278Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span><span class="m_-2644720238882970278Apple-converted-space"> </span>wrote<wbr class="">:<br class="">
</span>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="">
<div class="m_-2644720238882970278h5">On Mon, Jun 12, 2017 at 5:25
PM, Jérémie Girault<span class="m_-2644720238882970278Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jeremie.girault@gmail.com" target="_blank" class="">jeremie.girault@<wbr class="">gmail.com</a>></span><span class="m_-2644720238882970278Apple-converted-space"> </span>wrote:<br class="">
</div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">
<div class="m_-2644720238882970278h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class=""><br class=""></span></div>
<span class=""><br class=""></span>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409bloop_sign_1497305107136064000" class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px" class="">
<span class="">—</span></div>
<div class=""><span class=""><font face="Helvetica" size="1" class="">very short reply expected -<span class="m_-2644720238882970278Apple-converted-space"> </span><a href="http://vsre.info/" target="_blank" class="">vsre.info</a></font></span></div>
<div style="font-family:helvetica,arial;font-size:13px" class="">
<span class="">Jérémie Girault<br class=""></span></div>
</div>
<span class=""><br class=""></span>
<p class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409airmail_on">
<span class="">On 12 juin 2017 at 23:56:37, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>) wrote:</span></p>
<div class="">
<blockquote type="cite" class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409clean_bq" 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">
<div class="">
<div class="">
<div dir="ltr" class=""><span class="">On Mon, Jun 12, 2017 at 4:47
PM, Jérémie Girault<span class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jeremie.girault@gmail.com" target="_blank" class="">jeremie.girault@gmail<wbr class="">.com</a>></span><span class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409Apple-converted-space"> </span>wrote:<br class="">
</span>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">- 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.</div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">- maybe it should be revised around this ? Simple example
: </div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">`typealias Callback<T> = (T) -> Void` ->
`Callback<Void>` will give `(Void) => Void`. </div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">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 ?</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">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.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="">It is still be typechecked and appropriate errors
should be reported to the user so _nobody_ will ignore it.</p>
<p class="">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.</p>
<p class="">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 :</p>
<p class="">```</p>
<p class="">func foo<T, U, V>(t: T, u: U) -> V {</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>// do
something with t and u</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>//
return some V</p>
<p class="">}</p>
<p class="">```</p>
<p class="">with</p>
<p class="">```</p>
<p class="">func foo<Void, Int, String>(u: Int) -> String
{ let t = ()</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>// do
something with t and u</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>//
return some V</p>
<p class="">}</p>
<p class="">```</p>
<p class="">or</p>
<p class="">```</p>
<p class="">func foo<Void, Int, String>(t: Void = (), u: Int)
-> String {</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>// do
something with t and u</p>
<p class=""> <span class="m_-2644720238882970278Apple-converted-space"> </span>//
return some V</p>
<p class="">}</p>
<p class="">```</p>
<p class="">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.</p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">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`?</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><span class=""><br class=""></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409clean_bq" 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">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">My point here is that `Void` should be
“striped” by “reducing” argument list signatures.</span></div>
<span class=""><span class=""><br class=""></span></span>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_sign_1497302247432667904" class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px" class="">
<span class="">—</span></div>
<div class=""><span class=""><font face="Helvetica" size="1" class="">very short reply expected -<span class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409Apple-converted-space"> </span><a href="http://vsre.info/" target="_blank" class="">vsre.info</a></font></span></div>
<div style="font-family:helvetica,arial;font-size:13px" class="">
<span class="">Jérémie Girault<br class=""></span></div>
</div>
<span class=""><br class=""></span>
<p class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921airmail_on">
<span class="">On 12 juin 2017 at 19:15:18, John McCall (<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>) wrote:</span></p>
<div class="">
<div class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409h5">
<blockquote type="cite" class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921clean_bq">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span>
<div class="">
<blockquote type="cite" class="">
<div class=""><span class="">On Jun 12, 2017, at 4:48 AM, Jérémie
Girault via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</span></div>
<span class=""><br class="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921Apple-interchange-newline">
</span>
<div class="">
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class="">Hi here,</span></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class=""><br class=""></span></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class="">As I tested swift4 in xcode9b1 I noticed a
lot of regressions about tuples usage.</span></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class=""><br class=""></span></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class="">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_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class=""><br class=""></span></div>
<div id="m_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class="">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_-2644720238882970278m_5601571053956628674m_2043415068894562036m_-5564007550782516409m_-3578613130368345921bloop_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" class=""><span class="">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 class=""><br class=""></span></div>
<div class=""><span class="">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 class=""><span class=""><br class=""></span></div>
<div class=""><span class="">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 class=""><span class=""><br class=""></span></div>
<div class=""><span class="">John.</span></div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div></div></span></blockquote></body></html>