There's the obvious fix of adding UInt16(...) to the second 1 (bitPattern &>> (count &- 1) ^ UInt16(1)), but, surprisingly/why I think this is a bug, inference can also be made to work by adding `Int(...)` to the first `1` (bitPattern &>> (count &- Int(1)) ^ 1), or by removing the subtraction completely (bitPattern &>> count ^ 1).

@swift-ci create

cc @xedin

It's a bad diagnostic. We don't have heterogeneous shifts for the masking shifts, so we should be complaining about the count here.

Note that the precedence is
(bitPattern &>> (count &- 1)) ^ 1

and not

bitPattern &>> ((count &- 1) ^ 1)

Is the lack of heterogenous overloads in this case is intentional, @moiseev?

Taking a look at Integers.swift.gyb, it does look to be intentional.

Well perhaps there is more going on here than I noticed. There is a heterogeneous masking shift in FixedWidthInteger.

@rudkx there are heterogeneous overloads like &>> <Value: FixedWidthInteger, Shift: BinaryInteger>, and there are also homogeneous ones on concrete integer types.

I agree that it looks like the wrong diagnostics, what I think happens is: bitPattern &>> (count &- 1) – this part gets Int because count is Int. Then ^ gets applied to Int and Int and results in Int, but then it tries to squeeze this value into a Uint16 and fails.

I think there's more than just being a wrong diagnostic: the version without a subtraction bitPattern &>> count ^ 1 compiles fine, even though, presumably, the bitPattern &>> count subexpression should be being getting the same type as the shift in the version with the subtraction.

This was fixed recently on master with #33060

Could you please verify using the latest master toolchain from https://swift.org/download/#snapshots? Thank you!

@hborla I tested with the DEVELOPMENT-SNAPSHOT-2020-08-07-a snapshot available in swiftenv, and it compiles without errors 🙂 thanks!