Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Jul 1, 2016, at 9:18 PM, Patrick Pijnappel wrote: >> > We might even be able to take the existing string-to-integer >> > logic, which I believe is duplicated for each type through GYB, and >> > share it in an extension so no Integer needs to write its own >> >

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> > > We might even be able to take the existing string-to-integer > > logic, which I believe is duplicated for each type through GYB, and > > share it in an extension so no Integer needs to write its own > > conversion. Is that something that should be added? > >

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Wed Jun 29 2016, Brent Royal-Gordon wrote: > We might even be able to take the existing string-to-integer > logic, which I believe is duplicated for each type through GYB, and > share it in an extension so no Integer needs to write its own > conversion. Is that

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md Minor omission I noticed: `Integer` doesn't formally model the `init?(_: String, radix: Int)` initializer. If it did, we could provide an `init?(_: String)` initializer that called through to

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Fri Jun 24 2016, plx wrote: > +1 but with a few reservations. > > # Arithmetic > > What *are* the expected semantics of the operators? It seems like you > can’t assume much about a generic `Arithmetic` type, e.g. in a generic > context I can’t reliably assume even

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Thu Jun 23 2016, Remy Demarest wrote: > I would also like to know why bit shifting and bit-wise and, or and > xor operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Mon, Jun 27, 2016 at 12:38 AM, Károly Lőrentey wrote: > > > On 2016-06-25, at 14:23, Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote: > > The first comment I have to make is that, as has already been noted by > plx, > > the Arithmetic protocol

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 26, 2016, at 6:38 PM, Károly Lőrentey via swift-evolution > wrote: > > I’m not sure if this has been mentioned yet, but the semantics of Integer > operations also needs to be tied down. In particular, the expected behavior > of the remainder operation (in

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On 2016-06-25, at 14:23, Nicola Salmoria via swift-evolution > wrote: > The first comment I have to make is that, as has already been noted by plx, > the Arithmetic protocol looks like a "bag of syntax" with loose semantics > attached. It will be used by signed

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? This is a great proposal which was sorely needed, so I strongly support it in general. I have a few comments and suggestions to make. First of all, a bit of background to explain where I'm coming from: in the past weeks I have been working for

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 24, 2016, at 15:03, Nicola Salmoria via swift-evolution > wrote: > > > > On Fri, Jun 24, 2016 at 11:45 PM, Max Moiseev > wrote: >> However, division by 0 isn't an overflow: it's an undefined operation. I >>

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

As someone who’ll likely make use of this protocol, I’m in favor of a “halfWidthDivide” (or whatever it’s called). As someone who’ll likely end up writing at least one type which will conform to `Integer`, I’m not looking forward to implementing 503 little functions & computed properties

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

+1 I've read the proposal and I've been following the conversation for some days now. I don't have anything else to add to the concerns that have already been discussed, but I would like to reiterate on the fact that having the ,absoluteValue, property but without substituting 'abs' will induce

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> However, division by 0 isn't an overflow: it's an undefined operation. I find > it somewhat surprising that dividedWithOverflow/remainderWithOverflow allow > attempting this operation. I tried to say that in my previous email. I agree that division by zero is NOT the overflow and should

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 24, 2016, at 2:52 PM, Haravikk via swift-evolution > wrote: > > >> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution >> wrote: >> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which >> will

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

The operation I want is the inverse of doubleWidthMultiply, where you have a (high, low) word pair and you want to divide it by a single word, getting a quotient and remainder. This is an important building block for implementing arbitrary precision division. Intel’s DIV can do this in a single

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution > wrote: > I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which > will likely lead to a measurable speedup. Why is there no > `doubleWidthQuotientAndRemainder` or

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 23:06, Nicola Salmoria via swift-evolution > wrote: > > > > On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev > wrote: > Hi Nicola, > > > For these reasons, I think it would make sense to explicitly

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? +1 in general > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes, with some nitpicks detailed below. > * If you have used other languages

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 14:38, Nicola Salmoria via swift-evolution > wrote: > > Max Moiseev via swift-evolution writes: > >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under > what situations would >> you have an overflow?

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Nicola, > For these reasons, I think it would make sense to explicitly request that > the remainder operation never traps, and remove the overflow variants. It will still trap when you divide by 0. But in that case falling back to the same generic overflow logic is not the best idea. I agree

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Remy, > I would also like to know why bit shifting and bit-wise and, or and xor > operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable way consistent with the protocol. Wouldn't it? The

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Xiaodi, > Q2: I do not understand the comment explaining signBitIndex. I thought I > understood what it does from the name, but the comment says it's not the > right name. So what is signBitIndex? The name is good but the way it is implemented in the prototype currently is NOT what the

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Félix, > Do we lose the ability to create a signed integer from an unsigned bit > pattern? As I mentioned in one of the earlier replies, the proposal does not contain the full API diff. `init(bitPattern:)` is very useful and will remain. However, I don’t think it should be added to any of

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi David, > In addition to the technical review, I would like to point out that the > definition of Arithmetic appears to be missing some underscores in > add/adding/subtract/subtracting Thank you! I’ll fix it. > For Integer, does the presence of signBit indicate an expectation that signed >

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? +1 The protocols are well thought out and make total sense to me. I only have a miner gripe with the naming of: func nthWord(n: Int) -> UInt Which reads very weird. Why not: func word(at: Int) -> UInt > * Is the problem being

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Is there a way to get an optional initializer that returns `nil` if the > operand can't be represented? That’s in the Arithmetic Protocol in the proposal: /// Initializes to the value of

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Do we lose the ability to create a signed integer from an unsigned bit > pattern? The existing `init(bitPattern x: UIntN)` are still present on the concrete types in the prototype. There’s a

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution > wrote: > > What is the cost of heterogeneous comparison? Smaller-than-wordsize comparisons will fall out for free in most cases. For word size and larger types, there’s one extra test in some

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Do we lose the ability to create a signed integer from an unsigned bit pattern? Is there a way to get an optional initializer that returns `nil` if the operand can't be represented? What is the cost of heterogeneous comparison? Félix > Le 22 juin 2016 à 22:42:00, David Waite via

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

In addition to the technical review, I would like to point out that the definition of Arithmetic appears to be missing some underscores in add/adding/subtract/subtracting > > > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md > > * What is

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Jun 22, 2016, at 9:32 PM, Karl via swift-evolution > wrote: > > I would like ‘floor’ and ‘ceil’ to be part of the standard library (or some > equivalent). It annoys me that I have to import Darwin/Glibc to properly > convert between

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? This looks really great! Thank you team for all of your hard work on improving the numeric protocols in Swift 3. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. The current protocols leave a

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Karl - Absolute value of `Int.min` is currently not representable by an Int. On Wed, Jun 22, 2016 at 9:32 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Looks very good. A couple of points: > > - I’m not convinced about ‘absoluteValue’, with an associated type. I >

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

+1 Looks very good. A couple of points: - I’m not convinced about ‘absoluteValue’, with an associated type. I think it should return the same value as ‘abs()’ or have a different name if it’s really needed at all; the example of a print function is a bit weak IMO. - I’m not sure about an

[swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hello Swift community, The review of "SE-0104: Protocol-oriented integers" begins now and runs through June 27. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md Reviews are an important part of the Swift evolution