[Pitch #2] Safe Access to Contiguous Storage

[Karl]

@glessard

I believe that possibility is marked by the particle "raw" in the type name, just like UnsafeRawPointer. There are different types of unsafety and I believe it is useful to use different words for each when possible.

I don't think "raw" quite communicates the severity of the problem - we use "raw" for lots of things that are perfectly safe (the one developers are most likely to be familiar with is RawRepresentable and its rawValue property).

And yes, there are many ways operations can be unsafe - but the way we have used "unsafe" in Swift has had a consistent meaning; that being:

1. The operation has certain preconditions.

2. Those preconditions are not automatically enforced (at compile-time or run-time) and require manual reasoning by the programmer.

3. Violating the operation's preconditions may cause undefined behaviour.

It has never been limited to issues of lifetimes or bounds-checking.

In this case, I think the operation absolutely fits the bill for being labelled as unsafe. It is essentially the operation which we currently call unsafeBitCast, but being exposed on a type whose entire reason for being is that it is supposedly safe.

@glessard

In the case of load<T>(as:), there is no constraint on the type, and that's significantly more unsafe. We could add a BitwiseCopyable constraint on this as well, thereby limiting the fully-unconstrained load operation to being used via UnsafePointer in a withUnsafeBytes() closure.

I don't think BitwiseCopyable has any bearing on this. As I described in a recent thread, I don't think it actually provides safety. The other operations could even drop the BitwiseCopyable constraint and I don't think they would be any less safe.

@Karl

I can recall suggestions that BitwiseCopyable could allow for these constructs to be written safely - so you could write <T: RawRepresentable> where T.RawValue: BitwiseCopyable. I'm not entirely sure that is safe, either.

For an integer or float, it doesn't matter; it's not a safety issue. You may read an unexpected/nonsense value, but every bit-pattern is defined. If you load an integer or float from some unknown memory address, the compiler obviously won't assume any particular value in a way that UB could result if the assumption was incorrect.

But for an enum, if you load an enum from random bytes, it may have a bit-pattern that doesn't correspond to any of its cases. So when performing an exhaustive switch, it may be that you do not land in any branch:

enum MyEnum: BitwiseCopyable {
  case a, b, c
} // size: 1 byte

let myEnumValue = RandomBytes(1).load(as: MyEnum.self)

var x: SomeClass
switch myEnumValue {
case .a: x = SomeClass(...)
case .b: x = SomeClass(...)
case .c: x = SomeClass(...)
}
// Is 'x' definitely initialised here?
// What if myEnumValue is none of a/b/c?

I don't think the compiler can/would guarantee that all enum switches land in a deterministic branch, even if the enum has an invalid bit-pattern. At the same time, MyEnum is unquestionably BitwiseCopyable. So clearly BitwiseCopyable isn't the constraint we're looking for.

Here's an example of this happening. We switch over an enum with 4 cases, which the compiler optimises to a table lookup, assuming it will only ever see those 4 values. By constructing an invalid enum case, we deference past the end of the table. When executing on Godbolt, I find that if the function containing the switch is @inline(never) we just read a value from random memory, and if it isn't, it appears to crash (but I don't believe that is guaranteed).

It troubles me that this could be done without any notice at the call site, on a type which claims to be safe. In real code you likely wouldn't see that the loaded value clearly does not correspond to an enum case.

@glessard

These are the first non-escapable types to be pitched, but we do not yet know in which order things will land in the standard library. But we need some concrete things to build upon.

Span, ~Escapable types and ~Copyable types need to be prototyped and used so that the generalized Sequence-like and Collection-like don't get designed in a vacuum. Pitching and prototyping the feature also allows the adventurous like you to try things out and point out mistakes and omissions!

For sure - I do appreciate the progress that is being made, and it is exciting. It's particularly nice that there is a working prototype to experiment with.

What I'm saying is that I hope this doesn't progress all the way to a full review and acceptance before we have a clearer picture of what non-copyable collection interfaces will look like. As far as I can tell, there have been no public discussions on that topic, while this is already the second pitch for Span.

In other words, I'm saying that in my opinion, there is a preferred order in which things land in the standard library.