<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 2:36 PM, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman <span dir="ltr" class=""><<a href="mailto:milseman@apple.com" target="_blank" class="">milseman@apple.com</a>></span> wrote:<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=""><div class=""><br class=""></div><div class="">* Unless you’re proposing a change to the semantics of the language that could affect e.g. name mangling or the type metadata hierarchy, then that would be ABI-affecting. For example, proposing that all functions must only take a single tuple rather than multiple arguments could affect the runtime representation of function types. But even then, there are approaches to mitigate this, so such a proposal would likely present an ABI migration strategy.</div><div class=""><div class="gmail-h5"><div class=""><br class=""></div></div></div></div></div></blockquote></div><br class=""></div><div class="gmail_extra">I think I understand (and understood), in very basic terms, the difference between source stability and binary stability, and I was thinking something like this:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">What if there is a chance that the "uniform tuple concept" could be redesigned and reimplemented after all, handling inout, variadic, etc in some way, allowing named single element tuples, allowing A -> B to represent (possibly only "pure") functions with _any_number_ of args, and not just one, as in Swift 4, and so on.</div></div></div></blockquote><div><br class=""></div>We really do want to tie most of these features specifically to function calls.</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"><br class=""></div><div class="gmail_extra">I'm still not entirely sure if this is ABI-affecting or not. But anyway, thank you for your calming words!</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">(I will try to not worry that (almost) everything parentheses-related in Swift will forever be stuck in a local optimum, because its current state and the history that lead to it is so confusing that it will stop all attempts at a substantially better solution and only allow minor changes/polishing.)</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">/Jens</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>