[Review] SE-0104: Protocol-oriented integers


(Chris Lattner) #1

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 process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Xiaodi Wu) #2

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 process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?

This is excellent, and a huge improvement. Two questions and one ask:

Q1: With the adoption of this proposal, will FloatingPoint conform to
Arithmetic?
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?
Ask: You've got bitWidth and nthWord. Any way you could expose
__builtin_popcount()? Pretty please?

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes, the current tangle of protocols is not exactly fun to work with for
generics.

        * 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?

Not applicable, I think.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Read the proposal, worked with the existing protocols, thought carefully
about numbers in the context of the FloatingPoint discussion.

···

On Wed, Jun 22, 2016 at 7:52 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #3

  * 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 lot of room for improvement, which we see in this proposal.

  * Does this proposal fit well with the feel and direction of Swift?

Yes very much so.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal when a draft was available and again tonight. I have also encountered some of the challenges described with the existing protocols.

···

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Waite) #4

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 your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, oh yes.

  * Does this proposal fit well with the feel and direction of Swift?

It looks like a significant improvement.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I combed the proposal for questions, although most were answered by the time I hit the end.

-DW


(Karl) #5

+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 ‘nthWord()’ getter without a corresponding setter.
- 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 standard library types. Would this go with the initialisers from FloatingPoint on Integer, or somewhere on FloatingPoint?

Definitely a step up from what we have, and a good foundation to build on.

Karl

···

On 23 Jun 2016, at 02:52, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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 process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jordan Rose) #6

Hey, standard library folks. Glad we're doing this one. :slight_smile:

- I remain unconvinced that defining an Arithmetic that includes both exact and floating-point numbers is a good idea. All of the arguments from Swift 1 and 2 about why we didn't include this still seem relevant. To phrase it in generic programming terms, what algorithm would be generic over Arithmetic?

