[swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

[Dave Abrahams]

on Sun May 01 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> It's a bad habit of mine, I guess, to err on the side of suggesting conservative
> changes on the assumption that it'll be maximally acceptable. If there's
> appetite for a more serious renaming, and as you say these are considered
> relatively rarely used, then it's a world of possibility!
>
> We could do as Shawn suggested and follow precedent in some other languages by
> moving these functions out of the global scope. Perhaps these will meet with
> some satisfaction:
>
> ```
> Memory.footprint(of:)
> Memory.alignment(of:)
> Memory.spacing(of:)
> ```

I'd rather have 

MemoryLayout<T>.size
MemoryLayout<T>.alignment
MemoryLayout<T>.spacing

-Dave

> On Sun, May 1, 2016 at 21:41 Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>     on Sun May 01 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
>
>     > On Sun, May 1, 2016 at 7:00 PM, Dave Abrahams via swift-evolution
>     > <swift-evolution at swift.org> wrote:
>     >
>     > on Thu Apr 28 2016, Xiaodi Wu
>     > <swift-evolution at swift.org> wrote:
>     >
>     > > We all know and love sizeof(), but given that it's different from its C
>     > > counterpart anyway, shouldn't these conform to Swift naming guidelines?
>     In
>     > other
>     > > words, after SE-0006, shouldn't these names be as follows?
>     > >
>     > > ```
>     > > size<T>(of: T.Type)
>     > > size<T>(ofValue: T)
>     > > stride<T>(of: T.Type)
>     > > stride<T>(ofValue: T)
>     > > align<T>(of: T.Type)
>     > > align<T>(ofValue: T)
>     > > ```
>     > >
>     > > There are obvious issues with two different things named `stride`, but
>     IMO
>     > > that's best addressed by renaming one of them; the real problem is that
>     > the word
>     > > stride is used in two different ways already. Thoughts?
>     >
>     > These functions correspond to C and LLVM primitives and we consciously
>     > kept those names because they are terms of art.
>     >
>     > I recognize that this was the intention behind preserving the names as-is.
>     The
>     > thought process behind proposing a renaming was as follows:
>     >
>     > * The Swift counterpart to C `sizeof()` is `strideof(_:)`. Thus, although
>     the
>     > *names* are treated as terms of art, not all of them are used to mean the
>     art
>     > for which they are terms (if you will).
>
>     The specific meaning of sizeof in Swift comes from either LLVM or from
>     SIL, IIRC. It predates me, but it's supposed to correspond to what the
>     IRGen level of the compiler calls “sizeof.”
>
>     > To reinforce the separation between C primitives and these Swift
>     > functions, C `offsetof()` has no Swift counterpart.
>
>     Yes, that's part of the reason I'd very much like to choose more
>     descriptive names if we are going to move away from the current
>     spellings. moving the parenthesis is a pretty weak cue that this thing
>     might be slightly different.
>
>     > * A survey of other languages suggests that, as terms of art, these names
>     are
>     > not always treated as a single word but as a phrase, by which I mean that
>     the
>     > preposition "of" can be subject to language-specific naming conventions.
>     For
>     > example, in Rust you have `size_of()`, `size_of_val()`, etc.; in the .NET
>     > Framework, you have the `Marshal.SizeOf()` method; and even in LLVM you
>     > apparently have (and this is based just on googling--my level of
>     familiarity
>     > with LLVM is low to nonexistent) struct `AlignOf<T>`.
>     >
>     > I don't know that
>     >
>     > size(of: T.self)
>     >
>     > is particularly descriptive usage, and if we were going to change them
>     > so they didn't look like sizeof, strideof, alignof I'd want to make them
>     > far more descriptive. E.g.
>     >
>     > memoryFootprint(Int.self)
>     >
>     > or
>     >
>     > bytesRequiredForStorage(Int.self)
>     > standardByteAlignment(Int.self)
>     > bytesBetweenArrayElements(Int.self)
>     >
>     > etc.
>     >
>     > To my mind, `size(of:)` is not moving away from using a term of art but
>     rather
>     > following existing precedent in conforming use of the preposition to
>     > language-specific conventions.
>
>     The same argument could be made for “mapped” and “reduced.”
>
>     > Like you, I would be hesitant to suggest moving away from these terms
>     > of art altogether.
>
>     You misunderstand me. I'm not hesitant about that at all. What I
>     dislike is the idea of being close-to-but-not-quite-the-same as the
>     source terms to which they correspond. The original terms are not
>     great, and these facilities are seldom used. They can afford to be
>     longer and more descriptive.
>
>     > I do think, though, that moving the preposition has the bonus of
>     > visually suggesting however subtly that `size(of:) ` might have a
>     > Swift-specific twist that makes it not a drop-in equivalent for C
>     > `sizeof()`.
>
>     I don't think subtlety is a virtue in this case.
>
>     --
>     Dave
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave