Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-10 Thread Susan Cheng via swift-evolution
Thanks, but we can implement Codable for BEInteger and LEInteger types. public struct BEInteger : FixedWidthInteger { public var bitPattern: BitPattern public init(bitPattern: BitPattern) public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread John McCall via swift-evolution
> On Jul 9, 2017, at 6:57 PM, Robert Bennett wrote: > Just a question: how would/does allowing the reordering of fields affect the > correctness and performance of the (de)serialization API added in Swift 4? The design of that is definitely proof against changes to the

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Robert Bennett via swift-evolution
Just a question: how would/does allowing the reordering of fields affect the correctness and performance of the (de)serialization API added in Swift 4? > On Jul 9, 2017, at 6:21 PM, Jens Persson via swift-evolution > wrote: > > Thanks for that clarification John

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Jens Persson via swift-evolution
Thanks for that clarification John McCall. My code is using a lot of generic structs (in which memory layout is important) though, an example would be: struct Vector4 : Vector { typealias Index = VectorIndex4 typealias Element = E var e0, e1, e2, e3: Element … } And I guess I'm out

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread John McCall via swift-evolution
> On Jul 9, 2017, at 6:14 PM, Jens Persson wrote: > > Thanks for that clarification John McCall. > My code is using a lot of generic structs (in which memory layout is > important) though, an example would be: > struct Vector4 : Vector { > typealias Index = VectorIndex4

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread John McCall via swift-evolution
> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution > wrote: > > Sorry for making so much off topic noise in this thread, but I made a mistake > regarding the Metal tutorial: > Looking more carefully I see now that they rebuild a vertedData: [Float] from

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Jens Persson via swift-evolution
Sorry for making so much off topic noise in this thread, but I made a mistake regarding the Metal tutorial: Looking more carefully I see now that they rebuild a vertedData: [Float] from their vertices: [Vertex] using the floatBuffer() method of the Vertex struct, which returns an Array with the

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Jens Persson via swift-evolution
I should perhaps add that in my image processing code, I use code like this: func withVImageBuffer(for table: Table, body: (vImage_Buffer) -> R) -> R where Data.Coordinate.Index == VectorIndex2 { let vib = vImage_Buffer( data: table.baseAddress, height:

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Jens Persson via swift-evolution
I don't think I'm misunderstanding you, but I might be, so I'll add more detail: If you look at the Metal article, you'll see that the (Swift) struct "Vertex" is used to specify the data that is sent to Metal for creating a buffer (using MTLDevice.makeBuffer). The result that the GPU will produce

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Chris Lattner via swift-evolution
> On Jul 9, 2017, at 12:23 AM, Jens Persson wrote: > > > On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution > > wrote: > Hi Susan, > > Swift does not currently specify a layout for Swift structs.

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-09 Thread Jens Persson via swift-evolution
On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hi Susan, > > Swift does not currently specify a layout for Swift structs. You > shouldn’t be using them for memory mapped i/o or writing to a file, because > their layout can change. When

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-07 Thread Susan Cheng via swift-evolution
Here are two problems being fixed. First, considering the example: struct MyRawDataStruct { var size: UInt32 var signature: UInt32 var width: UInt32 var height: UInt32 } The type UInt32 doesn't tall us the endianness of the value. Also, if we read the value of it, the

Re: [swift-evolution] [Proposal] Introduces endianness specific type

2017-07-07 Thread Max Moiseev via swift-evolution
Hi Susan, Was there any motivation for this proposal that I missed? If not then, can you please provide it in a few sentences? Otherwise it’s not clear to me what problem it is supposed to fix. Thanks, Max > On Jul 6, 2017, at 8:21 PM, Susan Cheng via swift-evolution >

[swift-evolution] [Proposal] Introduces endianness specific type

2017-07-07 Thread Susan Cheng Team Garment via swift-evolution
IMO, it has unclear representation when FixedWidthInteger working with endianness specific type. so I want to introduce the endianness specific wrapper: public struct BEInteger : FixedWidthInteger { public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get

[swift-evolution] [Proposal] Introduces endianness specific type

2017-07-06 Thread Susan Cheng via swift-evolution
IMO, it has unclear representation when FixedWidthInteger working with endianness specific type. so I want to introduce the endianness specific wrapper: public struct BEInteger : FixedWidthInteger { public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get