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

[Dave Abrahams]

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