[Review] SE-0136: Memory Layout of Values

Hello Swift community,

The review of "SE-0136: Memory Layout of Values" begins now and runs
through August 9th. Apologies for the short review period, but we are
running up against the Swift 3 deadline. The proposal is available here:

  swift-evolution/0136-memory-layout-of-values.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution
mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of
Swift. When writing your review, here are some questions you might
want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a
          change to Swift?
  * Does this proposal fit well with the feel and direction of
          Swift?
  * If you have used other languages or libraries with a similar
          feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a
          quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

Dave Abrahams
Review Manager

  * 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”.

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  * What is your evaluation of the proposal?

+1

  * 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?
  * How much effort did you put into your review? A glance, a
          quick reading, or an in-depth study?

A quick reading of the proposal and review thread to date.

-Kevin Ballard

···

On Sun, Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution wrote:

  * What is your evaluation of the proposal?

+0.5

  * Is the problem being addressed significant enough to warrant a
         change to Swift?

Almost

  * Does this proposal fit well with the feel and direction of
         Swift?

I am not totally happy with the whole MemoryLayout solution, but having standard API to obtain memory layout of values is better than not having it.

  * How much effort did you put into your review?

quick reading

I don't think that making this public is so urgent that we need to approve it after the deadline.

I suspect that a syntax for talking about the types associated with a variable will emerge from the enhanced existential proposals. If one does, we will be able to use it here:

  MemoryLayout<pointer.Pointee>.size
  MemoryLayout<array.Element>.stride
  MemoryLayout<someComplexLazyFilteredArray.Self>.size

