[swift-evolution] MemoryLayout for a value

[Xiaodi Wu]

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

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

As I mentioned above, it's not only possible but already used in the
standard library. For instance, `first` and `first(where:)` for Collection
types.


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