[swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

[Erica Sadun]

> On Jul 13, 2016, at 5:39 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Wed Jul 13 2016, Brent Royal-Gordon <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/d708fc3a/attachment.html>