> On Jun 30, 2016, at 10:07 PM, Dave Abrahams <[email protected]> wrote: > > > on Thu Jun 30 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: > >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams <[email protected]> wrote: >>> >>> >>> on Thu Jun 30 2016, Matthew Johnson <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 >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>>> On Jun 30, 2016, at 5:47 PM, James Berry <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote: >>>>>>> >>>>>>>>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams <[email protected]> >>>>>>>>> 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. >> >> I was just throwing in my 2 cents and planned to leave it at that. >> The primary reason I chimed in is because I didn’t find the rationale >> in the “answer” compelling. This isn’t something I feel like bike >> shedding any further over either. >> >> https://en.wikipedia.org/wiki/Stride_of_an_array >> >> Maybe stride isn’t as common as I thought it was (if it was I’m sure >> you would have heard of it before Swift) but it certainly predates >> Swift in usage. > > But that's actually a different meaning altogether. Two “arrays” of > type T can have different strides. They're talking about taking a view > onto an underlying series of contiguous Ts that (potentially) skips over > elements.
Maybe I come from an esoteric part of the universe. While I’ve never heard of stride applied to a type, in particular, the concept of stride as I know it applies to any item as laid out in memory, and seems to me to apply equally well to any “object” in the loosest form of the word. I believe my first experience with it, some 30 years ago, dealt with the row stride in a frame buffer or bitmap. This meaning is similar to the array reference as above. I disagree that they’re not in that article above talking primarily about the same thing that we are: their very first example, under the “Padding” headline, seems to exactly match our intent. Their additional examples are just hacks/extensions of this concept. If we were talking about waveforms we’d be talking about period. Stride indicates the same thing with regard to items in memory: how long a step do you need to take to get from the start of one item to the start of the next. So we could use “period”, or “interval”, or “step”, or something. I’m just arguing that the most recognizable word to describe this concept, as applied to any sort of item in memory, is stride. But again, maybe that’s just based on my own experience. Ultimately, I’m sure it’s not a big deal. I agree with Mathew that people using MemoryLayout aren’t likely to confuse the two uses within swift. It’s just that if I had to describe the concept we’re describing in MemoryLayout, stride would be my first choice, as it seems most apt. Short of that, I’m sure that I could read comments and ultimately figure out that “interval,” or “spacing,” or whatever, really means “stride” ;) James _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