(You could use `size(ofValue:)` and friends with more complicated expressions, but that would mean evaluating them for no good reason. I'd say using `size(ofValue:)` with anything other than a simple variable is probably a smell.)

So that means this is:

1. A specialized feature,
2. Probably used far more by the standard library than anything else,
3. Which is a mere convenience,
4. Can be trivially added by any user who wants it,
5. And may no longer be necessary by the time generics are where we want them to be.

So why the rush? Why not keep the standard library's implementation private to the standard library?

···

On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

  * What is your evaluation of the proposal?

--
Brent Royal-Gordon
Architechies

I'm fine with the proposal if it suits the core team / stdlib requirements for reasons previously stated.

Some questions: Under SE-0136, the calls would be `MemoryLayout<Int>.size` and `MemoryLayout.size(ofValue: 2)`, with T inferred from the `size(ofValue:)` argument type.

* Will it benefit the compiler to use autoclosure as previously discussed to avoid evaluation? Or is that unnecessary?
* With some list members requesting a single namespaced set of functions that align with the original version of 101, is there any advantage to adopting the following non-generic enum design?

public enum MemoryLayout {
    public static func size<T>(ofValue _: T) -> Int { ... }
    public static func stride<T>(ofValue _: T) -> Int { ... }
    public static func alignment<T>(ofValue _: T) -> Int { ... }
    public static func size<T>(of _: T.Type) -> Int { ... }
    public static func stride<T>(of _: T.Type) -> Int { ... }
    public static func alignment<T>(of _: T.Type) -> Int { ... }
}

* If not, should the remaining 3 functions be added to `MemoryLayout<T>` as a courtesy for those who feel it reads better?

-- E

···

On Aug 7, 2016, at 12:18 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0136: Memory Layout of Values" begins now and runs
through August 9th. Apologies for the short review period, but we are
running up against the Swift 3 deadline. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0136-memory-layout-of-values.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution
mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of
Swift. When writing your review, here are some questions you might
want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a
         change to Swift?
  * Does this proposal fit well with the feel and direction of
         Swift?
  * If you have used other languages or libraries with a similar
         feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a
         quick reading, or an in-depth study?

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  * 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.

···

on Sun Aug 07 2016, Karl <razielim-AT-gmail.com> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

The use case is this: you have a value, but you don't have its type at
compile-time, and you want memory layout information. For example, it
might be the result of

     let x = (0..<20).reversed().lazy.map { $0 * 3 }

(which has a horrible type you wouldn't want to spell out) and you want
to know the size of the instance x.

     MemoryLayout.size(ofValue: x)

will work here. Getting a type to pass in the angle brackets requires
jumping through lots of hoops and is easy to get wrong.

···

on Sun Aug 07 2016, Brandon Knope <bknope-AT-me.com> wrote:

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.

--
-Dave

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.

···

On Sun, Aug 7, 2016 at 9:31 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote:

Sent from my iPad

> On Aug 7, 2016, at 10:18 PM, Dave Abrahams via swift-evolution < > swift-evolution@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> -Dave
> _______________________________________________
> 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

+1 from me. I followed the discussion and read the proposal. It seems like
a fairly straightforward solution to the problem.

···

On Sun, Aug 7, 2016 at 9:03 PM, Karl via swift-evolution < swift-evolution@swift.org> 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”.

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@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

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

···

Sent from my iPad

On Aug 7, 2016, at 10:18 PM, Dave Abrahams via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@gmail.com> wrote:

On Sun, Aug 7, 2016 at 9:31 PM, Brandon Knope via swift-evolution <swift-evolution@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@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> -Dave
> _______________________________________________
> 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

I should add, it serves to clarify intention to the reader as well. Take,
for instance:

let array = [0, 1, 2]
let x = strideofValue(array[0]) // using the Swift 2 name
// stdlib testing code actually does something like this at one point

A reader can see on inspection that x is the correct increment for
advancing through the raw bytes of the array. If I edit the first line to
`let array = [0, 1.5, 2]`, x is still appropriate for that use on 32-bit
systems. And if I tried to use x to advance through the bytes of a
different array2, it would definitely prompt a reader to take a second look
at the code.

Of course, it is trivial to rewrite the second line as `let x =
MemoryLayout<Int>.stride` and to adjust if the type of array changes. But
combine that with a scenario such as Dave's, and it can be much more
difficult for a reader to discern whether the code is asking for the memory
layout properties of the right type.

···

On Sun, Aug 7, 2016 at 10:21 PM Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Aug 07 2016, Brandon Knope <bknope-AT-me.com> wrote:

> 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.

The use case is this: you have a value, but you don't have its type at
compile-time, and you want memory layout information. For example, it
might be the result of

     let x = (0..<20).reversed().lazy.map { $0 * 3 }

(which has a horrible type you wouldn't want to spell out) and you want
to know the size of the instance x.

     MemoryLayout.size(ofValue: x)

will work here. Getting a type to pass in the angle brackets requires
jumping through lots of hoops and is easy to get wrong.

--
-Dave

I feel so incredibly silly :facepalm:

Thank you...it's obvious now

Brandon

···

Sent from my iPad

On Aug 7, 2016, at 11:21 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Aug 07 2016, Brandon Knope <bknope-AT-me.com> wrote:

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.

The use case is this: you have a value, but you don't have its type at
compile-time, and you want memory layout information. For example, it
might be the result of

    let x = (0..<20).reversed().lazy.map { $0 * 3 }

(which has a horrible type you wouldn't want to spell out) and you want
to know the size of the instance x.

    MemoryLayout.size(ofValue: x)

will work here. Getting a type to pass in the angle brackets requires
jumping through lots of hoops and is easy to get wrong.

--
-Dave

Honestly, I prefer old 'size(of:)' and 'size(ofValue:)' to new
'MemoryLayout'.
I actually voted against that proposal. Without it, we wouldn't have
problems we have now.
But it's obvious now that it's just a formality to complete the transition.
Sadly.

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, if 'T' is a supertype, then 'size(ofValue:T)' returns size of
specific type of its parameter:
let anything: Any = UInt16(0)
size(ofValue: anything) //=> 2
Believe it or not, some people need that functionality :P

There's plenty offered by the standard library that _app_ developers might
not touch very frequently, but since, for example, we're encouraging people
to start their own matrix algebra library, types like ManagedBuffer
and--yes--MemoryLayout are probably just as important for those use cases
as it is for the standard library itself.

To the extent that, as Dave might put it, usage in the standard library
helps us to "discover" the right API to expose, the experience of
implementing SE-0101 has been informative, I think. IMO, the migration
story for a project that *does* need an *ofValue facility could be much,
much better than having the user reimplement a privately available method,
and it is possible to deliver an improvement on the Swift 3 timeline.

Of course, more powerful generics are going to be a huge boon for Swift 4,
but surely it'd be wiser not to omit Swift 3 facilities on hypothesized
directions for the next version.

···

On Tue, Aug 9, 2016 at 3:32 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>
> * What is your evaluation of the proposal?

I don't think that making this public is so urgent that we need to approve
it after the deadline.

I suspect that a syntax for talking about the types associated with a
variable will emerge from the enhanced existential proposals. If one does,
we will be able to use it here:

        MemoryLayout<pointer.Pointee>.size
        MemoryLayout<array.Element>.stride
        MemoryLayout<someComplexLazyFilteredArray.Self>.size

(You could use `size(ofValue:)` and friends with more complicated
expressions, but that would mean evaluating them for no good reason. I'd
say using `size(ofValue:)` with anything other than a simple variable is
probably a smell.)

So that means this is:

1. A specialized feature,
2. Probably used far more by the standard library than anything else,
3. Which is a mere convenience,
4. Can be trivially added by any user who wants it,
5. And may no longer be necessary by the time generics are where we want
them to be.

So why the rush? Why not keep the standard library's implementation
private to the standard library?

--

Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Is there a way to get the size of the stored properties? I had a look but couldn’t find one.

···

On 8 Aug 2016, at 04:18, Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Aug 07 2016, Karl <razielim-AT-gmail.com <http://razielim-at-gmail.com/&gt;&gt; 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.

In the alternatives section of the proposal, I touched on the issue of
@autoclosure. I continue to think that it's (to borrow Will's phrasing
above) 'too clever', in that use of the attribute for the express purpose
of discarding the closure is unprecedented in the standard library, and in
that it may violate user expectations that `a(b(c))` generally entails
invoking both b(_:) and a(_:).

IMO, the core team's original rationale for having a generic enum rather
than generic functions is sound, and I think I've come around to sharing
Dave's opinion that ofValue and non-ofValue facilities should distinguish
themselves from each other as much as possible to avoid confusion about
their behavior when the argument is T.self vs. T.Type.

In the alternatives section, I've also included a sketch of an argument for
why having duplicative API for non-ofValue facilities might be less than
preferable.

···

On Tue, Aug 9, 2016 at 12:57 Erica Sadun <erica@ericasadun.com> wrote:

I'm fine with the proposal if it suits the core team / stdlib requirements
for reasons previously stated.

Some questions: Under SE-0136, the calls would be `MemoryLayout<*Int*>.size`
and `MemoryLayout.size(ofValue: *2*)`, with T inferred from the
`size(ofValue:)` argument type.

* Will it benefit the compiler to use autoclosure as previously discussed
to avoid evaluation? Or is that unnecessary?
* With some list members requesting a single namespaced set of functions
that align with the original version of 101, is there any advantage to
adopting the following non-generic enum design?

public enum MemoryLayout {
    public static func size<T>(ofValue _: T) -> Int { ... }
    public static func stride<T>(ofValue _: T) -> Int { ... }
    public static func alignment<T>(ofValue _: T) -> Int { ... }
    public static func size<T>(of _: T.Type) -> Int { ... }
    public static func stride<T>(of _: T.Type) -> Int { ... }
    public static func alignment<T>(of _: T.Type) -> Int { ... }
}

* If not, should the remaining 3 functions be added to `MemoryLayout<T>`
as a courtesy for those who feel it reads better?

-- E

On Aug 7, 2016, at 12:18 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0136: Memory Layout of Values" begins now and runs
through August 9th. Apologies for the short review period, but we are
running up against the Swift 3 deadline. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0136-memory-layout-of-values.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution
mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of
Swift. When writing your review, here are some questions you might
want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a
         change to Swift?
* Does this proposal fit well with the feel and direction of
         Swift?
* If you have used other languages or libraries with a similar
         feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a
         quick reading, or an in-depth study?

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Honestly, I prefer old 'size(of:)' and 'size(ofValue:)' to new
'MemoryLayout'.
I actually voted against that proposal. Without it, we wouldn't have
problems we have now.

We'd have different problems:

The “problems we have now” come from over-eager removal of
functionality; they have nothing to do with whether the syntax uses free
functions or static methods/properties.

But it's obvious now that it's just a formality to complete the
transition. Sadly.

I'm very sorry that you're disappointed in the result, but there *was* a
review; your preferences might have had an impact, had they been aired
there.

···

on Mon Aug 08 2016, Anton Zhilin <antonyzhilin-AT-gmail.com> wrote:

--
-Dave

Just for the record: I like MemoryLayout.

I just had a mental lapse or something. Hopefully it is just me and not others when they first see the API :joy:

Brandon

···

On Aug 8, 2016, at 1:16 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Aug 08 2016, Anton Zhilin <antonyzhilin-AT-gmail.com> wrote:

Honestly, I prefer old 'size(of:)' and 'size(ofValue:)' to new
'MemoryLayout'.
I actually voted against that proposal. Without it, we wouldn't have
problems we have now.

We'd have different problems:
https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md#motivation

The “problems we have now” come from over-eager removal of
functionality; they have nothing to do with whether the syntax uses free
functions or static methods/properties.

But it's obvious now that it's just a formality to complete the
transition. Sadly.

I'm very sorry that you're disappointed in the result, but there *was* a
review; your preferences might have had an impact, had they been aired
there.

--
-Dave