[swift-evolution] [Review] SE-0136: Memory Layout of Values

[Brandon Knope]

Yes but:

extension MemoryLayout {
  @_transparent
  public static func size(ofValue _: T) -> Int {
    return MemoryLayout.size
  }
  @_transparent
  public static func stride(ofValue _: T) -> Int {
    return MemoryLayout.stride
  }
  @_transparent
  public static func alignment(ofValue _: T) -> Int {
    return MemoryLayout.alignment
Vs

public struct MemoryLayout<T> { 
     public static var size: Int { return _sizeof(T) } 
     public static var stride: Int { return _strideof(T) } 
     public static var alignment: Int { return _alignof(T) }
}

I see the obvious difference between the two in their names and signature, but what is the need for both?

It looks duplicated for the most part, so some clarification would be nice. 

Brandon 

Sent from my iPad

> On Aug 7, 2016, at 10:44 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> On Sun, Aug 7, 2016 at 9:31 PM, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
>> Can someone quickly explain what this new API does compared to what SE-101 had?
>> 
>> I'm trying hard to see what's being added here but my brain isn't working
>> 
>> Brandon
> 
> The text of SE-0101 was never updated to reflect the core team's decision, which was that MemoryLayout was to be an enum with no cases and without the suggested `of(_:)` functions. This proposal is to restore the `of(_:)` functions, but it incorporates recent discussion as to the most appropriate spelling for them.
> 
>> Sent from my iPad
>> 
>> > On Aug 7, 2016, at 10:18 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> >
>> >
>> > on Sun Aug 07 2016, Karl <razielim-AT-gmail.com> wrote:
>> >
>> >>>    * What is your evaluation of the proposal?
>> >>
>> >> +1
>> >>
>> >> Although if I was nitpicking I prefer the name “ofInstance” (as in the
>> >> stdlib private function) to “ofValue”.
>> >
>> > The problem with “ofInstance” is that a class instance will be reported
>> > to be the same size as Int.  Most people think of a class instance as
>> > the place where its stored properties live, not the reference.
>> >
>> >>
>> >> What is the standard nomenclature? Whereas I would distinguish between
>> >> “objects/instances” and “values”, I’ve started referring to all Swift
>> >> things as “objects” and “instances”, even if they are value types.
>> >>
>> >>
>> >>>    * Is the problem being addressed significant enough to warrant a
>> >>>         change to Swift?
>> >>
>> >> Yes
>> >>
>> >>>    * Does this proposal fit well with the feel and direction of
>> >>>         Swift?
>> >>
>> >> Yes
>> >>
>> >>>    * If you have used other languages or libraries with a similar
>> >>>         feature, how do you feel that this proposal compares to those?
>> >>
>> >> I think the metatype system needs revising for Swift >3.0, but given
>> >> time constraints this is the best solution
>> >>
>> >>>    * How much effort did you put into your review? A glance, a
>> >>>         quick reading, or an in-depth study?
>> >>
>> >> Followed prior discussion, read proposal
>> >>
>> >>>
>> >>> More information about the Swift evolution process is available at
>> >>>
>> >>>    https://github.com/apple/swift-evolution/blob/master/process.md
>> >>>
>> >>> Thank you,
>> >>>
>> >>> Dave Abrahams
>> >>> Review Manager
>> >>> _______________________________________________
>> >>> swift-evolution mailing list
>> >>> swift-evolution at swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > --
>> > -Dave
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160807/c3bbc2bc/attachment.html>