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

[Xiaodi Wu]

In the alternatives section of the proposal, I touched on the issue of
@autoclosure. I continue to think that it's (to borrow Will's phrasing
above) 'too clever', in that use of the attribute for the express purpose
of discarding the closure is unprecedented in the standard library, and in
that it may violate user expectations that `a(b(c))` generally entails
invoking both b(_:) and a(_:).

IMO, the core team's original rationale for having a generic enum rather
than generic functions is sound, and I think I've come around to sharing
Dave's opinion that ofValue and non-ofValue facilities should distinguish
themselves from each other as much as possible to avoid confusion about
their behavior when the argument is T.self vs. T.Type.

In the alternatives section, I've also included a sketch of an argument for
why having duplicative API for non-ofValue facilities might be less than
preferable.
On Tue, Aug 9, 2016 at 12:57 Erica Sadun <erica at ericasadun.com> wrote:

> I'm fine with the proposal if it suits the core team / stdlib requirements
> for reasons previously stated.
>
> Some questions: Under SE-0136, the calls would be `MemoryLayout<*Int*>.size`
> and `MemoryLayout.size(ofValue: *2*)`, with T inferred from the
> `size(ofValue:)` argument type.
>
> * Will it benefit the compiler to use autoclosure as previously discussed
> to avoid evaluation? Or is that unnecessary?
> * With some list members requesting a single namespaced set of functions
> that align with the original version of 101, is there any advantage to
> adopting the following non-generic enum design?
>
> public enum MemoryLayout {
>     public static func size<T>(ofValue _: T) -> Int { ... }
>     public static func stride<T>(ofValue _: T) -> Int { ... }
>     public static func alignment<T>(ofValue _: T) -> Int { ... }
>     public static func size<T>(of _: T.Type) -> Int { ... }
>     public static func stride<T>(of _: T.Type) -> Int { ... }
>     public static func alignment<T>(of _: T.Type) -> Int { ... }
> }
>
> * If not, should the remaining 3 functions be added to `MemoryLayout<T>`
> as a courtesy for those who feel it reads better?
>
> -- E
>
> On Aug 7, 2016, at 12:18 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0136: Memory Layout of Values" begins now and runs
> through August 9th. Apologies for the short review period, but we are
> running up against the Swift 3 deadline. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0136-memory-layout-of-values.md
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution
> mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
>          change to Swift?
> * Does this proposal fit well with the feel and direction of
>          Swift?
> * If you have used other languages or libraries with a similar
>          feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a
>          quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Dave Abrahams
> Review Manager
> _______________________________________________
> 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/2d05a87a/attachment.html>