I don't support picking a single RHS type. Again I'll mention that the prototype <https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L1082> I'm already working on to replace the integer protocols and types already supports any integer type appearing on the RHS of a shift operation, where the LHS is any fixed-width integer type. It also supports negative shifts and overshifts without trapping or causing undefined behavior (as suggested by Steve Canon there's also a new masking shift operator that masks the RHS before shifting, for those who can't afford the branch).
> On Dec 19, 2015, at 7:43 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > > +1 to dropping the existing signatures and providing a consistent right-hand > side. > > I'm a little concerned about not allowing Int as the shift type. Even though > we disallow negative shifts, we generally encourage using 'Int' as the > "vocabulary" type for integers, which means any shift by a non-constant > amount might require a conversion. I do see that BigInts may be shifted by > more than 2^64, however, so hardcoding Int wouldn't be right either. > > (We do want to make sure the implementation is efficient when both argument > types are a machine-representable integers, though, which may not be possible > with all UnsignedIntegerTypes.) > > Jordan > >> On Dec 19, 2015, at 5:54 , Andrew Bennett via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> +1 >> >> Something worth considering with this proposal: Should it be IntMax rather >> than Int? (or UIntMax, does a negative count make sense?). >> >> Although it's probably never going to be enough if you want to calculate the >> next largest known prime number in swift, the last was 2^57885161 − 1. >> >> Also if it's in scope: >> >> Left and right shift are the only operators on integers that aren't >> generalised by a protocol. Every other operator is somehow part of >> IntegerType. >> >> See IntegerArithmeticType, SignedNumberType and BitwiseOperationsType. >> >> It would be nice to create a new protocol for something that can shift. The >> new protocol could be: >> protocol IntegerBitShiftType { >> var sizeInBits: UIntMax >> >> @warn_unused_result >> func <<(lhs: Self, rhs: UIntMax) -> Self >> >> @warn_unused_result >> func >>(lhs: Self, rhs: UIntMax) -> Self >> } >> >> If IntegerType conformed to that protocol I don't think there's anything I >> want that Int can do and IntegerType can't. >> >> A related but slightly off-topic gripe: >> Integer protocols in Standard Library define init(_: IntMax) or init(_: >> UIntMax), they assume that there isn't a wider type. When trying to make a >> new type conform to IntegerType (ie. a BigInt library) this can be an issue. >> >> It also seems to be necessary that things implementing IntegerType must >> conform to _MaxBuiltinIntegerType. It's type is much wider than IntMax (64x >> for me) and its interface is empty which makes it hard to conform. >> >> I think currently _MaxBuiltinIntegerType is 4096 bits, but it is still much >> smaller than what you want from a BigInt type. While I have suggested using >> IntMax in this implementation I think that IntMax is inherently flawed in >> its usage. However it is the best available at the moment in my opinion. >> >> Something like this may work in a more general case: >> >> protocol IntegerBitShiftType { >> @warn_unused_result >> func << <T: UnsignedIntegerType>(lhs: Self, rhs: T) -> Self >> >> @warn_unused_result >> func >> <T: UnsignedIntegerType>(lhs: Self, rhs: T) -> Self >> } >> >> >> On Sat, Dec 19, 2015 at 3:02 AM, Greg Titus via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> +1. In fact, I would go even farther than asking for an additional version >> that uses Int on the rhs, I think all of the existing definitions are >> arguably wrong and they should all just be changed to use Int. I just took a >> brief scan of all uses of >> and << in the stdlib: most use constants on the >> rhs, and so would be unaffected. It looks like all the rest either use Int >> on the lhs or require explicit casting or calling numericCast() to get the >> rhs to match. >> >> - Greg >> >> > On Dec 18, 2015, at 3:55 AM, Jeremy Pereira via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > These are the definitions of the right shift operators >> > >> > public func >>(lhs: Int8, rhs: Int8) -> Int8 >> > >> > public func >>(lhs: Int, rhs: Int) -> Int >> > >> > public func >>(lhs: UInt, rhs: UInt) -> UInt >> > >> > public func >>(lhs: Int64, rhs: Int64) -> Int64 >> > >> > public func >>(lhs: UInt64, rhs: UInt64) -> UInt64 >> > >> > public func >>(lhs: UInt8, rhs: UInt8) -> UInt8 >> > >> > public func >>(lhs: UInt16, rhs: UInt16) -> UInt16 >> > >> > public func >>(lhs: Int16, rhs: Int16) -> Int16 >> > >> > public func >>(lhs: Int32, rhs: Int32) -> Int32 >> > >> > public func >>(lhs: UInt32, rhs: UInt32) -> UInt32 >> > >> > >> > Note that both left and right hand side are of the same type. In my >> > opinion, rhs, which represents the number of bits to shift, should always >> > be an Int e.g. >> > >> > public func >>(lhs: UInt64, rhs: Int) -> UInt64 >> > >> > The two operands are fundamentally different, the left hand one is >> > conceptually an array of bits and the right hand one is conceptually a >> > count. >> > >> > The current definitions mean that I almost always have to do a cast on the >> > right operand with shift operations. e.g. the following snippet that >> > converts a UInt64 into an array of boolean values. >> > >> > let aNumber: UInt64 = 0x123456 >> > var numberAsBits: [Bool] = []; >> > for i in 0 ..< 64 >> > { >> > numberAsBits.append((aNumber >> i) & 1 != 0); // Error because i >> > needs to be cast to a UInt64 >> > } >> > >> > I would like additional versions of the shift operator where rhs is an Int >> > please. >> > >> > Needless to say, the same applies to the left shift operators. >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
