[swift-evolution] Implicit truncation

Xiaodi Wu xiaodi.wu at gmail.com
Sun May 21 23:55:22 CDT 2017


...And I do have to take one statement back: if I recall, using the label
"truncating" was considered and rejected for converting from floating point
values to integers. The reasoning was that, in Swift, the term "truncating"
is intended to be used exclusively for the truncating of bit patterns (such
as Int(truncatingOrExtending: 42 as Int8)). Although C has "trunc", the
same function is deliberately known in Swift as "rounded toward zero." Even
the documentation for Int.init(_: Float) deliberately uses that terminology
and never calls it "truncating."
On Sun, May 21, 2017 at 23:44 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> Both `rounded()` and `round()` are already provided by FloatingPoint. As
> with all proposed API additions, you'd need to demonstrate why
> Int.init(rounding: value) is necessary given that Int.init(value.rounded())
> is already possible. With so many initializers on Int already, I highly
> doubt that adding more is a good move.
>
> There is `Int.init?(exactly:)` for the originally requested feature. Now,
> if one were to design from scratch, then perhaps Int.init(truncating:)
> would be the most consistent name, but the unlabeled spelling is not
> harmful, as `Int.init(_: Float)` is after all a non-failable initializer
> that converts from a floating point value to an integer value. Put another
> way, if the current unlabeled spelling weren't used for what it is today,
> then there could be no unlabeled initializer on an integer type that takes
> a floating point argument.
>
> In any case, this issue is settled. The integer protocols have been
> formally reviewed not once but twice, and not all of the approved design
> has even been implemented yet. One cannot go back and bikeshed endlessly
> what has already been approved.
>
>
> On Sun, May 21, 2017 at 21:22 Robert Bennett via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Swift already has the FloatingPointRoundingRule enum — used in mutating
>> func round(_ rule: FloatingPointRoundingRule) in FloatingPoint — which has
>> all of that behavior as separate cases. So all that would be added to the
>> language would be:
>>
>> Int.init(rounding number: FloatingPoint, _ rule:
>> FloatingPointRoundingRule)
>> Int.init(truncating number: FloatingPoint)
>>
>> The latter would be source breaking and require migration, so we'd need
>> it before Swift 4. This seems like a pretty easy change to make, though.
>>
>> Also, this probably isn't the thread for this, but I noticed that the
>> FloatingPoint protocol has a mutating round method, but not a non-mutating
>> rounded() method. Would that be worth adding as well? It feels odd to not
>> have the mutating/non-mutating pair of methods there.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170522/054626e1/attachment.html>


More information about the swift-evolution mailing list