<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">Interesting use-case,</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"><span class="Apple-tab-span" style="white-space:pre"> </span>Actually, after double-checking the rules I proposed, it seem to be possible, to do `let x: Void = foo()` but all “pseudo-instances” of Void would be stripped at compile time. Therefore this does not introduces source-breaking changes even if this use case is quite convoluted (but could happen easily in generics case).</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"><span class="Apple-tab-span" style="white-space:pre"> </span>I do not propose that implicit Void should be removed, it’s more of a sample of the “magic” around Void. My proposition consist to “extend" this magic a bit using given rules and in consequence, allow more source-compatibility, readability.</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"><span class="Apple-tab-span" style="white-space:pre"> </span>I just read the SE-0066 and don’t see any conflicting point (nor relation) with this proposition. <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md">https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md</a></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"><span class="Apple-tab-span" style="white-space:pre"> </span>If you see any conflicting point, I would be interested to know which one specifically.</div> <br> <div id="bloop_sign_1497285054277498880" 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 12 juin 2017 at 13:21:24, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 12.06.2017 11:48, Jérémie Girault via swift-evolution wrote:
<br>> Hi here,
<br>>
<br>> As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage.
<br>>
<br>> After documenting myself about the changes which happened, I thought that they could
<br>> be improved. Instead of fighting these propositions (which make sense), I wanted
<br>> create a few proposal which would improve these recent changes with a few simple rules.
<br>>
<br>> My propositions are based on the recent decisions and in the continuation of SE-0110.
<br>> The first one is about Void.
<br>> Void is historically defined as the type of the empty tuple. The reason of this is
<br>> that arguments were initially considered as tuple. If this is no more the case, then
<br>> it’s no more a reason to keep Void as an empty tuple.
<br>
<br>Could you clarify, do yo propose to change meaning of this code:
<br>func foo() {}
<br>from "implicitly returns Void" to "returns nothing" ?
<br>
<br>So, this valid Swift 3 and Swift 4 code will be invalid:
<br>
<br>func foo(){}
<br>let x : Void = foo()
<br>?
<br>
<br>In this case I believe your proposal introduces new source breaking change that makes
<br>transition from Swift 3 to Swift 4 even more difficult for some code.
<br>
<br>There were short discussions in this list if implicit Void return should also be
<br>removed and IIRC was rejected by common opinion or by some one's authoritative opinion.
<br>
<br>Also, I'd like to suggest you to read text of SE-0066 proposal, where you can see
<br>that it clearly separated functions accepting Void parameter and accepting no
<br>parameters. So, IMO you should also refer to SE-0066 proposal in your text and it
<br>seems(correct me if I understood your proposal incorrectly) you should propose to
<br>revisit SE-0066 in this detail.
<br>
<br>
<br>Vladimir.
<br>
<br>>
<br>> I think that by having a few rules around tuples of cardinality 0 and 1 and also
<br>> arguments list, we could greatly improve source compatibility and keep a lot of what
<br>> makes swift great when using functional style and generics.
<br>>
<br>> I drafted a proposal that would allow more source compatibility and type consistency
<br>> and would enjoy discussing it with you, in order to improve it :
<br>>
<br>> <a href="https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md">https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md</a>
<br>>
<br>> Let me know what you think about it,
<br>>
<br>> —
<br>> very short reply expected - <a href="http://vsre.info">vsre.info</a> <<a href="http://vsre.info">http://vsre.info</a>>
<br>> Jérémie Girault
<br>>
<br>>
<br>> _______________________________________________
<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">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br>>
<br></div></div></span></blockquote></body></html>