[swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

[Dave Abrahams]

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.

+1.

> 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
noise-free.

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

Lastly, any other design is more verbose, requiring ".self" on the
passed metatype.

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

Definitely not.

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

-- 
Dave