[swift-evolution] MemoryLayout for a value

[Dave Abrahams]

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

-- 
-Dave