Looks like this problem has been caused by a new deprecated overload of `withUnsafeMutableBytes` method added by this commit - d030354 Since we don't rank down deprecated overloads this makes your expression truly ambiguous.

This is the overload in question https://github.com/apple/swift/blob/master/stdlib/public/Darwin/Foundation/Data.swift#L2169

Honestly if we are to move full steam ahead without breaking binary compatibility we need to deprecate and replace. It seems to me the compiler should down rank deprecated overloads.

I need to break this apart more. Often times the compiler just flakes out with blocks and the diagnostic.

The choice not to down rank deprecated overloads has been a deliberate one, since we'd want the code to use the old overload if possible. Diagnostic about `>>` is indeed an incorrect one unfortunately, but should point to `withUnsafeMutableBytes` instead.

Perhaps if the decision was made explicitly then it would be useful to have an attribute to mark them as less desirable by the solver. The deprecated method in question was marked that way not because we wanted a new interface only, it was deprecated because the old one was really unsafe (like wrong and could lead to undefined behavior and other nasties).

I don't see what the ambiguity here has anything to do with our changes. The issue in question is 0xff >> zerobits, which has nothing to do with Data.
More so, bytes[0] &= UInt8(...) should be unambiguous regardless of what's in the UInt8 initializer, since it's a standalone subexpression.

@itaiferber The problem is that type-checker now finds 4 solutions related to `withUnsafeMutableBytes`, 3 of them have the same overload (and different overloads for `>>`):

```
Foundation.(file).Data.withUnsafeMutableBytes as @lvalue Data.withUnsafeMutableBytes: ((UnsafeMutablePointer<T>) throws -> T) throws -> T
```

The forth however has this overload:

```
Foundation.(file).Data.withUnsafeMutableBytes as @lvalue Data.withUnsafeMutableBytes: ((UnsafeMutableRawBufferPointer) throws -> T) throws -> T
```

and overload of `>>` picked from protocol requirement on BinaryInteger

Which makes this ambiguous.

After further discussion with @itaiferber we came to an understanding that unfortunately there is no way to resolve this issue because type-checker can't really distinguish this properly and old overload can't be obsoleted in Foundation. You'd have to use a temporary variable as a workaround.

> Perhaps if the decision was made explicitly then it would be useful to have an attribute to mark them as less desirable by the solver.

Can we use the @_disfavoredOverload attribute?

I'd rather not because that's not something we'd like to keep.