[swift-evolution] MemoryLayout for a value

[rintaro ishizaki]

> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```

I don't think we can do this while we have:

  public static var size: Int {

maybe `sizeOf(value _: T) -> Int` ?


2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
swift-evolution at swift.org>:

> On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >
>> > Having seen the effects in the standard library and in other
>> > code, I'm concerned that we may have made a mistake in removing
>> > `sizeofValue` et al without providing a replacement.  In the standard
>> > library, we ended up adding an underscored API that allows
>> >
>> >  MemoryLayout._ofInstance(someExpression).size
>> >
>> > Where someExpression is an autoclosure, and thus not evaluated.  I
>> > wanted to bring up the possibility of introducing a replacement as a
>> > bufix.
>> >
>> > I propose that the way to express the above should be:
>> >
>> >  MemoryLayout.of(type(of: someExpression)).size
>> >
>> > implementable as:
>> >
>> >  extension MemoryLayout {
>> >    @_transparent
>> >    public
>> >    static func of(_: T.Type) -> MemoryLayout<T>.Type {
>> >      return MemoryLayout<T>.self
>> >    }
>> >  }
>> >
>> > I think this API would solve the concerns I had about confusability that
>> > led me to advocate dropping the ability to ask for the size of a value.
>> > The only way to use it is to pass a type and these two expressions have
>> > equivalent meaning:
>> >
>> >    MemoryLayout<Int>
>> >    MemoryLayout.of(Int.self)
>> >
>> > It also has the benefit of isolating the autoclosure magic to type(of:).
>> >
>> > ,----[ Aside ]
>> > | A slightly cleaner use site is possible with a larger API change:
>> > |
>> > |   MemoryLayout(type(of: someExpression)).size
>> > |
>> > | Which would involve changing MemoryLayout from an `enum` to
>> > | a `struct` and adding the following:
>> > |
>> > |   extension MemoryLayout {
>> > |     public init(_: T.Type) {}
>> > |
>> > |     public var size: Int { return MemoryLayout.size }
>> > |     public var stride: Int { return MemoryLayout.stride }
>> > |     public var alignment: Int { return MemoryLayout.alignment }
>> > |   }
>> > |
>> > | However I am concerned that dropping ".of" at the use site is worth
>> the
>> > | added API complexity.
>> > `----
>> >
>> > Thoughts?
>> > --
>> > -Dave
>>
>>
>> I don't think using "of" is a great burden.
>>
>
> Agreed, but I do think "memory layout of type of my value, size" is a
> mouthful compared to "size of value". Moreover, something doesn't sit right
> with me that MemoryLayout<T> and MemoryLayout.of(T.self) would be one and
> the same thing.
>
> Could I suggest an alternative? It's conservative in that it mimics the
> relationships we had before the proposal was implemented and also maintains
> the simplicity of the caseless enum:
>
> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```
>
>
>> -- E
>>
>> _______________________________________________
>> 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/20160805/55340eb9/attachment.html>