I'm not sure exactly where the bar is, but chiming in that recently, in implementing generic succinct data structures as an exercise, I needed to define exactly this operation generically.
-Colin On Tue, Feb 21, 2017 at 6:29 PM Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution