[late pitch] UnsafeBytes proposal


(Jason Cardwell) #1

As an average developer that likes to look at this stuff on occasion, I thought I'd toss in my take on 'byte' terminology. I know little about machine architecture; but, it feels like the programming community in general has taken the term byte to mean 8 bits. Since it is actually the smallest unit of addressable memory, which is much more abstract, the APIs tend to go all wonky. In my head I think of it in a way not unlike the Int, IntMax, Int64 family. I haven't dealt with an architecture where IntMax = Int32 in so long that as I'm coding my head translates them all to 'a 64 bit integer'. However, the aliasing is enough to keep me honest from time to time as it forces me to consider whether I can count on a certain size for a particular situation. I don't know, something about the Byte and UInt8 situation feels the same to me. It seems like the standard library should be telling me upfront somewhere what the hell I can safely call a byte for the target architecture. The need for this proposal arose out of developers like me wanting to work with bytes. If some future architecture allowed addressing 4 bits instead of 8, that's what I'd want to work with. It seems any confusion over interchangeable use of Byte and UInt8 stems from the varying levels of degree to which people see byte as an abstract term vs 8 bits. A simple declaration somewhere that officially tells us, "Hey, when you see mention of byte it is safe to think in your head '8 bits''' would make it all fall in line for me. Anywho, thanks so far for the wonderful language.

Jason Cardwell

···

On Aug 19, 2016, at 12:43 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Aug 19, 2016 at 2:32 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Aug 2016, at 19:35, Andrew Trick <atrick@apple.com> wrote:

On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution <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
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.

But I thought what Andy's saying is that he's proposing to standardize the usage of the word byte to mean raw memory and not 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Trent Nadeau) #2

For an architecture to be C-compatible, its byte size must be 8 bits. Given
the need to run C everywhere and that almost all OSes are written in C,
it's a very safe assumption that a byte equals 8 bits. At this point, I
think the only thing where that's not true are certain micro-controllers
for which there are specialized compilers.

In any case, LLVM (the compiler infrastructure on which the Swift compiler
is built) doesn't support architectures where that's not true.

···

On Tue, Aug 23, 2016 at 1:12 PM, Jason Cardwell via swift-evolution < swift-evolution@swift.org> wrote:

As an average developer that likes to look at this stuff on occasion, I
thought I'd toss in my take on 'byte' terminology. I know little about
machine architecture; but, it feels like the programming community in
general has taken the term byte to mean 8 bits. Since it is actually the
smallest unit of addressable memory, which is much more abstract, the APIs
tend to go all wonky. In my head I think of it in a way not unlike the Int,
IntMax, Int64 family. I haven't dealt with an architecture where IntMax =
Int32 in so long that as I'm coding my head translates them all to 'a 64
bit integer'. However, the aliasing is enough to keep me honest from time
to time as it forces me to consider whether I can count on a certain size
for a particular situation. I don't know, something about the Byte and
UInt8 situation feels the same to me. It seems like the standard library
should be telling me upfront somewhere what the hell I can safely call a
byte for the target architecture. The need for this proposal arose out of
developers like me wanting to work with bytes. If some future architecture
allowed addressing 4 bits instead of 8, that's what I'd want to work with.
It seems any confusion over interchangeable use of Byte and UInt8 stems
from the varying levels of degree to which people see byte as an abstract
term vs 8 bits. A simple declaration somewhere that officially tells us,
"Hey, when you see mention of byte it is safe to think in your head '8
bits''' would make it all fall in line for me. Anywho, thanks so far for
the wonderful language.

Jason Cardwell

On Aug 19, 2016, at 12:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Fri, Aug 19, 2016 at 2:32 PM, Karl via swift-evolution < > swift-evolution@swift.org> wrote:

On 19 Aug 2016, at 19:35, Andrew Trick <atrick@apple.com> wrote:

On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution < >> swift-evolution@swift.org> wrote:

On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution < >> swift-evolution@swift.org> wrote:

On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution < >> 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
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.

But I thought what Andy's saying is that he's proposing to standardize the
usage of the word byte to mean raw memory and not 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Félix Cloutier) #3

I'm told that POSIX requires that bytes are 8 bits, but modern C only says that it has to be at least 8. If your platform can only address one size, then `char` will take that size. Larger-than-8 bit sizes are apparently mostly found on DSPs.

LLVM can be (and has been <http://lists.llvm.org/pipermail/llvm-dev/2014-September/076572.html>) extended to support bytes that are not 8 bits.

That said, it's the kind of thing that comes into being with corporate support, and the main corporate sponsor behind Swift is mostly interested in x86 and ARM. It might be a while before this assumption has to be seriously revisited, and it would be quite breaking.

Félix

···

Le 23 août 2016 à 17:28:53, Trent Nadeau via swift-evolution <swift-evolution@swift.org> a écrit :

For an architecture to be C-compatible, its byte size must be 8 bits. Given the need to run C everywhere and that almost all OSes are written in C, it's a very safe assumption that a byte equals 8 bits. At this point, I think the only thing where that's not true are certain micro-controllers for which there are specialized compilers.

In any case, LLVM (the compiler infrastructure on which the Swift compiler is built) doesn't support architectures where that's not true.

On Tue, Aug 23, 2016 at 1:12 PM, Jason Cardwell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As an average developer that likes to look at this stuff on occasion, I thought I'd toss in my take on 'byte' terminology. I know little about machine architecture; but, it feels like the programming community in general has taken the term byte to mean 8 bits. Since it is actually the smallest unit of addressable memory, which is much more abstract, the APIs tend to go all wonky. In my head I think of it in a way not unlike the Int, IntMax, Int64 family. I haven't dealt with an architecture where IntMax = Int32 in so long that as I'm coding my head translates them all to 'a 64 bit integer'. However, the aliasing is enough to keep me honest from time to time as it forces me to consider whether I can count on a certain size for a particular situation. I don't know, something about the Byte and UInt8 situation feels the same to me. It seems like the standard library should be telling me upfront somewhere what the hell I can safely call a byte for the target architecture. The need for this proposal arose out of developers like me wanting to work with bytes. If some future architecture allowed addressing 4 bits instead of 8, that's what I'd want to work with. It seems any confusion over interchangeable use of Byte and UInt8 stems from the varying levels of degree to which people see byte as an abstract term vs 8 bits. A simple declaration somewhere that officially tells us, "Hey, when you see mention of byte it is safe to think in your head '8 bits''' would make it all fall in line for me. Anywho, thanks so far for the wonderful language.

Jason Cardwell

On Aug 19, 2016, at 12:43 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Fri, Aug 19, 2016 at 2:32 PM, Karl via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 19 Aug 2016, at 19:35, Andrew Trick <atrick@apple.com <mailto:atrick@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

‘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.

But I thought what Andy's saying is that he's proposing to standardize the usage of the word byte to mean raw memory and not 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

Right, Swift depends on Clang. Clang assumes that the target machine has 8-bit-byte-addressable memory. I don’t see any reason that Swift should pretend to work on the (only historically interesting) systems that had 9-bit (or any other weird number) addressable units.

-Chris

···

On Aug 23, 2016, at 5:28 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

For an architecture to be C-compatible, its byte size must be 8 bits. Given the need to run C everywhere and that almost all OSes are written in C, it's a very safe assumption that a byte equals 8 bits. At this point, I think the only thing where that's not true are certain micro-controllers for which there are specialized compilers.


(Jason Cardwell) #5

To be a little more clear, all I meant to point out was the difference between what originated as an abstract term and what is decidedly a concrete term. Everybody seems to have merged the two as a result of how the architecture evolved over time. My first degree was in English and that side of me is wondering if the entry for byte in the Oxford English Dictionary would show it as historical or current. If the two words are entirely equal than just drop one and use the other everywhere. If using the there one everywhere seems off in some places then ask why they aren't interchangeable. When the byte typealias was first dropped I added my own to use in a custom framework. Later I removed it because it bugged me using two different types to mean the same thing. I don't care one way or the other so long as there is consistency.

···

On Aug 23, 2016, at 5:28 PM, Trent Nadeau <tanadeau@gmail.com> wrote:

For an architecture to be C-compatible, its byte size must be 8 bits. Given the need to run C everywhere and that almost all OSes are written in C, it's a very safe assumption that a byte equals 8 bits. At this point, I think the only thing where that's not true are certain micro-controllers for which there are specialized compilers.

In any case, LLVM (the compiler infrastructure on which the Swift compiler is built) doesn't support architectures where that's not true.

On Tue, Aug 23, 2016 at 1:12 PM, Jason Cardwell via swift-evolution <swift-evolution@swift.org> wrote:
As an average developer that likes to look at this stuff on occasion, I thought I'd toss in my take on 'byte' terminology. I know little about machine architecture; but, it feels like the programming community in general has taken the term byte to mean 8 bits. Since it is actually the smallest unit of addressable memory, which is much more abstract, the APIs tend to go all wonky. In my head I think of it in a way not unlike the Int, IntMax, Int64 family. I haven't dealt with an architecture where IntMax = Int32 in so long that as I'm coding my head translates them all to 'a 64 bit integer'. However, the aliasing is enough to keep me honest from time to time as it forces me to consider whether I can count on a certain size for a particular situation. I don't know, something about the Byte and UInt8 situation feels the same to me. It seems like the standard library should be telling me upfront somewhere what the hell I can safely call a byte for the target architecture. The need for this proposal arose out of developers like me wanting to work with bytes. If some future architecture allowed addressing 4 bits instead of 8, that's what I'd want to work with. It seems any confusion over interchangeable use of Byte and UInt8 stems from the varying levels of degree to which people see byte as an abstract term vs 8 bits. A simple declaration somewhere that officially tells us, "Hey, when you see mention of byte it is safe to think in your head '8 bits''' would make it all fall in line for me. Anywho, thanks so far for the wonderful language.

Jason Cardwell

On Aug 19, 2016, at 12:43 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Aug 19, 2016 at 2:32 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Aug 2016, at 19:35, Andrew Trick <atrick@apple.com> wrote:

On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution <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
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.

But I thought what Andy's saying is that he's proposing to standardize the usage of the word byte to mean raw memory and not 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Andrew Trick) #6

To be fair to Jason, I think he just wants the language to be explicit about a byte being an 8-bit numeric value.

That’s not quite what I’m trying to convey though. I want bytes to refer only to the in-memory layout of values of any type in 8-bit chunks per the ABI. Typically, loading a byte without imposing any type on the in-memory value should produce a UInt8 value. Swift should not have a Byte type because it would contradict this meaning and serve no purpose.

I’ve been working with developers who need to parse or stream binary data. It’s a common use case. What I’m proposing perfectly matches the intuition of these developers who are already using the same concepts and terminology that I am.

-Andy

···

On Aug 23, 2016, at 9:56 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 23, 2016, at 5:28 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

For an architecture to be C-compatible, its byte size must be 8 bits. Given the need to run C everywhere and that almost all OSes are written in C, it's a very safe assumption that a byte equals 8 bits. At this point, I think the only thing where that's not true are certain micro-controllers for which there are specialized compilers.

Right, Swift depends on Clang. Clang assumes that the target machine has 8-bit-byte-addressable memory. I don’t see any reason that Swift should pretend to work on the (only historically interesting) systems that had 9-bit (or any other weird number) addressable units.