I'm not sure this bikeshed is the right color yet.
How does the user remember the distinction between MemoryLayout<Int> and
MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
of() ?
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
···
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from memorylayout.md · GitHub
Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does MemoryLayout still need a public init? Half of the proposal’s problems revolve around the likely-unexpected behavior caused by passing T.self to the init function (although, argument labels would also solve the issue).
- Dave Sweeris
···
On Jun 29, 2016, at 10:05 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
I'm not sure this bikeshed is the right color yet.
How does the user remember the distinction between MemoryLayout<Int> and MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than of() ?
On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from https://gist.github.com/erica/57a64163870486468180b8bab8a6294e\)
// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8
// Value
let x: UInt8 = 5
MemoryLayout(x).dynamicType.size // 1
MemoryLayout("hello").dynamicType.arraySpacing // 24
MemoryLayout(29.2).dynamicType.alignment // 8
At least, I thought that was the latest version of the proposal. Maybe I’ve gotten confused.
There must be a typo in these examples. `MemoryLayout(x.dynamicType).size` perhaps?
>>
>> That’s the “as proposed” usage for getting the size of a value (from
>> memorylayout.md · GitHub
>
>> <https://gist.github.com/erica/57a64163870486468180b8bab8a6294e>\)
>> // Types
>> MemoryLayout<Int>.size // 8
>> MemoryLayout<Int>.arraySpacing // 8
>> MemoryLayout<Int>.alignment // 8
>>
>> // Value
>> let x: UInt8 = 5
>> MemoryLayout(x).dynamicType.size // 1
>> MemoryLayout("hello").dynamicType.arraySpacing // 24
>> MemoryLayout(29.2).dynamicType.alignment // 8
>>
>>
>> At least, I thought that was the latest version of the proposal. Maybe
I’ve gotten confused.
>>
>> There must be a typo in these examples.
`MemoryLayout(x.dynamicType).size` perhaps?
>
> I have listened. I have updated.
>
> memorylayout.md · GitHub
>
> // Types
> MemoryLayout<Int>.size // 8
> MemoryLayout<Int>.arraySpacing // 8
> MemoryLayout<Int>.alignment // 8
>
> // Value
> let x: UInt8 = 5
> MemoryLayout.of(x).size // 1
> MemoryLayout.of(1).size // 8
> MemoryLayout.of("hello").arraySpacing // 24
> MemoryLayout.of(29.2).alignment // 8
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
So long as the issue regarding querying an existential value's dynamic type
is addressed, yes?
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.
···
On Thu, Jun 30, 2016 at 2:30 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com > <mailto:davesweeris@mac.com>> wrote:
I agree and being able to ask about the size of an instance implies things that aren’t true. Sticking “value” labels on everything doesn’t change the fact that sizeOf(swift_array) is not going to give you the size of the underlying buffer no matter how you slice it.
IMHO Sizes are for types, just drop the instance stuff. There is no point in keeping it.
Russ
···
On Jun 30, 2016, at 12:30 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
let value: Any = 2 // dynamicType is Int
let layout = MemoryLayout(value).dynamicType // inlined from above
let arrayType = [value].dynamicType
‘layout’ here is still 'MemoryLayout<Any>', not 'MemoryLayout<Int>', for the same reason that ‘arrayType’ is ‘Array<Any>’ rather than ‘Array<Int>’.
If we want to support sizeofValue et al, we’d need to make these instance properties rather than static properties, and may then want to give up on the struct being generic.
Jordan
···
On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from memorylayout.md · GitHub
// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").arraySpacing // 24
MemoryLayout.of(29.2).alignment // 8
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
Good point; ideally, there would be no initializers at all.
···
On Thu, Jun 30, 2016 at 10:24 AM, David Sweeris <davesweeris@mac.com> wrote:
Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does
MemoryLayout still need a public init? Half of the proposal’s problems
revolve around the likely-unexpected behavior caused by passing T.self to
the init function (although, argument labels would also solve the issue).
- Dave Sweeris
On Jun 29, 2016, at 10:05 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
I'm not sure this bikeshed is the right color yet.
How does the user remember the distinction between MemoryLayout<Int> and
MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
of() ?
>>
>> That’s the “as proposed” usage for getting the size of a value (from
>> memorylayout.md · GitHub
>
>> <https://gist.github.com/erica/57a64163870486468180b8bab8a6294e>\)
>> // Types
>> MemoryLayout<Int>.size // 8
>> MemoryLayout<Int>.arraySpacing // 8
>> MemoryLayout<Int>.alignment // 8
>>
>> // Value
>> let x: UInt8 = 5
>> MemoryLayout(x).dynamicType.size // 1
>> MemoryLayout("hello").dynamicType.arraySpacing // 24
>> MemoryLayout(29.2).dynamicType.alignment // 8
>>
>>
>> At least, I thought that was the latest version of the proposal. Maybe
I’ve gotten confused.
>>
>> There must be a typo in these examples.
`MemoryLayout(x.dynamicType).size` perhaps?
>
> I have listened. I have updated.
>
> memorylayout.md · GitHub
>
> // Types
> MemoryLayout<Int>.size // 8
> MemoryLayout<Int>.arraySpacing // 8
> MemoryLayout<Int>.alignment // 8
>
> // Value
> let x: UInt8 = 5
> MemoryLayout.of(x).size // 1
> MemoryLayout.of(1).size // 8
> MemoryLayout.of("hello").arraySpacing // 24
> MemoryLayout.of(29.2).alignment // 8
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
So long as the issue regarding querying an existential value's dynamic type
is addressed, yes?
Oh, I guess that's right.
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.”
···
on Thu Jun 30 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
On Thu, Jun 30, 2016 at 2:30 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:
>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com >> <mailto:davesweeris@mac.com>> wrote:
As a meta-issue, it's been hard to make meaningful commentary during this
review process because the latest proposal has been so rapidly shifting
throughout. What, exactly, is the version we are reviewing at the moment?
Can we have a few days to mull over that version specifically?
···
On Thu, Jun 30, 2016 at 12:24 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:
Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does
MemoryLayout still need a public init? Half of the proposal’s problems
revolve around the likely-unexpected behavior caused by passing T.self to
the init function (although, argument labels would also solve the issue).
- Dave Sweeris
On Jun 29, 2016, at 10:05 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
I'm not sure this bikeshed is the right color yet.
How does the user remember the distinction between MemoryLayout<Int> and
MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
of() ?
And moved it to "If for some reason, the core team decides that there's a compelling reason to include value calls, an implementation might look something like this" instead.
Dave expressed that this should be something that operates on types not values.
-- E
···
On Jul 12, 2016, at 2:43 PM, Jordan Rose <jordan_rose@apple.com> wrote:
Sorry to only come across this now. The proposed implementation does not work.
let value: Any = 2 // dynamicType is Int
let layout = MemoryLayout(value).dynamicType // inlined from above
let arrayType = [value].dynamicType
‘layout’ here is still 'MemoryLayout<Any>', not 'MemoryLayout<Int>', for the same reason that ‘arrayType’ is ‘Array<Any>’ rather than ‘Array<Int>’.
If we want to support sizeofValue et al, we’d need to make these instance properties rather than static properties, and may then want to give up on the struct being generic.
// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").arraySpacing // 24
MemoryLayout.of(29.2).alignment // 8
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
Sorry to only come across this now. The proposed implementation does not work.
let value: Any = 2 // dynamicType is Int
let layout = MemoryLayout(value).dynamicType // inlined from above
let arrayType = [value].dynamicType
‘layout’ here is still 'MemoryLayout<Any>', not 'MemoryLayout<Int>',
for the same reason that ‘arrayType’ is ‘Array<Any>’ rather than
‘Array<Int>’.
That is the right answer. If you want to store an array of things with
the same type as “value” (== Any) you need that MemoryLayout.
If we want to support sizeofValue et al, we’d need to make these
instance properties rather than static properties, and may then want
to give up on the struct being generic.
That wouldn't change anything. Nothing can possibly unwrap the Any and
find out the size of the thing. The current sizeofValue() doesn't work
that way either:
print(sizeofValue(1 as Int8 as Any))
···
on Tue Jul 12 2016, Jordan Rose <jordan_rose-AT-apple.com> wrote:
On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
The only proposal that's in review is the one on github at Swift Evolution.
I have been putting together another version as a courtesy for Dave A, to flesh out how the alternative approach would look if the alternative was the primary proposal. That one is a personal gist.
-- E
···
On Jun 30, 2016, at 12:00 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
As a meta-issue, it's been hard to make meaningful commentary during this review process because the latest proposal has been so rapidly shifting throughout. What, exactly, is the version we are reviewing at the moment? Can we have a few days to mull over that version specifically?
On Thu, Jun 30, 2016 at 12:24 David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does MemoryLayout still need a public init? Half of the proposal’s problems revolve around the likely-unexpected behavior caused by passing T.self to the init function (although, argument labels would also solve the issue).
- Dave Sweeris
On Jun 29, 2016, at 10:05 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm not sure this bikeshed is the right color yet.
How does the user remember the distinction between MemoryLayout<Int> and MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than of() ?
On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from https://gist.github.com/erica/57a64163870486468180b8bab8a6294e\)
// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8
// Value
let x: UInt8 = 5
MemoryLayout(x).dynamicType.size // 1
MemoryLayout("hello").dynamicType.arraySpacing // 24
MemoryLayout(29.2).dynamicType.alignment // 8
At least, I thought that was the latest version of the proposal. Maybe I’ve gotten confused.
There must be a typo in these examples. `MemoryLayout(x.dynamicType).size` perhaps?
No way to last-second sell you on interval rather than spacing?
// Returns the least possible interval between distinct instances of
/// `T` in memory. The result is always positive.
-- E
···
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@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.”
On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from memorylayout.md · GitHub
// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").arraySpacing // 24
MemoryLayout.of(29.2).alignment // 8
I am still very skeptical that anyone needs the “Value” version, and as
long as we're resyntaxing I am inclined to take it away and see how many
people complain. You can still always write it yourself.
Sorry to only come across this now. The proposed implementation does not work.
let value: Any = 2 // dynamicType is Int
let layout = MemoryLayout(value).dynamicType // inlined from above
let arrayType = [value].dynamicType
‘layout’ here is still 'MemoryLayout<Any>', not 'MemoryLayout<Int>',
for the same reason that ‘arrayType’ is ‘Array<Any>’ rather than
‘Array<Int>’.
That is the right answer. If you want to store an array of things with
the same type as “value” (== Any) you need that MemoryLayout.
If we want to support sizeofValue et al, we’d need to make these
instance properties rather than static properties, and may then want
to give up on the struct being generic.
That wouldn't change anything. Nothing can possibly unwrap the Any and
find out the size of the thing. The current sizeofValue() doesn't work
that way either:
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.
···
on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@apple.com> wrote:
Hmm. Sounds like stride to me. stride or byteStride?
James
···
On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@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.
On Jun 30, 2016, at 5:05 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@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.
The trouble with spacing is that spaces are usually “between” things. “interval” just seems like a a poor approximation for “stride” which really is the term of art here and what people/I would expect.
James
···
On Jun 30, 2016, at 4:47 PM, James Berry <jberry@rogueorbit.com> wrote:
On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@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?
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."
-- E
···
On Jun 30, 2016, at 5:47 PM, James Berry <jberry@rogueorbit.com> wrote:
On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jun 30 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 30, 2016, at 4:41 PM, Dave Abrahams <dabrahams@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?
Heh. Guess I missed that FAQ. Ok, so I guess I don’t agree with the answer. Yes, stride gets used as a verb in the library, but it seems more confusing to work around its meaning as a noun. Would I look like a duck if you asked me to duck? ;) “stride” is the appropriate term of the art here, and anything else just obscures the truth.
James
···
On Jun 30, 2016, at 4:59 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Jun 30, 2016, at 5:47 PM, James Berry <jberry@rogueorbit.com <mailto:jberry@rogueorbit.com>> wrote:
On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@apple.com <mailto:dabrahams@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.”