[swift-evolution] MemoryLayout for a value

[Xiaodi Wu]

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

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


>
> --
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160804/2e720477/attachment.html>