Sign, perhaps, can be thought of as "part of a number," but signum refers to the signum function (http://en.wikipedia.org/wiki/Sign_function) defined as:
-1 if x < 0 0 if x = 0 1 if x > 0 1 isn't really "part of" 42, for instance, at least not in the sense that 42 and + are "part of" 42. On Tue, Feb 21, 2017 at 22:18 Howard Lovatt via swift-evolution < [email protected]> wrote: > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
