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
