> On 19 Aug 2016, at 19:35, Andrew Trick <atr...@apple.com> wrote:
>
>
>> On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>>
>>>> It seems like there’s a potential for confusion here, in that people may
>>>> see “UInt8” and assume there is some kind of typed-ness, even though the
>>>> whole point is that this is untyped. Adjusting the header comments
>>>> slightly might help:
>>>>
>>>>
>>>> /// A non-owning view of raw memory as a collection of bytes.
>>>> ///
>>>> /// Reads and writes on memory via `UnsafeBytes` are untyped operations
>>>> that
>>>> /// do no require binding the memory to a type. These operations are
>>>> expressed
>>>> /// in terms of `UInt8`, though the underlying memory is untyped.
>>>>
>>>> …
>>>>
>>>> You could go even further towards hinting this fact with a `typealias Byte
>>>> = UInt8`, and use Byte throughout. But, I don’t know if that’s getting too
>>>> excessive.
>>>
>>> I don't think that's too excessive at all. I might even go further and say
>>> that we should call it "Untyped" instead of "Byte", to really drive home
>>> the point (many people see "byte" and think "8-bit int", which is merely a
>>> side effect of CPUs generally not having support for types *other* than
>>> ints and floats, rather than a reflection of the true "type" of the data).
>>>
>>> - Dave Sweeris
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> ‘Byte’ is sufficient, I think.
>>
>> In some sense, it is typed as bytes. It reflects the fact that anything that
>> is representable to the computer must be expressible as a sequence of bits
>> (the same way we have string de/serialisation — which of course is not to
>> say that the byte representation is good for serialisation purposes).
>> “withUnsafeBytes” can be seen as doing a reversible type conversion the same
>> way LosslessStringConvertible does; only in this case the conversion is free.
>
> Yes. Byte clearly refers to a value's in-memory representation. But typealias
> Byte = UInt8 would imply the opposite of what needs to be conveyed. The name
> Byte refers to raw memory being accessed, not the value being returned by the
> collection. The in-memory value's bytes are loaded from memory and
> reinterpreted as UInt8 values. UInt8 is the correct type for the value after
> it is loaded. Calling the collection’s element type Byte sends the wrong
> message. e.g. [Byte] or UnsafePointer<Byte> would be nonsense.
>
> Keep in mind the important use case is code that needs to work with a
> collection of UInt8 values without knowing the type of the values in memory.
> This makes it intuitive and convenient to implement correctly without needing
> to reason about the Swift-specific notions of raw vs. typed pointers and
> binding memory to a type.
>
> The documentation should be fixed to clarify that the in-memory value is not
> the same as the loaded value.
>
> -Andy
Well, a byte is a numerical type as much as a UInt8 is. We attach meaning to it
(e.g. a memory location), but it’s just a number. Perhaps it shouldn’t be a
typealias then (if the alias would have some kind of impure semantics), but its
own type which is exactly the same as UInt8. Typing raw memory accesses with
`Byte` to indicate that the number was read from raw memory is a good idea for
type-safety IMO.
You’d wonder if we could have initialisers for other integer types which take a
fixed-size array of `Byte`s - e.g. UInt16(_: [2 * Byte]). That wouldn’t make as
much sense with two UInt8s.
Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
