[swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

[Shawn Erickson]

Strong +1 for me as well, can't summarize it better then Gwynne's email

On Tue, Jul 12, 2016 at 8:48 PM Gwynne Raskind via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Jul 12, 2016, at 18:53, Chris Lattner <clattner at apple.com> wrote:
> >       * What is your evaluation of the proposal?
>
> Very strong +1; cleaning up the global namespace, addressing confusion
> with usage of these functions, and promoting the concept of the low-level
> attributes of a type being related to that type (rather than being
> arbitrarily global truths), are all significant wins for readability,
> discoverability, and conceptual clarity.
>
> >       * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> Definitively. The sizeof() family of functions are neither commonly enough
> used nor fundamental enough to idiomatic Swift to belong in the global
> namespace, and having them there adds potentially dangerous confusion for
> users coming from C, C++, and Objective-C. In particular, "sizeof(T)"
> almost definitely doesn’t mean what a newcomer to Swift expects, but when
> encountering "MemoryLayout<T>.size" one is considerably more likely to have
> at least noticed the documentation of what it means and the fact that
> ".stride" exists.
>
> >       * Does this proposal fit well with the feel and direction of Swift?
>
> Very much so. To me, the syntax proposed here is simpler, clearer, and
> much more in keeping with OO design.
>
> >       * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> The closest equivalent I can think of comes from C++, per
> std::numeric_limits<T>, std::pointer_traits<T>, std::allocator_traits<T>,
> etc. While C++ is being typically verbose in its syntax, it successfully
> represents the type information in object-oriented and unambiguous fashion,
> and the sheer verbosity aside, I’ve always liked this representation. This
> proposal is substantially similar in form and at a quick glance at my own
> Swift code, it adds similar clarity to the intent the code expresses.
>
> >       * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> A quick reading.
>
> -- Gwynne Raskind
> More magic than a mere signature can contain
>
> _______________________________________________
> 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/20160713/7532eec0/attachment-0001.html>