<div dir="ltr">On Wed, May 24, 2017 at 12:00 AM, Guillaume Lessard <span dir="ltr"><<a href="mailto:glessard@tffenterprises.com" target="_blank">glessard@tffenterprises.com</a>></span> wrote:<br><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"><span class="gmail-"><br>
> On May 23, 2017, at 20:34, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
</span><span class="gmail-">> > Is there another lossy initializer for Int or BinaryInteger that doesn’t have a parameter label?<br>
><br>
> Yes. First, the Foundation initializer converting from NSNumber has the same behavior:<br>
><br>
> ```<br>
> import Foundation<br>
> let x = Int(42.5 as NSNumber) // x == 42<br>
> ```<br>
<br>
</span>That’s basically a repetition that brought no additional information to the table. The question stands.<br>
<span class="gmail-"><br>
<br>
> Now, you might argue that trapping does not meet your definition of "lossy," but it certainly causes problems in the example posed above:<br>
<br>
</span>I’m not talking about trapping, I’m talking about losing information. As in, the reverse conversion may differ from the original value. (why do you make me define this?).</blockquote><div><br></div><div>Yikes, that's an even _wider_ claim than Haravikk's!</div><div><br></div><div>* The Swift API design guidelines state that value-preserving (monomorphic) conversions should omit the label.</div><div>* Haravikk wants something more, if I understand him correctly: he wants _only_ value-preserving (monomorphic) conversions to omit the label and all other conversions to preserve the label.</div><div>* The Swift API design guidelines are explicit that value-preserving does _not_ guarantee round-tripping: "Note: the ability to retrieve the original value has no bearing on whether a conversion is value preserving." But you want _only_ round-trippable conversions to omit the label?</div><div><br></div><div>There is an accepted proposal to add such initializers for integers, and the accepted name is `init?(exactly:)`. It has not yet been fully implemented for floating point to integer conversions, afaict.</div><div><br></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">Trapping is fine; it’s the right behaviour.<br>
<br>
More broadly, though, I and others would like to know why it’s *better* to have no label on Int.init(_ x: Float) than to have one. Your attitude seems to be that the status quo needs no justification,</blockquote><div><br></div><div>Right, it doesn't. API renaming was an explicit part of Swift 3 evolution, but since those initial changes were settled, the bar for revising existing APIs has always been very high. After Swift 3 shipped, the core team said that the bar was now "extreme justification." Here, integer protocols were revised not once but twice, and they have been only recently approved and not yet even fully implemented. Moreover, floating point protocols were their own proposal, the rounding API was its own proposal, and additional initializers for exact integer conversion were yet another standalone proposal, so the question of how floating point values might be converted to integer values has been considered in some form _up to five times_ on this list, each time with a pitch, draft, review period, and core team decision.</div><div><br></div><div>But it's easy to have a good justification for this particular status quo. On principle, I will not post my thoughts to this list, because again the status quo is not what needs justification and we needn't debate its merits. I will, however, email it to you separately off-list.</div><div><br></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">but perhaps the status quo is not a global optimum.<br></blockquote><div><br></div><div>Like all human endeavors, Swift Evolution is path-dependent. For the general sanity of participants, the bar for revisiting topics is necessarily much higher than the bar for bringing up a topic for the first time. The necessarily implication of this is that we must accept that, as a matter of process, it can be undesirable to attempt to reach a global optimum. Which is not to say that I don't believe the current status quo isn't a global optimum: in fact, the more I think about it, the more I am satisfied with it.</div></div></div></div>