[swift-evolution] Implicit truncation

[Xiaodi Wu]

On Wed, May 24, 2017 at 12:00 AM, Guillaume Lessard <
glessard at tffenterprises.com> wrote:

>
> > On May 23, 2017, at 20:34, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > > Is there another lossy initializer for Int or BinaryInteger that
> doesn’t have a parameter label?
> >
> > Yes. First, the Foundation initializer converting from NSNumber has the
> same behavior:
> >
> > ```
> > import Foundation
> > let x = Int(42.5 as NSNumber) // x == 42
> > ```
>
> That’s basically a repetition that brought no additional information to
> the table. The question stands.
>
>
> > Now, you might argue that trapping does not meet your definition of
> "lossy," but it certainly causes problems in the example posed above:
>
> 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?).


Yikes, that's an even _wider_ claim than Haravikk's!

* The Swift API design guidelines state that value-preserving (monomorphic)
conversions should omit the label.
* 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.
* 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?

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.

Trapping is fine; it’s the right behaviour.
>
> 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,


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.

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.

but perhaps the status quo is not a global optimum.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170524/6ce6a695/attachment.html>