Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines


(Xiaodi Wu) #1

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?


(Joe Groff) #2

Seems reasonable to me.

-Joe

···

On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution <swift-evolution@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?


(Dave Abrahams) #3

These functions correspond to C and LLVM primitives and we consciously
kept those names because they are terms of art. 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.

···

on Thu Apr 28 2016, Xiaodi Wu <swift-evolution@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?

--
Dave


(Josh Parmenter) #4

I think this is a nice suggestion as well.
Best,
Josh

···

On Apr 28, 2016, at 1:52 PM, Joe Groff via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@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?

Seems reasonable to me.

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 7777
C 206 437 1551
F 248 616 1980
www.vectorform.com<http://www.vectorform.com/>

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA 98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD


(Xiaodi Wu) #5

> 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). To reinforce the separation
between C primitives and these Swift functions, C `offsetof()` has no Swift
counterpart.

* 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. Like you, I would be hesitant to suggest
moving away from these terms of art altogether. 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()`.

···

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #6

Well, glad that it's uncontroversial. Here's a draft of a short proposal
then. Comments welcome:

Rename sizeof(_:slight_smile: and related functions to follow API naming guidelines

   - Proposal: SE-NNNN
   <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
   - Author(s): Xiaodi Wu <https://github.com/xwu>
   - Status: Awaiting review
   <https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#rationale>
   - Review manager: TBD

<https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#introduction>
Introduction

With SE-0006
<https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md>,
Standard Library APIs have been renamed to follow a set of naming
guidelines. However, sizeof(_:slight_smile: and related functions do not follow these
guidelines.

Since sizeof(_:slight_smile: behaves differently in any case from sizeof() in other
C-family languages, it makes sense to conform these functions to Swift
naming guidelines.

Swift-evolution thread: [link goes here]
<https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#proposed-solution>Proposed
solution

The proposed solution is to rename sizeof(_:slight_smile: and related functions as
follows:

func size<T>(of: T.Type) // currently: sizeof<T>(_: T.Type)func
size<T>(ofValue: T) // currently: sizeofValue<T>(_: T)func
stride<T>(of: T.Type) // currently: strideof<T>(_: T.Type)func
stride<T>(ofValue: T) // currently: strideofValue<T>(_: T)func
align<T>(of: T.Type) // currently: alignof<T>(_: T.Type)func
align<T>(ofValue: T) // currently: alignofValue<T>(_: T)

<https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#detailed-design>Detailed
design

With the renaming proposed above, stride(of:) will appear to be related to
stride(from:to:by:). This conflict arises from a pre-existing issue;
namely, the term "stride" is used to mean two different things. Although
moving the preposition only highlights the issue, one possible resolution
is to rename strideof(_:slight_smile: to strideSize(of:) and strideofValue(_:slight_smile: to
strideSize(ofValue:).
<https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#impact-on-existing-code>Impact
on existing code

The proposed changes are as source-breaking for current code as the set of
changes implemented for SE-0006. During implementation, previous names can
be annotated as unavailable symbols to allow the proper Fix-Its to be
emitted by the compiler.
<https://github.com/xwu/swift-evolution/blob/master/proposals/NNNN-rename-sizeof.md#alternatives-considered>Alternatives
considered
The alternative is to maintain current function names.

···

On Thu, Apr 28, 2016 at 3:55 PM, Josh Parmenter via swift-evolution < swift-evolution@swift.org> wrote:

I think this is a nice suggestion as well.
Best,
Josh

On Apr 28, 2016, at 1:52 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org<mailto:swift-evolution@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?

Seems reasonable to me.


(Dave Abrahams) #7

    > 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


(Xiaodi Wu) #8

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:)
···

On Sun, May 1, 2016 at 21:41 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

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:
>
> > 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #9

LLVM doesn't call anything "sizeof". These names were lifted straight from C.

-Joe

···

On May 1, 2016, at 7:40 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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.”


(Brent Royal-Gordon) #10

With the renaming proposed above, stride(of:) will appear to be related to stride(from:to:by:). This conflict arises from a pre-existing issue; namely, the term "stride" is used to mean two different things. Although moving the preposition only highlights the issue, one possible resolution is to rename strideof(_:slight_smile: to strideSize(of:) and strideofValue(_:slight_smile: tostrideSize(ofValue:).

I wonder if it might make sense to rename all of these, then?

  instanceSize(of:)
  instanceSize(ofValue:)
  alignmentSize(of:)
  alignmentSize(ofValue:)
  strideSize(of:)
  strideSize(ofValue:)

···

--
Brent Royal-Gordon
Architechies


(Dave Abrahams) #11

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 01 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

On Sun, May 1, 2016 at 21:41 Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote:

    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:
    >
    > > 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@swift.org
    https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave


(Xiaodi Wu) #12

That is an alternative, definitely. I'll add that in. alignof isn't really
a size, though, so there's some bikeshedding to be done if going down that
route. Personally, I'm a fan of minimalist changes and I'm not enamored
with strideSize(of:) in the first place. There's work afoot to make changes
to striding, so stride(from:to:by:) may not necessarily be long for this
world in any case.

···

On Sun, May 1, 2016 at 4:54 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

> With the renaming proposed above, stride(of:) will appear to be related
to stride(from:to:by:). This conflict arises from a pre-existing issue;
namely, the term "stride" is used to mean two different things. Although
moving the preposition only highlights the issue, one possible resolution
is to rename strideof(_:slight_smile: to strideSize(of:) and strideofValue(_:slight_smile:
tostrideSize(ofValue:).

I wonder if it might make sense to rename all of these, then?

        instanceSize(of:)
        instanceSize(ofValue:)
        alignmentSize(of:)
        alignmentSize(ofValue:)
        strideSize(of:)
        strideSize(ofValue:)


(Shawn Erickson) #13

I personally kinda want to see these namespaced instead of global
functions. That could possibly allow clarity in naming.

-Shawn

···

On Sun, May 1, 2016 at 2:55 AM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> With the renaming proposed above, stride(of:) will appear to be related
to stride(from:to:by:). This conflict arises from a pre-existing issue;
namely, the term "stride" is used to mean two different things. Although
moving the preposition only highlights the issue, one possible resolution
is to rename strideof(_:slight_smile: to strideSize(of:) and strideofValue(_:slight_smile:
tostrideSize(ofValue:).

I wonder if it might make sense to rename all of these, then?

        instanceSize(of:)
        instanceSize(ofValue:)
        alignmentSize(of:)
        alignmentSize(ofValue:)
        strideSize(of:)
        strideSize(ofValue:)

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #14

This would be a legit use for 'extension Any'. IMO it'd be even better as just T.size, T.alignment, T.spacing.

-Joe

···

On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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


(Xiaodi Wu) #15

I like it, but how do you accommodate sizeofValue, etc?

···

On Mon, May 2, 2016 at 11:46 Dave Abrahams <dabrahams@apple.com> wrote:

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@swift.org> wrote:
>
> 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:
> >
> > > 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

--
Dave


(Xiaodi Wu) #16

A clash of names is inelegant, but in practice, I'm not actually sure that
there's really a lack of clarity. IMO, `stride(of: Int)` is not really
misinterpretable as anything else.

···

On Sun, May 1, 2016 at 12:08 PM, Shawn Erickson <shawnce@gmail.com> wrote:

I personally kinda want to see these namespaced instead of global
functions. That could possibly allow clarity in naming.

-Shawn

On Sun, May 1, 2016 at 2:55 AM Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:

> With the renaming proposed above, stride(of:) will appear to be related
to stride(from:to:by:). This conflict arises from a pre-existing issue;
namely, the term "stride" is used to mean two different things. Although
moving the preposition only highlights the issue, one possible resolution
is to rename strideof(_:slight_smile: to strideSize(of:) and strideofValue(_:slight_smile:
tostrideSize(ofValue:).

I wonder if it might make sense to rename all of these, then?

        instanceSize(of:)
        instanceSize(ofValue:)
        alignmentSize(of:)
        alignmentSize(ofValue:)
        strideSize(of:)
        strideSize(ofValue:)

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #17

A clash of names is inelegant, but in practice, I'm not actually sure that
there's really a lack of clarity. IMO, `stride(of: Int)` is not really
misinterpretable as anything else.

I disagree, especially since `Strideable` has an associated `Stride` type.

···

on Sun May 01 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Sun, May 1, 2016 at 12:08 PM, Shawn Erickson > <shawnce@gmail.com> wrote:

    I personally kinda want to see these namespaced instead of global functions.
    That could possibly allow clarity in naming.

    -Shawn

    On Sun, May 1, 2016 at 2:55 AM Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote:

        > With the renaming proposed above, stride(of:) will appear to be
        related to stride(from:to:by:). This conflict arises from a pre-existing
        issue; namely, the term "stride" is used to mean two different things.
        Although moving the preposition only highlights the issue, one possible
        resolution is to rename strideof(_:slight_smile: to strideSize(of:) and
        strideofValue(_:slight_smile: tostrideSize(ofValue:).

        I wonder if it might make sense to rename all of these, then?

        instanceSize(of:)
        instanceSize(ofValue:)
        alignmentSize(of:)
        alignmentSize(ofValue:)
        strideSize(of:)
        strideSize(ofValue:)

        --
        Brent Royal-Gordon
        Architechies

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org
        https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave


(Xiaodi Wu) #18

Is the naming infelicitous? Yes, no argument from me here.

But: I'd guess that Strideable, being a protocol for numeric types, comes
into the picture mostly when implementing generic numeric algorithms, and
its associated Stride type (if I remember correctly from reading code
comments) should really be Distance but for current limitations in the
language. I have no doubt that someone who knows the insides of Strideable
to that level of detail has the expertise and imagination to conjure up a
meaning for `stride(of: Int)` other than the stride size in bytes of
consecutive Ints, but I venture that it'd still take some effort and
wouldn't be an unintentional misunderstanding :stuck_out_tongue:

···

On Sun, May 1, 2016 at 7:01 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Sun May 01 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

> A clash of names is inelegant, but in practice, I'm not actually sure
that
> there's really a lack of clarity. IMO, `stride(of: Int)` is not really
> misinterpretable as anything else.

I disagree, especially since `Strideable` has an associated `Stride` type.


(Dave Abrahams) #19

I very much disagree. I don't want to see Array(1..<100).size == 24.

···

on Mon May 02 2016, Joe Groff <swift-evolution@swift.org> wrote:

On May 2, 2016, at 9:46 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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

This would be a legit use for 'extension Any'. IMO it'd be even better
as just T.size, T.alignment, T.spacing.

--
Dave


(Dave Abrahams) #20

I like it, but how do you accommodate sizeofValue, etc?

IMO you don't. I added those years ago on a whim, when whims were what
we had to guide development. I'm unconvinced they add value to Swift.

···

on Mon May 02 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Mon, May 2, 2016 at 11:46 Dave Abrahams > <dabrahams@apple.com> wrote:

    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@swift.org> wrote:
    >
    > 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:
    > >
    > > > 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@swift.org
    > https://lists.swift.org/mailman/listinfo/swift-evolution
    >

    --
    Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave