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

[Xiaodi Wu]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160809/89b84c9a/attachment.html>