You raised two points: 1. "... magnitude is something the number ‘has’ whereas signum is a completely new thing ..." I think sign is as much part of a number as magnitude. Its a minor point, code complete gets it anyway.
2. "... [extras] are defined as protocol extensions, therefore they should be discoverable through completion ..." I wasn't thinking so much about code completion, more browsing the protocol to see what is available (I use SwiftDoc quite a bit). Thanks for running with this - very valuable, -- Howard. On 22 February 2017 at 10:27, Max Moiseev <[email protected]> wrote: > > On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution < > [email protected]> wrote: > > The re-review of SE-0104 "Protocol-oriented integers" begins now and runs > through February 25, 2017. This proposal was accepted for Swift 3, but was > not implemented in time for the release. The revised proposal is available > here: > >> >> https://github.com/apple/swift-evolution/blob/master/ >> proposals/0104-improved-integers.md >> >> >> • What is your evaluation of the proposal? >> > > Well worth while. Few nit picks: > > 1. Number.init? Description should say BinaryInteger not floating-point. > > I’ll update the proposal. > > 2. Number should document that mutating versions of operators can > overflow. > 3. SignedNumber should document that negate and unary `-` can overflow. > > Documentation changes noted. Thanks! > > 4. SignedNumber, it is weird that `signum` is a function when other > similar things, e.g. `magnitude`, are properties. > > I think of it as: magnitude is something the number ‘has’ whereas signum > is a completely new thing of the same type. > > 5. Not worth representing `DoubleWidth` as an enumeration, it is obscure > and therefore will only confuse people. > 6. It would be better to put the 'extra' operations into the protocols > and provide default implementations, otherwise they are difficult to find. > > They are defined as protocol extensions, therefore they should be > discoverable through completion and in the generated source code. Or what > do you mean by ‘difficult to find’? > > Thanks for the feedback! > > >> • Is the problem being addressed significant enough to warrant a change >> to Swift? >> > > Yes, the current design has not served my purpose on more than one > occasion > >> >> • 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? >> > > Yes, this proposal is similar to what other languages provide, e.g. Scala. > In Scala however they tackle the `conversion problem as well in their > `traits heirarchy. I guess this could be added at a later date. > >> >> • How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? >> > > Read the proposal, have used similar features in other languages, and have > had trouble with Swift's current heirarchy. > -- > -- Howard. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
