[swift-evolution] Implicit truncation

Xiaodi Wu xiaodi.wu at gmail.com
Tue May 23 14:25:40 CDT 2017

On Tue, May 23, 2017 at 1:16 PM, Guillaume Lessard via swift-evolution <
swift-evolution at swift.org> wrote:

> I completely agree with Haravikk. This is not C, we have type inference,
> and this behaviour is different from other non-failable lossy conversions
> in Swift.
> Regarding uses of ‘truncating’, Xiaodi is wrong. The documentation of
> BinaryInteger.init<T: FloatingPoint>(_ source: T) in the accepted proposal
> specifically uses the term in the way the original poster used it:
>   /// Creates an integer from the given floating-point value, truncating
> any
>   /// fractional part.
> (https://github.com/apple/swift-evolution/blame/master/propo
> sals/0104-improved-integers.md#L444)

The doc comments in the proposal text were meant as explanation for readers
of the proposal; they undergo editing for accuracy during implementation.
That wording is, notably, not found in the implemented protocol. Instead:

/// When you create a binary integer from a floating-point value using the
/// default initializer, the value is rounded toward zero before the range
/// checked. In the following example, the value `127.75` is rounded to
/// which is representable by the `Int8` type.  `128.25` is rounded to
/// which is not representable as an `Int8` instance, triggering a runtime
/// error.


This wording is also reflected in the pre-SE-0104-take-2 documentation for
the concrete implementation on the type itself, showing that it is a
longstanding convention:

> `init(_:)`
> Creates a new instance by rounding the given floating-point value toward

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170523/a00db6d9/attachment.html>

More information about the swift-evolution mailing list