[swift-evolution] MemoryLayout for a value

[rintaro ishizaki]

2016-08-05 16:20 GMT+09:00 Xiaodi Wu <xiaodi.wu at gmail.com>:

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

My bad. Sorry, never mind.
I didn't know we can have such overloads (property and func, same basename)
:O



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