[Pitch 2] Safe loading of values from `RawSpan`

[tera]

@glessard

@ksluder

The solution of using UInt16.init(bigEndian:) makes me uncomfortable because it implies temporarily modeling data in the correct type but with an invalid value.

Exactly this. If we had avoided the misadventure that are .init(bigEndian:), the .bigEndian property and their converses, there would be no way around providing byte order control in the integer-loading operations of the standard library. We shouldn’t add designs with holes that need to be papered over by old bad ideas; we should add the best designs we can.

IIUC there'll be a problem specifying correct byte order for multi-component types like the mentioned: struct Point { var x, y: Int }

Consider having two sets of API's - one set for integers/floats with byte order parameter, another for other types without byte order parameter.

In contrast, Range could not conform to FullyInhabited, even though on the surface it has the same composition as Point. There is a semantic constraint between two two stored properties of Range: lowerBound must be less than or equal to upperBound. This makes it unable to conform to FullyInhabited.

What happens when loading or storing from an invalid offset? I guess a trap? †

By the same logic, what if working with Range<Int> was allowed and worked fine when the bounds play fair, and traps when lowerBound is greater than upperBound? (The actual checking/trapping could be implemented in some later compiler version as in proposal.)

---

† BTW, have we considered making those API's throwing instead?