Well, I mean, it's not as though you invented them just for Swift. It's
possible to evaluate sizeof an instance in C, C++, C#, D, Python, Rust...
Removing this facility from Swift is a whole nother discussion from
renaming.
···
On Mon, May 2, 2016 at 3:11 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:
on Mon May 02 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:
> 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 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
> 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.
Is the naming infelicitous? Yes, no argument from me here.
But: I'd guess that Strideable, being a protocol for numeric types,
Not only those. UnsafePointer is strideable, for example.
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 don't *think* so.
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 :P
You're going to see a definition of Int.Stride when you look at the members.
···
on Sun May 01 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
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:
// FIXME(ABI)(compiler limitation): We'd like to name this type "Distance"
// but for <rdar://problem/17619038>
···
On Sun, May 1, 2016 at 20:51 Dave Abrahams <dabrahams@apple.com> wrote:
on Sun May 01 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
> 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.
>
> Is the naming infelicitous? Yes, no argument from me here.
>
> But: I'd guess that Strideable, being a protocol for numeric types,
Not only those. UnsafePointer is strideable, for example.
> 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 don't *think* so.
> 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 :P
You're going to see a definition of Int.Stride when you look at the
members.
I agree that the names could be more specific but I do agree that putting these methods on `Any` is a good idea.
(I am not saying that `Any` should be open to user extensions though.)
···
On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Mon May 02 2016, Joe Groff <swift-evolution@swift.org <mailto: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:
They would presumably be static members, so that wouldn't be valid. Array<Int>.size would be, though.
-Joe
···
On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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:
I agree with Dave here. Even if these got more verbose names (to avoid confusion with count), it is still unfortunate to pollute code completion for these uncommonly used "operators”. I’m coming around to agree with Dave’s view that dynamicType should be made into a global function for the same reason.
-Chris
···
On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
OK, but personally don't want it on Array either, especially not after
we get statically-sized arrays.
···
on Mon May 02 2016, Joe Groff <jgroff-AT-apple.com> wrote:
On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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:
This feedback has been very edifying. I've been playing around a little bit
in the IBM Swift Sandbox (it's what I've got handy). I think Dave's
solution is supremely elegant, but I'm not entirely comfortable proposing
elimination of `sizeofValue(_:)` and friends; I've just got no real-world
information about how useful they are or not, and the onus is on the person
proposing the change to show why the change is necessary and appropriate. I
wouldn't know where to begin.
Dave's suggestion can be bolted onto Swift 2 as follows:
struct MemoryLayout<T> {
static var alignment: Int {
return alignof(T)
}
static var size: Int {
return sizeof(T)
}
static var spacing: Int {
return strideof(T)
}
private init() { }
}
I think, though, that it becomes more confusing to include
`sizeofValue(_:)` in this syntax, because it'd be possible to write
`MemoryLayout<Base>.size(ofValue: Subclass())`, which is a can of worms.
However, we can do this:
It's not up to Dave's standards of elegance, but it seems acceptable IMO.
The preposition, incidentally, has to go because parsing rules (at least in
Swift 2) mean `size(Int)` is fine but `size(of: Int)` blows up (it has to
be `size(of: Int.self)`). Is there an issue with using overloaded methods
instead of unique labels in replacing `sizeof(_:)` and `sizeofValue(_:)`?
···
On Mon, May 2, 2016 at 4:32 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> 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.
>
> I very much disagree. I don't want to see Array(1..<100).size == 24.
I agree with Dave here. Even if these got more verbose names (to avoid
confusion with count), it is still unfortunate to pollute code completion
for these uncommonly used "operators”. I’m coming around to agree with
Dave’s view that dynamicType should be made into a global function for the
same reason.