<div dir="ltr">On Tue, Aug 9, 2016 at 3:32 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> * What is your evaluation of the proposal?<br>
<br>
</span>I don't think that making this public is so urgent that we need to approve it after the deadline.<br>
<br>
I suspect that a syntax for talking about the types associated with a variable will emerge from the enhanced existential proposals. If one does, we will be able to use it here:<br>
<br>
MemoryLayout<pointer.Pointee>.<wbr>size<br>
MemoryLayout<array.Element>.<wbr>stride<br>
MemoryLayout<<wbr>someComplexLazyFilteredArray.<wbr>Self>.size<br>
<br>
(You could use `size(ofValue:)` and friends with more complicated expressions, but that would mean evaluating them for no good reason. I'd say using `size(ofValue:)` with anything other than a simple variable is probably a smell.)<br>
<br>
So that means this is:<br>
<br>
1. A specialized feature,<br>
2. Probably used far more by the standard library than anything else,<br>
3. Which is a mere convenience,<br>
4. Can be trivially added by any user who wants it,<br>
5. And may no longer be necessary by the time generics are where we want them to be.<br>
<br>
So why the rush? Why not keep the standard library's implementation private to the standard library?<br></blockquote><div><br></div><div>There's plenty offered by the standard library that _app_ developers might not touch very frequently, but since, for example, we're encouraging people to start their own matrix algebra library, types like ManagedBuffer and--yes--MemoryLayout are probably just as important for those use cases as it is for the standard library itself.</div><div><br></div><div>To the extent that, as Dave might put it, usage in the standard library helps us to "discover" the right API to expose, the experience of implementing SE-0101 has been informative, I think. IMO, the migration story for a project that *does* need an *ofValue facility could be much, much better than having the user reimplement a privately available method, and it is possible to deliver an improvement on the Swift 3 timeline.</div><div><br></div><div>Of course, more powerful generics are going to be a huge boon for Swift 4, but surely it'd be wiser not to omit Swift 3 facilities on hypothesized directions for the next version.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>