Hm. They should probably be consistent, and I guess array-to-pointer is the useful one, but it's a little unfortunate that there's then no way to request inout-to-pointer.

Though not quite as convenient as an implicit conversion, using withUnsafePointer(to:_:) is one option that allows you to get inout-to-pointer for an array (although it doesn't handle optionality). But given that it's probably not as common of a thing to ask for, maybe that's an okay balance.

Oh, right, this only comes up when going straight to UnsafeRawPointer, because otherwise it's not ambiguous.

Wait, hang on. You're not supposed to use & for an immutable array-to-pointer conversion.

Oh, really? Even though it can be expressed without &, using it with & to me seems to be the natural consequence of allowing both array-to-pointer and mutable-pointer-to-immutable-pointer argument conversions (although it's modelled by a single conversion in the constraint system).

It's also consistent with inout-to-pointer when used with immutable pointer types, e.g:

func foo(_ ptr: UnsafePointer<Int>) {}

var value = 0
foo(&value)

Yeah, inout-to-pointer is different because you need the address of the variable's storage. For array-to-pointer you don't.

I guess that's fair – although IMO there's a nice symmetry in allowing & for such a conversion, as I believe it means that you should be able to refactor an UnsafeMutableRawPointer parameter to a UnsafeRawPointer parameter without breaking any call-sites.

But anyway, should I file a separate bug for it?