[swift-evolution] MemoryLayout for a value

[Xiaodi Wu]

On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki <fs.output at gmail.com>
wrote:

> > ```
> > 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 {
>

Why not?

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/c3e62b41/attachment.html>