[swift-evolution] Implicit truncation

[Haravikk]

> On 22 May 2017, at 15:51, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> If we're to speak of intuition for new developers who've never used a programming language, who are falling back to what they know about mathematics, then quite literally a decimal point _is_ about division by ten.

I don't think this necessarily follows; the issue here is that the constructor isn't explicit enough that it is simply lopping off the fractional part. My own experience of maths as taught in school, to go from a decimal to an integer I would expect to round, so I think it's reasonable that Swift should be clear. While it is reflected in the documentation, a good choice of label would allow it to be explicit at the point of use, without requiring a look up each time there is uncertainty.

> 	func init(truncating:Float) { … }
> 
> Again, this particular naming suggestion has been discussed as part of the review of integer protocols and not adopted. The rationale was that the term "truncating" is intended to be left for bit patterns only. The term in Swift is exclusively "rounded toward zero."

As I understand it truncation is a term of art from C at least (rounding toward zero is the trunc function I believe?), it also makes sense given that what's happening is that the fractional part is being discarded, regardless of how how high it may be. init(roundTowardZero:Float) seems like it would be very unwieldy by comparison just because truncating is arbitrarily reserved for bit operations.

Also, when it comes down to it, discarding the fractional part of a float is a bit-pattern operation of a sort, as the conversion is simplistically taking the significand, dropping it into an Int then shifting by the exponent.

> 	func init(rounding:Float, _ strategy: FloatingPointRoundingRule) { … }
> 
> Again, here, as an addition to the API, this fails the six criteria of Ben Cohen, as it is strictly duplicative of `T(value.rounded(strategy))`.

Maybe, but init(rounding:) is explicit that something is being done to the value, at which point there's no obvious harm in clarifying what (or allowing full freedom). While avoiding redundancy is good as a general rule, it doesn't mean there can't be any at all if there's some benefit to it; in this case clarity of exactly what kind of rounding is taking place to the Float/Double value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170522/aa28857c/attachment.html>