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

[Brent Royal-Gordon]

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

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)

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

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

-- 
Brent Royal-Gordon
Architechies