[swift-evolution] MemoryLayout for a value

[Xiaodi Wu]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160803/c18ec95e/attachment.html>