[swift-evolution] Implicit truncation

[Xiaodi Wu]

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/c8762575/attachment.html>