[swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

John McCall rjmccall at apple.com
Fri Jul 1 11:33:25 CDT 2016


> On Jul 1, 2016, at 8:57 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> on Thu Jun 30 2016, John McCall <rjmccall-AT-apple.com <http://rjmccall-at-apple.com/>> wrote:
>> 
>> >> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >> on Thu Jun 30 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/> <http://matthew-at-anandabits.com/ <http://matthew-at-anandabits.com/>>> wrote:
>> >>
>> >>> Sent from my iPad
>> >>>
>> >
>> >>>> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >>>>
>> >>>>
>> >>>>>> On Jun 30, 2016, at 5:47 PM, James Berry <jberry at rogueorbit.com <mailto:jberry at rogueorbit.com>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >>>>>> on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/>> wrote:
>> >>>>>>
>> >>>>>>>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> >>>>>>>>> I mentioned this in a comment on the gist already, but I'm really not
>> >>>>>>>>> digging the "array" in `arraySpacing`. We've already moved from top-level
>> >>>>>>>>> "stride" to "memory layout spacing," gaining plenty of clarity. I'm
>> >>>>>>>>> skeptical that the "array" adds anything more. Moreover, it muddies the
>> >>>>>>>>> waters by mentioning a specific type (Array) in a context where you're
>> >>>>>>>>> querying the memory layout properties of another type.
>> >>>>>>>>
>> >>>>>>>> OK, I agree with that.  If we have “alignment” rather than
>> >>>>>>>> “defaultAlignment,” I suppose we can have plain “spacing.”
>> >>>>>>>
>> >>>>>>> No way to last-second sell you on interval rather than spacing?
>> >>>>>>
>> >>>>>> If you can explain why it's better.
>> >>>>>>
>> >>>>>>> // Returns the least possible interval between distinct instances of
>> >>>>>>> /// `T` in memory.  The result is always positive.
>> >>>>>>
>> >>>>>> For me, “interval” doesn't go with “size” and “alignment,” which are all
>> >>>>>> about physical distances and locations.  There are all kinds of
>> >>>>>> “intervals,” e.g. time intervals.
>> >>>>>
>> >>>>> Hmm. Sounds like stride to me. stride or byteStride?
>> >>>>>
>> >>>>> James
>> >>>>
>> >>>> FAQ: "Why aren't you using the obvious phrase `stride` for something that clearly
>> >>>> returns the memory stride?"
>> >>>>
>> >>>> ANSWER: "As stride already has a well-established meaning in the standard library,
>> >>>> this proposal changes the name to spacing, providing a simple but correct name that
>> >>>> works well enough in its intended use. Measuring memory is sufficiently esoteric
>> >>>> that we prefer to reserve `stride` for a more common use case."
>> >>>
>> >>> Counter: some words have more than one well established meaning when
>> >>> used in different contexts.  'spacing' isn't too bad here (much better
>> >>> than 'arraySpacing') but sticking to the term of art 'stride' would be
>> >>> best IMO.  As James mentioned, spacing implies empty space *between*
>> >>> items whereas stride matches the meaning of this property *exactly*
>> >>> (which is why it is the term of art).
>> >>>
>> >>> If a programmer can't distinguish between a 'stride' property on
>> >>> MemoryLayout and the 'stride' function they probably have no business
>> >>> doing anything which requires use of MemoryLayout in the first place.
>> >>
>> >> I don't believe that “stride” *is* the accepted term of art for this
>> >> meaning.  I never heard of the idea of types having an intrinsic
>> >> “stride” until I arrived on the Swift project.  That usage came from
>> >> “strideof.”
>> >>
>> >> If you all swear up and down that you've been talking about “the stride
>> >> of a type” for more than 2 years, I won't fight you on this.
>> >> Otherwise... well, I still won't fight; I'm being crushed by an
>> >> avalanche of bikesheds and I can't muster the energy ;->... but I'll
>> >> forever be plagued by doubts about the name.
>> >
>> > As the person who originally picked "stride" here, I agree that I've never
>> > heard of people talking about the "stride" of a type; people talk about striding
>> > over an array, and they talk about the size of one's stride, and that size
>> > can be measured in bytes.  That's all I was thinking.
>> >
>> > However, I was just picking a name for an internal implementation concept;
>> > I did not expect it to be used in the standard library.
>> >
>> > I don't really like "spacing"; it sounds too much like a synonym for "padding",
>> > i.e. the amount of empty space between elements rather than the total amount
>> > of space for each element.  But I don't mean to re-open wounds; if people
>> > have settled on "spacing", have at it.
>> 
>> Better names are always welcome if you can come up with one.
>> 
>> FWIW, courtesy of the thesaurus, curated to eliminate clearly unsuitable words:
>> breadth, dimension, expanse, interval, period, space, span, stretch, width
>> 
>> Of these, span might be the most OK.
> 
> Another thought is "arrayElementSize", or "sizeAsArrayElement", or "sizeInArray".  Somewhat verbose, though.

Ignore me; I should stop responding to things sent to my inbox before I read the rest of the thread.  'stride' sounds good to me.

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/5468fb61/attachment.html>


More information about the swift-evolution mailing list