<div dir="ltr"><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><b>* What is your evaluation of the proposal?</b></span><div>This seems like obvious functionality. I know there are a couple places (especially when providing nice, Swifty interfaces for C functions) in the app I'm currently working on where I'd miss this functionality.</div><div>The syntax is the most straightforward design I think of, so this is a +1 from me.</div><div><br></div><div>I don't mind the `.of(_:)` syntax suggested in the original proposal either, but I think it's probably (especially with the `@autoclosure`) a bit too clever for its own good. That is, it would be especially difficult to discover.</div><div><b><br style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">* Is the problem being addressed significant enough to warrant a</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> change to Swift?</span></b></div><div><div><span style="line-height:1.5">I would</span><span class="inbox-inbox-Apple-converted-space" style="line-height:1.5"> </span><i style="line-height:1.5">not</i><span style="line-height:1.5"> be in favor leaving it out as Brent Royal-Gordon suggested, because I don't think it's overly specialized. This is one of those things that you don't think will crop up until it does (like in the stdlib).</span><br></div><br class="inbox-inbox-Apple-interchange-newline"><b><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">* Does this proposal fit well with the feel and direction of</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> Swift?</span></b></div><div>Yes.<br style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> </span></div><div><b><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">* If you have used other languages or libraries with a similar </span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">feature, how do you feel that this proposal compares to those?</span></b></div><div>Long-time fan of `sizeofValue`.</div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> </span></div><div><b><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">* How much effort did you put into your review? A glance, a</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"> quick reading, or an in-depth study?</span></b></div><div>A quick reading of the proposal and the review thread.</div><div><br></div><div>Best,</div><div><br></div><div>Will<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 9, 2016 at 10:36 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div dir="ltr"><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>> On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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>.size<br>
MemoryLayout<array.Element>.stride<br>
MemoryLayout<someComplexLazyFilteredArray.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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>