- What is Integer.init<T: FloatingPoint>(_:slight_smile: supposed to do if the floating-point value is larger than the maximum representable integer? Smaller than the minimum? (As a special case, negative, when the integer type is unsigned?) Infinity? NaN?

- Integer.init<T: Integer>(_:slight_smile: currently says "if it is representable". It should say something like "trapping if it is not representable".

- I find it odd that Integer.init(clamping:) privileges the bounds of fixed-width integers. I was going to suggest it should take a range to clamp to that defaults to the min and max, but that's not implementable for a BigInt.

- nthWord should count "from least-significant to most-significant" rather than "from the right".

- As mentioned before, it sounds like Integer requires a two's complement representation (if only so the result of nthWord can be interpreted correctly). That should probably be in the doc comment for the protocol.

- Why is bitWidth in bits but nthWord in words? (I know there's a good answer to this, but using them together seems like it will be common.)

- It's also probably worth calling out even more explicitly that bitWidth is a representation property, not a value property. That is, a BigInt with the value "1" could have a bitWidth of 1, 8, or 128.

- What does signBitIndex return if self is positive? I ask because it's just not in the doc comment, but thinking about the answer made it obvious that the correct return value for 0 is 0.

- For signed integers, does remainder(dividingBy:) have specified behavior for the sign of the result? See https://en.wikipedia.org/wiki/Modulo_operation.

- I do think having Swift.abs(_:slight_smile: and Integer.absoluteValue is confusing, but I don't know what to do about it.

- Why are bitwise operations limited to fixed-width integers? I see "The only difference is that because shifting left truncates the high bits of fixed-width integers, it is hard to define what a left shift would mean to an arbitrary-precision integer" further down, but I would just assume it wouldn't truncate (i.e. it would be a pure multiplication by two).

- Is there a requirement about left-shifting into the sign bit, for '<<' and for '&<<'?

- What is the ArithmeticOverflow type?

- When does the remainder operation overflow? (I just can't remember.)

- I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or bitwiseAND to be more explicit?

- maskingShiftLeft/Right seem underspecified in their doc comments. Why can't the protocol requirement just assume the shift amount has already been masked, instead of performing the masking themselves? Is it because we won't be able to optimize that away?

I think that's about it. Great work, all!
Jordan


(David Hart) #7

  * 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 addressed significant enough to warrant a change to Swift?

Yes, generic algorithms using integers were difficult to write. This is definitely needed for Swift 3.

  * Does this proposal fit well with the feel and direction of Swift?

It follows the logic behind the floating-point protocols.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A good read.

···

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karoy Lorentey) #8

* 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 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?

An afternoon of detailed study.

As the author of a Swift package for arbitrary integers (https://github.com/lorentey/BigInt), I’m delighted by this proposal.

I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which will likely lead to a measurable speedup. Why is there no `doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?

What is the intended behavior for `nthWord` for negative numbers? Can we prevent having to answer this question by e.g. moving this method down to UnsignedInteger? Big integer libs often use a signed magnitude representation; having to e.g. convert it to two’s complement on the fly to satisfy the API would be weird. (Also, the name `nthWord` seems unswifty to me.)

Like others on this list, I also find signBitIndex confusing. The name does not make much sense for unsigned integers, or signed integers that do not use an embedded sign bit. Is it supposed to return the width (in bits) of the binary representation of the integer’s absolute value? (Why -1 for zero, then? What’s the signBitIndex for 1?)

I can’t find any mention of the unary bitwise not (~) operation. It should be in FixedWidthInteger, right?

Binary bitwise operations (or/and/xor) are in FixedWidthInteger, but I believe they can be implemented on big integers in a way that is perfectly consistent with fixed width integers. Admittedly, I don’t know of any generic algorithms that want these.

To support big integers better, I think IntegerLiteralConvertible should also be updated at some point to work in terms of machine words. (Having to implement StringLiteralConvertible to provide source-level support for huge numbers works, but it isn’t great.)

I can see myself typing foo.absoluteValue instead of abs(foo) all the time; if its use is to be discouraged, perhaps a less prominent name would be better.

There is a typo in the Operators section: “Arithmetic” should read “Integer” in these two lines:

  public func % <T: Arithmetic>(lhs: T, rhs: T) -> T
  public func %= <T: Arithmetic>(lhs: inout T, rhs: T)

Remark: The gyb is nice when used in moderation, but I find parts of the prototype overuse templating to a point that’s bordering on obfuscation. E.g., I found this code especially hard to read:

  https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L1016-L1033

--
Karoly
@lorentey

On 2016-06-23, at 02:52, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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 process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(plx) #9

+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 things like these:

- `(x / y) * y == x` (or even “is close to" x)
- `(x + x + … + x) / n == x` (for `x` added together `n` times)
- `((x + y) + z) == (x + (y + z))` (etc.)
- `(x + y) - y == x`(? I think...)

…and so on; am I missing something?

If `Arithmetic` is as lacking in semantics as it seems, then it feels like one of those “bag of syntax” protocols that keep getting mentioned as against the stdlib philosophy.

# More Bit Operations

These don’t have to go into a v1, but I’d like to request seriously considering baking good support for things like popcount first set bit, etc., directly into the appropriate protocol (`FixedWidthInteger`?).

I won’t pretend there are specific generic algorithms simply waiting on their presence or anything…it just seems like a logical extension of the rationalized bit-shifting behavior in the proposal (and at least IMHO things like popcount really ought to have been fundamental operations on par with the shifts and bitwise operations, but that’s an aside).

# Endianness & Byte-Reversal

Endianness seems entirely unaddressed. I assume it’s intentional and, if so, I agree it’s *mostly* best omitted...but I’m curious if there’s already a plan for addressing that at this level or not? Even if just including a function like `func byteReversed() -> Self` (etc.) on a suitable protocol (e.g. `FixedWidthInteger`, or perhaps a new refinement thereof?).

I think that’s it for now. Overall I like it!

···

On Jun 22, 2016, at 7:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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 process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * 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?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alejandro Martinez) #10

+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 a lot of programers to use it anyway and make mistakes.
That's my only concern with it, the rest looks awesome. It is really amazing to see the power of protocols.
Thanks for the proposal :+1:t2:

···

Sent from my iPad

On 23 Jun 2016, at 01:52, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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 process. All reviews should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

   * What is your evaluation of the proposal?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * 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?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Nicola Salmoria) #11

* 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 educational purposes on a Rational<T:

type. This is one of those things that seem trivial at first

sight, but are surprisingly difficult to do right. Thoroughly testing and
avoiding traps or incorrect results in edge cases was a lot of work.
I have now updated my code to use the new interfaces described in the
proposal, and I was able to remove a lot of custom protocols and
boilerplate. So it was a net improvement.

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 integers, unsigned integers (naturals),
floating point numbers; and is an obvious conformance for a Rational type as
well.
In the proposal, there is no indication of the expected semantics of the
four basic operations.
- Are addition and multiplication commutative?
- Is multiplication distributive over addition?
- Is 'rhs != 0' a precondition for division?
- Presumably associativity must match the associativity of the operators.
- What is (a / b) * b?
- Is T(exactly: n) * x guaranteed to be == (x + ... + x) n times?

While this protocol is useful to simplify the implementation of operators,
it might be largely superseded by other improvements related to SE-0091.
Taken alone, I'm not sure it pulls its own weight.

For example say I wanted to write some generic code using values that
represent probabilities. I would need arithmetic to work on such values, but
since probabilities are strictly in the interval [0.0, 1.0], integers would
be useless. I could make the code generic over FloatingPoint, but a Rational
type would fit the bill as well, and guarantee accuracy. So to write
meaningful generic code I'd need a different protocol, one that made more
promises about the semantics of division.

Now about the AbsoluteValue associatedtype, which several other people have
already shown doubts about.
I found it useful, precisely for the reason stated in the proposal
(generating the description of a Rational). However, it seems to be mostly
an implementation detail, used to:
1) work around the fact that -Int.min isn't representable in two's complement;
2) provide a way to get the unsigned version of an integer type, to be used
by the doubleWidthMultiply() return type.

These uses suggest that the Integer protocol might not be the best place for
this associatedtype: both of the use cases above would not apply to a
BigInt. It seems more appropriate for it to be part of FixedWidthInteger.
It might even make sense to rename it UnsignedSelf, to make it clear that
it's intended to be the unsigned equivalent of Self.

I also join Karoly's request for double-width division operations. In
particular I would suggest:

static func doubleWidthDivideWithOverflow(_ lhs: (high: Self, low:
AbsoluteValue), by rhs: Self) -> (partialValue: Self, overflow:
ArithmeticOverflow)

static func doubleWidthRemainder(_ lhs: (high: Self, low: AbsoluteValue), by
rhs: Self) -> Self

Note that I needed to use static members here, because the first argument of
the division is not Self. Alternatively, the result of doubleWidthMultiply()
could be a struct, so that double-width division operations could be members
of that struct.

These operations are difficult to implement, and are very useful.

In my specific use case of Rational, addition is the trickiest operation to
implement because it can have transient overflows, which get simplified in
the final result. To handle them, I need to do two double-width multiplies,
followed by a double-width addition (which is easily implemented without
explicit support from the standard library). Then I need a double-width
remainder to compute the GCD, and finally an overflowing double-width
division to attempt fitting the result in a single-width numerator.

Without support for double-width division, the proposal falls short of being
really useful for this kind of operations.

Finally, I don't understand this example, which is also repeated twice in
the proposal. Is it perhaps a copy&paste error?

public struct Int8 {
  public func addingWithOverflow(_ rhs: DoubleWidth<T>)
    -> (partialValue: DoubleWidth<T>, overflow: ArithmeticOverflow) {
    // efficient implementation
  }
}

* Is the problem being addressed significant enough to warrant a change to

Swift?

Absolutely. Working with integer types in generic code is currently one of
the most frustrating experiences in Swift. The proposal should address most
of the common issues.

* Does this proposal fit well with the feel and direction of Swift?

Very well. The new protocols are much more consistent and cohesive than the
status quo.

* If you have used other languages or libraries with a similar feature,

how do you feel that this proposal compares to those?

I haven't.

* How much effort did you put into your review? A glance, a quick reading,

or an in-depth study?

Many hours of experience with the current IntegerArithmetic hierarchy,
carefully read all the discussion, and used the new semantics in real code
obtaining significant improvements.

Thanks,
Nicola


(TJ Usiyan) #12

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
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 ‘nthWord()’ getter without a corresponding setter.
- 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 standard library types. Would this go with the
initialisers from FloatingPoint on Integer, or somewhere on FloatingPoint?

Definitely a step up from what we have, and a good foundation to build on.

Karl

> On 23 Jun 2016, at 02:52, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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 process. All
reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * 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?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _______________________________________________
> 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


(Stephen Canon) #13

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 standard library types. Would this go with the initialisers from FloatingPoint on Integer, or somewhere on FloatingPoint?

These should simply be added to FloatingPoint. I'll write a tiny proposal for that.

···

Sent from my iPhone

On Jun 22, 2016, at 9:32 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:


(Félix Cloutier) #14

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 swift-evolution <swift-evolution@swift.org> a écrit :

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 your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, oh yes.

  * Does this proposal fit well with the feel and direction of Swift?

It looks like a significant improvement.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I combed the proposal for questions, although most were answered by the time I hit the end.

-DW

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Psycho Hedgehog) #15

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?

···

Le 22 juin 2016 à 23:23, Félix Cloutier via swift-evolution <swift-evolution@swift.org> a écrit :

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 swift-evolution <swift-evolution@swift.org> a écrit :

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 your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, oh yes.

  * Does this proposal fit well with the feel and direction of Swift?

It looks like a significant improvement.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I combed the proposal for questions, although most were answered by the time I hit the end.

-DW

_______________________________________________
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


(Max Moiseev) #16

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 Integers will have a two's complement representation?

Yes. That is correct.

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

If you look at the prototype here: https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L789 there is exactly the check that you’ve mentioned, but for all signed integers. Besides, it is very convenient to have all the arithmetic operations be implemented the same way, even if there were no real overflows for division.

Max

···

On Jun 22, 2016, at 10:42 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

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 your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, oh yes.

  * Does this proposal fit well with the feel and direction of Swift?

It looks like a significant improvement.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I combed the proposal for questions, although most were answered by the time I hit the end.

-DW

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Max Moiseev) #17

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 the protocols. Mostly because in order to do so we would need to introduce another associated type — for the signed/unsigned counterpart with the same width.
Can you think of an example where this feature would be useful in the generic code?

Max

···

On Jun 22, 2016, at 11:23 PM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

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 swift-evolution <swift-evolution@swift.org> a écrit :

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 your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what situations would you have an overflow? I could only come up with something like Int.min.dividedWithOverflow(-1).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, oh yes.

  * Does this proposal fit well with the feel and direction of Swift?

It looks like a significant improvement.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I combed the proposal for questions, although most were answered by the time I hit the end.

-DW

_______________________________________________
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


(Max Moiseev) #18

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 name suggests. This is the point of the comment. I plan to revisit the prototype and either make it behave the way it’s called, or find a better name for what it currently does.

Ask: You've got bitWidth and nthWord. Any way you could expose __builtin_popcount()? Pretty please?

I don’t mind adding it to the concrete types, similar to `countLeadingZeros` (see https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L855). Do you think it should be a protocol requirement instead?

Max

···

On Jun 22, 2016, at 6:13 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 7:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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 process. All reviews should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

        * What is your evaluation of the proposal?

This is excellent, and a huge improvement. Two questions and one ask:

Q1: With the adoption of this proposal, will FloatingPoint conform to Arithmetic?
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?
Ask: You've got bitWidth and nthWord. Any way you could expose __builtin_popcount()? Pretty please?

        * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, the current tangle of protocols is not exactly fun to work with for generics.

        * 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?

Not applicable, I think.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, worked with the existing protocols, thought carefully about numbers in the context of the FloatingPoint discussion.

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Stephen Canon) #19

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 cases, but the (very small) added cost is vastly preferable to people rolling their own workarounds and getting it wrong.

– Steve

···

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

What is the cost of heterogeneous comparison?


(Stephen Canon) #20

The existing `init(bitPattern x: UIntN)` are still present on the concrete types in the prototype. There’s a new init at the Protocol level that handles the fully generic case:

/// Creates in instance of `Self` from `source` by sign-extending it
/// indefinitely and then truncating to fit `Self`.
init<T : Integer>(extendingOrTruncating source: T)

– Steve

···

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

Do we lose the ability to create a signed integer from an unsigned bit pattern?