Me:<br><br>Unless the functions also return an error, mutating/non-mutating pairs<br>of functions return Void/Self (or maybe Optional<Self>) respectively.<br>Are there other possibilities? But Swift is pretty unique among<br>C-family languages in allowing overloaded functions that differ only<br>by return type. Besides the loss of clarity to the reader at the call<br>site, what are downsides of simply naming both functions exactly the<br>same in today's Swift syntax?<br><br>You:<br><br>I don't think it's really worth exploring much further once you acknowledge the loss of clarity to the reader at the call site ;-)<br><br>(I think the smiley really seals the deal in terms of definitiveness of rejection, no?)<br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 25, 2016 at 17:05 Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Sun Apr 24 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Anyways, I wouldn’t be surprised if this idea has come up before and has<br>
> been rejected, but to me it sounds like a good idea.<br>
><br>
> Yes, I suggested this a while back, and it was rejected.<br>
<br>
That makes it sound much more definitive than anything on this list<br>
other than a formal review response can ever be. What actually<br>
happened?<br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>