> 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.
···
on Sun May 01 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:
On Sun, May 1, 2016 at 7:00 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote:
on Thu Apr 28 2016, Xiaodi Wu > <swift-evolution@swift.org> wrote:
--
Dave