> On Jul 13, 2016, at 5:39 PM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
> on Wed Jul 13 2016, Brent Royal-Gordon <[email protected]
> <mailto:[email protected]>> wrote:
>> I think grouping these into a type is a sensible approach, but I don't
>> like that it allows the creation of meaningless MemoryLayout
>> instances. The simplest fix would be to make `MemoryLayout` an empty
>> enum instead of an empty struct. This would convey that no
>> MemoryLayout instances do or can exist.
>
> +1.
+1 as well.
/// Accesses the memory layout of `T` through its
/// `size`, `stride`, and `alignment` properties
public enum MemoryLayout {
/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote"
/// storage. In particular, `MemoryLayout.size`, when
/// `T` is a class type, is the same regardless of how many
/// stored properties `T` has.
public static var size: Int { return _sizeof(T.self) }
/// For instances of `T` in an `Array`, returns the number of
/// bytes from the start of one instance to the start of the
/// next. This is the same as the number of bytes moved when an
/// `UnsafePointer` is incremented. `T` may have a lower minimal
/// alignment that trades runtime performance for space
/// efficiency. The result is always positive.
public static var stride: Int { return _strideof(T.self) }
/// Returns the default memory alignment of `T`.
public static var alignment: Int { return _alignof(T.self) }
}
-- E
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
