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 < [email protected]> wrote: > > on Mon May 02 2016, Xiaodi Wu <[email protected]> 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 > > <[email protected]> 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 > > > <[email protected]> wrote: > > > > > > on Sun May 01 2016, Xiaodi Wu > > <[email protected]> wrote: > > > > > > > On Sun, May 1, 2016 at 7:00 PM, Dave Abrahams via swift-evolution > > > > <[email protected]> wrote: > > > > > > > > on Thu Apr 28 2016, Xiaodi Wu > > > > <[email protected]> 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 > > > [email protected] > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > -- > > Dave > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
