Oh, one more comment: I suggest naming the primary protocol something other than "Integer", which IMHO is a little close to "Int" for a beginner. "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or "ArithmeticInteger"? Or to go with the representation thing, "BinaryInteger"? (Some of the requirements are at odds with a decimal-based implementation.)
Jordan > On Jun 23, 2016, at 13:50, Jordan Rose <[email protected]> wrote: > > Hey, standard library folks. Glad we're doing this one. :-) > > - 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>(_:) 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>(_:) 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 > <https://en.wikipedia.org/wiki/Modulo_operation>. > > - I do think having Swift.abs(_:) 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
