> On Jul 12, 2016, at 4:53 PM, Chris Lattner <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
