> On 22 May 2017, at 15:51, Xiaodi Wu <xiaodi...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution