[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue
David Sweeris
davesweeris at mac.com
Fri Jun 3 06:32:30 CDT 2016
On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> This might be silly, but what if there were a struct with all of the relevant fields (not sure what the best name would be):
>
> struct MemoryLayout {
> let size: Int
> let alignment: Int
> let stride: Int
> // etc
> }
>
> Then you’d only maybe need two functions:
>
> memoryLayout(of:) and memoryLayout(ofType:)
>
> Or perhaps just a single property on all types named “memoryLayout” (or whatever) that returns the MemoryLayout struct:
>
> Int.memory.size
> type(of: 42).memoryLayout.size
> // etc
>
> Or just a single property on UnsafePointer if we went that route..
>
> It seems like this sort of approach would keep namespace pollution down, at least?
I was about to suggest the something very much like that.
In addition to reducing namespace "pollution", I like that it kinda moves implementation and target-level details into their own little "type terrarium"... I might suggest renaming "MemoryLayout" to something like "ImplementationDetails". The latter seems more to-the-point, but, aside from endianness, I'm not sure if any such details wouldn't fall under the umbrella of "memory layout" anyway.
Hmm… If all the details of a type’s memory layout can be represented in this “MemoryLayout" type, could we use it to manually construct a type "in-code" instead of going through the compiler? I’m not sure it works "that way”… Nor am I sure what the point would be, but it might be handy if you have clever idea that the compiler can’t understand.
I clearly shouldn’t be up this early.
- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160603/43a8b5c4/attachment.html>
More information about the swift-evolution
mailing list