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?
l8r
Sean
> On Jun 2, 2016, at 4:55 PM, Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> I don't disagree with the points you make. But one can argue that this is a
>> good thing. It calls attention to code that requires extra attention and
>> care. In some ways this is similar to 'UnsafeMutablePointer<T>' vs '*T'.
>> Verbosity was a deliberate choice in that case.
>
> You know...rather than introducing a new type like MemoryLayout, would it
> make sense to do this with static properties on UnsafePointer?
>
> UnsafePointer<Int>.pointeeSize
> UnsafePointer<Int>.pointeeAlignment
> UnsafePointer<Int>.pointeeSpacing
>
> If you need this information, 90% of the time you're probably using
> UnsafePointer or one of its friends, right?
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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
