<div dir="ltr">On Wed, Aug 3, 2016 at 11:32 PM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
on Wed Aug 03 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
</span><span class="">> Agreed, but I do think "memory layout of type of my value, size" is a<br>
> mouthful compared to "size of value".<br>
<br>
</span>It is, but it would avoid confusion.<br>
<span class=""><br>
> Moreover, something doesn't sit right with me that MemoryLayout<T> and<br>
> MemoryLayout.of(T.self) would be one and the same thing.<br>
<br>
</span>As far as I'm concerned, that's a feature, not a bug. Unless you can<br>
describe why it should be different, “it doesn't sit right” is not a<br>
helpful argument.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Could I suggest an alternative? It's conservative in that it mimics the<br>
> relationships we had before the proposal was implemented and also maintains<br>
> the simplicity of the caseless enum:<br>
><br>
> ```<br>
> extension MemoryLayout {<br>
> static func size(ofValue _: T) -> Int { return MemoryLayout.size }<br>
> // etc.<br>
> }<br>
> ```<br>
<br>
</span>That introduces even more potential for confusion than adding forwarding<br>
vars to instances does. Now you're talking about “overloading” a static<br>
property with a static method having the same base name.<br></blockquote><div><br></div><div>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)?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
-Dave<br>
</font></span></blockquote></div><br></div></div>