[swift-evolution] [Review] SE-0136: Memory Layout of Values

[Will Field-Thompson]

** What is your evaluation of the proposal?*
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.
The syntax is the most straightforward design I think of, so this is a +1
from me.

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.

** Is the problem being addressed significant enough to warrant a change to
Swift?*
I would *not* 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).

** Does this proposal fit well with the feel and direction of Swift?*
Yes.

** If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?*
Long-time fan of `sizeofValue`.

** How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*
A quick reading of the proposal and the review thread.

Best,

Will

On Tue, Aug 9, 2016 at 10:36 AM Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> On Tue, Aug 9, 2016 at 3:32 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > On Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >       * What is your evaluation of the proposal?
>>
>> I don't think that making this public is so urgent that we need to
>> approve it after the deadline.
>>
>> 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:
>>
>>         MemoryLayout<pointer.Pointee>.size
>>         MemoryLayout<array.Element>.stride
>>         MemoryLayout<someComplexLazyFilteredArray.Self>.size
>>
>> (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.)
>>
>> So that means this is:
>>
>> 1. A specialized feature,
>> 2. Probably used far more by the standard library than anything else,
>> 3. Which is a mere convenience,
>> 4. Can be trivially added by any user who wants it,
>> 5. And may no longer be necessary by the time generics are where we want
>> them to be.
>>
>> So why the rush? Why not keep the standard library's implementation
>> private to the standard library?
>>
>
> 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.
>
> 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.
>
> 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.
>
> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160809/094dc8b3/attachment.html>