[swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct
dabrahams at apple.com
Wed Jul 13 18:39:49 CDT 2016
on Wed Jul 13 2016, Brent Royal-Gordon <swift-evolution at swift.org> wrote:
>> On Jul 12, 2016, at 4:53 PM, Chris Lattner <clattner at apple.com> wrote:
>> * What is your evaluation of the proposal?
> I think grouping these into a type is a sensible approach, but I don't
> like that it allows the creation of meaningless MemoryLayout
> instances. The simplest fix would be to make `MemoryLayout` an empty
> enum instead of an empty struct. This would convey that no
> MemoryLayout instances do or can exist.
> However, I'm also not really a fan of the way this
> reads. `MemoryLayout<Int>` is an unnatural way to access this
> functionality, quite different from how generics are typically
> used. The heavy use of type members, with instance behavior as a
> complete afterthought, is very unusual. If we are serious about use
> sites being the most important thing, we ought to be concerned about
> these use sites.
This design is specifically optimized to make use-sites clear and
The fact that using the type as a generic parameter very clearly states
that we're asking about the size of the type, and not the metatype, also
Lastly, any other design is more verbose, requiring ".self" on the
> I would prefer to see an instance-centric version of this design, with use sites along the lines of:
> MemoryLayout(of: Int.self).size
> let buffer = UnsafeRawPointer.allocate(bytes: MemoryLayout(of: Int.self).stride * count)
I don't think that objectively reads better than:
let buffer = UnsafeRawPointer.allocate(bytes: MemoryLayout<Int>.stride * count)
I can understand your preference for it as a matter of taste, but I
think the second one is just as understandable and much less
noisy... thus clearer.
> If the problem is that it would sometimes misbehave—for instance, when
> someone tries to construct a MemoryLayout instance from a `type(of:)`
> call—then we should make it behave correctly, or at least consider it
> a bug to be fixed eventually.
> (Incidentally, I notice that the ABI documentation lists the size,
> alignment, and stride as part of the type's value witness
> table. <https://github.com/apple/swift/blob/master/docs/ABI.rst#common-metadata-layout>
> Would it make sense to think of this as exposing the value witness
> table as a user-visible type?
> How might that be different from what's being proposed here?)
This is stable, documented API; the value witness table is not. :-)
>> * Is the problem being addressed significant enough to warrant a change to Swift?
> Yes. We need to lock this down.
>> * Does this proposal fit well with the feel and direction of Swift?
> See my comment above about how it reads.
>> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> Well, it *is* more coherent and less magical than the C family.
>> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> Quick reading, but I've chimed in during previous discussions (though not in this latest round—family duties have kept me from my mail client).
More information about the swift-evolution