> On Jul 1, 2016, at 1:14 PM, Karl via swift-evolution > <[email protected]> wrote: > > >> On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution >> <[email protected]> wrote: >> >> >>> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >>> begins now and runs through July 5. The proposal is available here: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md >>> >>> * What is your evaluation of the proposal? >> >> It is an improvement but would it be even better if the return type was Int >> (or possibly type inferred to Int16 etc.). If a float is really desired it >> can be initialised from the Int (or it could even infer float result is >> required). >> >>> * Is the problem being addressed significant enough to warrant a change to >>> Swift? >> >> Yes, reduces reliance on C APIs. API also clearer about semantics. >> >>> * Does this proposal fit well with the feel and direction of Swift? >> >> Yes >> >>> * If you have used other languages or libraries with a similar feature, >>> how do you feel that this proposal compares to those? >>> * How much effort did you put into your review? A glance, a quick reading, >>> or an in-depth study? >> >> Quick read and a quick look at earlier discussion linked from proposal. >> >> Joseph >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > We could perhaps change the existing Int(FloatingPoint) initialisers to take > a RoundingRule with a default argument. Currently I believe they are > equivalent to floor, but that’s a documentation comment and isn’t explicit in > the API itself.
trunc( ), not floor (matching the behavior of C-family conversions to integer). _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
