[swift-evolution] MemoryLayout for a value

Dave Abrahams dabrahams at apple.com
Thu Aug 4 13:29:30 CDT 2016

on Thu Aug 04 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> On Wed, Aug 3, 2016 at 11:32 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> on Wed Aug 03 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>> > Agreed, but I do think "memory layout of type of my value, size" is a
>> > mouthful compared to "size of value".
>> It is, but it would avoid confusion.
>> > Moreover, something doesn't sit right with me that MemoryLayout<T> and
>> > MemoryLayout.of(T.self) would be one and the same thing.
>> As far as I'm concerned, that's a feature, not a bug.  Unless you can
>> describe why it should be different, “it doesn't sit right” is not a
>> helpful argument.
> Originally, I'd actually half-way typed out a fuller argument, then deleted
> it, assuming most would find it to be uninteresting due to obviousness.
> Let's see:
> Unless I'm mistaken, every place where one might write `MemoryLayout<T>`
> can be replaced with `MemoryLayout.of(T.self)`. 

In my proposal, yes.

> (Yes, I understand that there are places where substituting in the
> other direction would be unsatisfactory, hence this follow-up thread.)
> However, I understand it to be a bug, not a feature, to have two
> different ways of spelling the same thing, because it necessarily
> brings confusion as to why there must be two of them, and I therefore
> consider this proposed design to be suboptimal.  You titled this
> thread "MemoryLayout for a value": I agree that that's what we
> need. It ought to be possible to provide facilities for exactly that
> *without* also providing an entirely duplicative way of spelling
> MemoryLayout for a type.

Fair enough.

>> > 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.
>> > }
>> > ```
>> That introduces even more potential for confusion than adding forwarding
>> vars to instances does.  Now you're talking about “overloading” a static
>> property with a static method having the same base name.
> IMO, here's where it's a feature, not a bug. I propose `size(ofValue:)` and
> `size` because they *are* related, just like how `first(where:)` and
> `first` are related for a Collection. 

GOod point.

> Moreover, the whole thing reads exactly as it should (and, not by
> accident, nearly identically to this thread's subject line): "memory
> layout size of value x". What is the source of confusion that you
> think would arise from this pseudo-overloading, and why are you
> emphasizing the fact that both would be static properties/methods (is
> it less confusing when it's not static)?

It's less confusing when only one of them is static and the other isn't.

But you've made some excellent points here.  Mulling...


More information about the swift-evolution mailing list