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

[Erica Sadun via swift-evolution]

We removed "of" from the final version:

https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
 


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  wrote:
> 
> Sorry to only come across this now. The proposed implementation does not work.
> 
> public static func of(_ candidate : @autoclosure () -> T) -> 
> MemoryLayout.Type {
>   return MemoryLayout.init(candidate).dynamicType
> }
> 
> let value: Any = 2 // dynamicType is Int
> let layout = MemoryLayout(value).dynamicType // inlined from above
> let arrayType = [value].dynamicType
> 
> ‘layout’ here is still 'MemoryLayout', not 'MemoryLayout', for the 
> same reason that ‘arrayType’ is ‘Array’ rather than ‘Array’.
> 
> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jul 12, 2016, at 17:03, Dave Abrahams  wrote:
> 
> 
> on Tue Jul 12 2016, Jordan Rose  > wrote:
> 
>>> On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Wed Jun 29 2016, Erica Sadun  wrote:
>>> 
>> 
> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris  > wrote:
> That’s the “as proposed” usage for getting the size of a value (from
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
 
> )
> // Types
> MemoryLayout.size // 8 
> MemoryLayout.arraySpacing // 8
> MemoryLayout.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.
 
 https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
 
 // Types
 MemoryLayout.size // 8
 MemoryLayout.arraySpacing // 8
 MemoryLayout.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.
>> 
>> Sorry to only come across this now. The proposed implementation does not 
>> work.
>> 
>> public static func of(_ candidate : @autoclosure () -> T) -> 
>> MemoryLayout.Type {
>>  return MemoryLayout.init(candidate).dynamicType
>> }
>> 
>> let value: Any = 2 // dynamicType is Int
>> let layout = MemoryLayout(value).dynamicType // inlined from above
>> let arrayType = [value].dynamicType
>> 
>> ‘layout’ here is still 'MemoryLayout', not 'MemoryLayout',
>> for the same reason that ‘arrayType’ is ‘Array’ rather than
>> ‘Array’.
> 
> 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))

Okay, I didn’t realize it was still looking for a static type. In that case 
there’s an even simpler implementation:

public static func of(_ candidate : @autoclosure () -> T) -> 
MemoryLayout.Type {
  return MemoryLayout.self
}

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jul 12 2016, Jordan Rose  wrote:

>> On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 29 2016, Erica Sadun  wrote:
>> 
>
 On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris > wrote:
 That’s the “as proposed” usage for getting the size of a value (from
 https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>> 
 )
 // Types
 MemoryLayout.size // 8 
 MemoryLayout.arraySpacing // 8
 MemoryLayout.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.
>>> 
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>> 
>>> // Types
>>> MemoryLayout.size // 8
>>> MemoryLayout.arraySpacing // 8
>>> MemoryLayout.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.
>
> Sorry to only come across this now. The proposed implementation does not work.
>
> public static func of(_ candidate : @autoclosure () -> T) -> 
> MemoryLayout.Type {
>   return MemoryLayout.init(candidate).dynamicType
> }
>
> let value: Any = 2 // dynamicType is Int
> let layout = MemoryLayout(value).dynamicType // inlined from above
> let arrayType = [value].dynamicType
>
> ‘layout’ here is still 'MemoryLayout', not 'MemoryLayout',
> for the same reason that ‘arrayType’ is ‘Array’ rather than
> ‘Array’.

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))

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jun 30, 2016, at 12:30, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 29 2016, Erica Sadun  wrote:
> 
>>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris >> > wrote:
>>> That’s the “as proposed” usage for getting the size of a value (from
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> 
>>> )
>>> // Types
>>> MemoryLayout.size // 8 
>>> MemoryLayout.arraySpacing // 8
>>> MemoryLayout.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.
>> 
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> 
>> // Types
>> MemoryLayout.size // 8
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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.

Sorry to only come across this now. The proposed implementation does not work.

public static func of(_ candidate : @autoclosure () -> T) -> 
MemoryLayout.Type {
  return MemoryLayout.init(candidate).dynamicType
}

let value: Any = 2 // dynamicType is Int
let layout = MemoryLayout(value).dynamicType // inlined from above
let arrayType = [value].dynamicType

‘layout’ here is still 'MemoryLayout', not 'MemoryLayout', for the 
same reason that ‘arrayType’ is ‘Array’ rather than ‘Array’.

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> On Jul 1, 2016, at 8:57 AM, John McCall via swift-evolution 
>  wrote:
>> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu > > wrote:
>> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Thu Jun 30 2016, John McCall > > wrote:
>> 
>> >> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution 
>> >> > wrote:
>> >> on Thu Jun 30 2016, Matthew Johnson > >>  > >> >> wrote:
>> >>
>> >>> Sent from my iPad
>> >>>
>> >
>>  On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>>  > wrote:
>> 
>> 
>> >> On Jun 30, 2016, at 5:47 PM, James Berry > >> > wrote:
>> >>
>> >>
>> >> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>> >> > wrote:
>> >> on Thu Jun 30 2016, Erica Sadun > >> > wrote:
>> >>
>>  On Jun 30, 2016, at 4:41 PM, Dave Abrahams >  > 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 

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

[John McCall via swift-evolution]

> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu  wrote:
> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution 
> > wrote:
> 
> on Thu Jun 30 2016, John McCall  wrote:
> 
> >> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution 
> >> > wrote:
> >> on Thu Jun 30 2016, Matthew Johnson  >> >> 
> >> wrote:
> >>
> >>> Sent from my iPad
> >>>
> >
>  On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>  > wrote:
> 
> 
> >> On Jun 30, 2016, at 5:47 PM, James Berry  >> > wrote:
> >>
> >>
> >> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
> >> > wrote:
> >> on Thu Jun 30 2016, Erica Sadun  wrote:
> >>
>  On Jun 30, 2016, at 4:41 PM, Dave Abrahams   > 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 

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

[Erica Sadun via swift-evolution]

> On Jul 1, 2016, at 1:03 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> It's not the minimum though. Just go with stride already  
> 

Changing to stride.

> Sent from my illudium Q-36 explosive space modulator


-- Sent from the HQ of the Ravenous Bugblatter Beast of Traal


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Stephen Canon via swift-evolution]

On Jun 30, 2016, at 9:12 PM, Dave Abrahams via swift-evolution 
 wrote:

> 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.

FWIW, speaking as someone with zero inside-baseball knowledge of Swift but a 
lot of low-level experience when I first encountered `strideof`, I thought its 
purpose was immediately obvious, and that it was (and is) a good name.

– Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Bah, of course. No point in trying to qualify the word; let's just call it
the memory layout stride and be done with it.


On Fri, Jul 1, 2016 at 02:05 Dave Abrahams  wrote:

> No, actually both can be something other than the minimum.  These are
> usually going to be the minimum-without-performance-degradation.
>
>
> Sent from my illudium Q-36 explosive space modulator
>
> On Jun 30, 2016, at 11:29 PM, Xiaodi Wu  wrote:
>
> I don't think it needs qualifying. It cannot be anything other than the
> minimum, just like we have `alignment` instead of `minimumAlignment`.
> On Fri, Jul 1, 2016 at 00:50 Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> There seems to be agreement that "stride" is sensical term for the
>> distance between values in memory, but it seems like what MemoryLayout
>> wants to expose is the *minimum* possible stride for a particular type. How
>> do folks feel about "*minimumStride*"?
>>
>> On Thu, Jun 30, 2016 at 10:46 PM, James Berry via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> > On Jun 30, 2016, at 10:07 PM, Dave Abrahams 
>>> wrote:
>>> >
>>> >
>>> > on Thu Jun 30 2016, Matthew Johnson >> > wrote:
>>> >
>>> >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams 
>>> wrote:
>>> >>>
>>> >>>
>>> >>> on Thu Jun 30 2016, Matthew Johnson >>  >
>>> wrote:
>>> >>>
>>> >>
>>>  Sent from my iPad
>>> 
>>> > On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> >
>>> >>> On Jun 30, 2016, at 5:47 PM, James Berry 
>>> 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 >> > wrote:
>>> >>>
>>> > On Jun 30, 2016, at 4:41 PM, Dave Abrahams <
>>> dabrah...@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 

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

[Dave Abrahams via swift-evolution]

No, actually both can be something other than the minimum.  These are usually 
going to be the minimum-without-performance-degradation. 

Sent from my illudium Q-36 explosive space modulator

> On Jun 30, 2016, at 11:29 PM, Xiaodi Wu  wrote:
> 
> I don't think it needs qualifying. It cannot be anything other than the 
> minimum, just like we have `alignment` instead of `minimumAlignment`.
>> On Fri, Jul 1, 2016 at 00:50 Jacob Bandes-Storch via swift-evolution 
>>  wrote:
>> There seems to be agreement that "stride" is sensical term for the distance 
>> between values in memory, but it seems like what MemoryLayout wants to 
>> expose is the *minimum* possible stride for a particular type. How do folks 
>> feel about "minimumStride"?
>> 
>>> On Thu, Jun 30, 2016 at 10:46 PM, James Berry via swift-evolution 
>>>  wrote:
>>> 
>>> > On Jun 30, 2016, at 10:07 PM, Dave Abrahams  wrote:
>>> >
>>> >
>>> > on Thu Jun 30 2016, Matthew Johnson  wrote:
>>> >
>>> >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams  wrote:
>>> >>>
>>> >>>
>>> >>> on Thu Jun 30 2016, Matthew Johnson >> >>> > wrote:
>>> >>>
>>> >>
>>>  Sent from my iPad
>>> 
>>> > On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>>> >  wrote:
>>> >
>>> >
>>> >>> On Jun 30, 2016, at 5:47 PM, James Berry  
>>> >>> wrote:
>>> >>>
>>> >>>
>>> >>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>> >>>  wrote:
>>> >>> on Thu Jun 30 2016, Erica Sadun  wrote:
>>> >>>
>>> > On Jun 30, 2016, at 4:41 PM, Dave Abrahams  
>>> > 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 

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

[Dave Abrahams via swift-evolution]

It's not the minimum though. Just go with stride already  

Sent from my illudium Q-36 explosive space modulator

> On Jun 30, 2016, at 10:49 PM, Jacob Bandes-Storch  wrote:
> 
> There seems to be agreement that "stride" is sensical term for the distance 
> between values in memory, but it seems like what MemoryLayout wants to expose 
> is the *minimum* possible stride for a particular type. How do folks feel 
> about "minimumStride"?
> 
>> On Thu, Jun 30, 2016 at 10:46 PM, James Berry via swift-evolution 
>>  wrote:
>> 
>> > On Jun 30, 2016, at 10:07 PM, Dave Abrahams  wrote:
>> >
>> >
>> > on Thu Jun 30 2016, Matthew Johnson  wrote:
>> >
>> >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams  wrote:
>> >>>
>> >>>
>> >>> on Thu Jun 30 2016, Matthew Johnson > >>> > wrote:
>> >>>
>> >>
>>  Sent from my iPad
>> 
>> > On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>> >  wrote:
>> >
>> >
>> >>> On Jun 30, 2016, at 5:47 PM, James Berry  
>> >>> wrote:
>> >>>
>> >>>
>> >>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>> >>>  wrote:
>> >>> on Thu Jun 30 2016, Erica Sadun  wrote:
>> >>>
>> > On Jun 30, 2016, at 4:41 PM, Dave Abrahams  
>> > 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 

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

[Xiaodi Wu via swift-evolution]

I don't think it needs qualifying. It cannot be anything other than the
minimum, just like we have `alignment` instead of `minimumAlignment`.
On Fri, Jul 1, 2016 at 00:50 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> There seems to be agreement that "stride" is sensical term for the
> distance between values in memory, but it seems like what MemoryLayout
> wants to expose is the *minimum* possible stride for a particular type. How
> do folks feel about "*minimumStride*"?
>
> On Thu, Jun 30, 2016 at 10:46 PM, James Berry via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jun 30, 2016, at 10:07 PM, Dave Abrahams 
>> wrote:
>> >
>> >
>> > on Thu Jun 30 2016, Matthew Johnson  wrote:
>> >
>> >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams 
>> wrote:
>> >>>
>> >>>
>> >>> on Thu Jun 30 2016, Matthew Johnson > 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@swift.org> wrote:
>> >
>> >
>> >>> On Jun 30, 2016, at 5:47 PM, James Berry 
>> 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  wrote:
>> >>>
>> > On Jun 30, 2016, at 4:41 PM, Dave Abrahams 
>> 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
>> >> 

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

[Jacob Bandes-Storch via swift-evolution]

There seems to be agreement that "stride" is sensical term for the distance
between values in memory, but it seems like what MemoryLayout wants to
expose is the *minimum* possible stride for a particular type. How do folks
feel about "*minimumStride*"?

On Thu, Jun 30, 2016 at 10:46 PM, James Berry via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 30, 2016, at 10:07 PM, Dave Abrahams  wrote:
> >
> >
> > on Thu Jun 30 2016, Matthew Johnson  wrote:
> >
> >>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams 
> wrote:
> >>>
> >>>
> >>> on Thu Jun 30 2016, Matthew Johnson  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@swift.org> wrote:
> >
> >
> >>> On Jun 30, 2016, at 5:47 PM, James Berry 
> 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  wrote:
> >>>
> > On Jun 30, 2016, at 4:41 PM, Dave Abrahams 
> 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 

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

[James Berry via swift-evolution]

> On Jun 30, 2016, at 10:07 PM, Dave Abrahams  wrote:
> 
> 
> on Thu Jun 30 2016, Matthew Johnson  wrote:
> 
>>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Thu Jun 30 2016, Matthew Johnson >> > wrote:
>>> 
>> 
 Sent from my iPad
 
> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
>>> 
>>> 
>>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> on Thu Jun 30 2016, Erica Sadun  wrote:
>>> 
> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  
> 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 

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

[Dave Abrahams via swift-evolution]

on Thu Jun 30 2016, Matthew Johnson  wrote:

>> On Jun 30, 2016, at 8:12 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Thu Jun 30 2016, Matthew Johnson > > wrote:
>> 
>
>>> Sent from my iPad
>>> 
 On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
  wrote:
 
 
>> On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
>> 
>> 
>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> on Thu Jun 30 2016, Erica Sadun  wrote:
>> 
 On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> On Jun 30, 2016, at 6:12 PM, Dave Abrahams via swift-evolution 
>  wrote:
> on Thu Jun 30 2016, Matthew Johnson  > wrote:
> 
>> Sent from my iPad
>> 
>>> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
> 
> 
> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>  wrote:
> on Thu Jun 30 2016, Erica Sadun  wrote:
> 
>>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Thu, Jun 30, 2016 at 8:21 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 30, 2016, at 8:12 PM, Dave Abrahams  wrote:
>
>
> on Thu Jun 30 2016, Matthew Johnson  > wrote:
>
> Sent from my iPad
>
> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 30, 2016, at 5:47 PM, James Berry  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  > wrote:
>
> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.
>

This does make the case for stride more strongly. At this point I too could
go either way.


>
> -Matthew
>
>
> --
> Dave
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Thu Jun 30 2016, Matthew Johnson  wrote:

> Sent from my iPad
>
>> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> 
 On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
 
 
 On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
  wrote:
 on Thu Jun 30 2016, Erica Sadun  wrote:
 
>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 30, 2016, at 6:59 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
>>> 
>>> 
>>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> on Thu Jun 30 2016, Erica Sadun  wrote:
>>> 
> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.

> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Berry via swift-evolution]

> On Jun 30, 2016, at 4:59 PM, Erica Sadun  wrote:
> 
> 
>> On Jun 30, 2016, at 5:47 PM, James Berry > > wrote:
>> 
>>> 
>>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> on Thu Jun 30 2016, Erica Sadun >> > wrote:
>>> 
> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  > 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.”


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


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 30, 2016, at 5:47 PM, James Berry  wrote:
> 
>> 
>> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> on Thu Jun 30 2016, Erica Sadun  wrote:
>> 
 On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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."

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Berry via swift-evolution]

> On Jun 30, 2016, at 4:05 PM, Dave Abrahams via swift-evolution 
>  wrote:
> on Thu Jun 30 2016, Erica Sadun  wrote:
> 
>>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 30, 2016, at 5:05 PM, Dave Abrahams  wrote:
> 
> 
> on Thu Jun 30 2016, Erica Sadun  wrote:
> 
>>> On Jun 30, 2016, at 4:41 PM, Dave Abrahams  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.
> 
> -- 
> Dave

Pull requests:

SE-0101 Reconfiguring sizeof and related functions 


and

Updating Buffer Value Names to Header Names 


-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Thu Jun 30 2016, Xiaodi Wu  wrote:

> On Thu, Jun 30, 2016 at 2:30 PM, Dave Abrahams  wrote:
>
>>
>> on Wed Jun 29 2016, Erica Sadun  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 > > wrote:
>> >> That’s the “as proposed” usage for getting the size of a value (from
>> >> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> >
>> >> )
>> >> // Types
>> >> MemoryLayout.size // 8
>> >> MemoryLayout.arraySpacing // 8
>> >> MemoryLayout.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.
>> >
>> > https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> >
>> > // Types
>> > MemoryLayout.size // 8
>> > MemoryLayout.arraySpacing // 8
>> > MemoryLayout.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.”

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Russ Bishop via swift-evolution]

> On Jun 30, 2016, at 12:30 PM, Dave Abrahams via swift-evolution 
>  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.
> 

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jun 29 2016, Erica Sadun  wrote:

>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris > > wrote:
>> That’s the “as proposed” usage for getting the size of a value (from
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>
>> )
>> // Types
>> MemoryLayout.size // 8 
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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.
>
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>
> // Types
> MemoryLayout.size // 8
> MemoryLayout.arraySpacing // 8
> MemoryLayout.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.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jun 29 2016, David Sweeris  wrote:

> (While I was typing this up, I realized that the exact usage you’re
> worried about, “MemoryLayout(Int.self).size” won’t compile, since
> `MemoryLayout` currently doesn’t have instance properties. If you’re
> worried about someone incorrectly typing out
> “MemoryLayout(Int.self).dynamicType.size”, though…)
>
> I made a rather critical typo in my earlier reply. It should’ve been
> “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
> extension MemoryLayout { // assuming `MemoryLayout` is already defined as 
> proposed
> public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` 
> still has the correct type for `T`
> }
>
> Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
> // without `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 8, almost certainly wrong
> //MemoryLayout(Int8).dynamicType.size   // error
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly 
> worded
> //MemoryLayout(Int8.Type).dynamicType.size  // error
>
> // with `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 1, almost certainly correct
> MemoryLayout(Int8).dynamicType.size   // 1, almost certainly correct
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly 
> worded
> MemoryLayout(Int8.Type).dynamicType.size  // 8, correct
>
> The only value that changes (aside from the errors) is the one “typo” that 
> you were worried about.
>
> Do this change your mind? 

No; it's too tricky. In your design MemoryLayout(x) now has two
different meanings depending on the type of x.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 
>  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 
> > 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 
> > wrote:
>> 
>> I'm not sure this bikeshed is the right color yet.
>> 
>> How does the user remember the distinction between MemoryLayout and 
>> MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than 
>> of() ?
>> 
>> Also, could the implementation be simply
>> 
>> static func ofValue(_ value: @autoclosure () -> T) -> 
>> MemoryLayout.Type {
>> return self
>> }
>> 
>> ?
>> 
>> Jacob
>> 
>> On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris >> > wrote:
>>> That’s the “as proposed” usage for getting the size of a value (from 
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 
>>> ) 
>>> // Types
>>> MemoryLayout.size // 8 
>>> MemoryLayout.arraySpacing // 8
>>> MemoryLayout.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.
>> 
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 
>> 
>> 
>> // Types
>> MemoryLayout.size // 8
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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
>> 
>> 
>> -- E
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

Good point; ideally, there would be no initializers at all.

On Thu, Jun 30, 2016 at 10:24 AM, David Sweeris  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 and
> MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
> of() ?
>
> Also, could the implementation be simply
>
> static func ofValue(_ value: @autoclosure () -> T) ->
> MemoryLayout.Type {
> return self
> }
>
> ?
>
> Jacob
>
> On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> 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 
>> wrote:
>>
>>> That’s the “as proposed” usage for getting the size of a value (from
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e)
>>>
>>> // Types
>>> MemoryLayout.size // 8
>>> MemoryLayout.arraySpacing // 8
>>> MemoryLayout.alignment // 8
>>> // Valuelet 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.
>>
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>
>> // Types
>> MemoryLayout.size // 8
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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
>>
>>
>> -- E
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 and
> MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
> of() ?
>
> Also, could the implementation be simply
>
> static func ofValue(_ value: @autoclosure () -> T) ->
> MemoryLayout.Type {
> return self
> }
>
> ?
>
> Jacob
>
> On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> 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 
>> wrote:
>>
>>> That’s the “as proposed” usage for getting the size of a value (from
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e)
>>>
>>> // Types
>>> MemoryLayout.size // 8
>>> MemoryLayout.arraySpacing // 8
>>> MemoryLayout.alignment // 8
>>> // Valuelet 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.
>>
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>
>> // Types
>> MemoryLayout.size // 8
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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
>>
>>
>> -- E
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

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 
 wrote:
> 
> I'm not sure this bikeshed is the right color yet.
> 
> How does the user remember the distinction between MemoryLayout and 
> MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than of() 
> ?
> 
> Also, could the implementation be simply
> 
> static func ofValue(_ value: @autoclosure () -> T) -> 
> MemoryLayout.Type {
> return self
> }
> 
> ?
> 
> Jacob
> 
> On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution 
> > wrote:
> 
>> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris > > wrote:
>> That’s the “as proposed” usage for getting the size of a value (from 
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 
>> ) 
>> // Types
>> MemoryLayout.size // 8 
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.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.
> 
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 
> 
> 
> // Types
> MemoryLayout.size // 8
> MemoryLayout.arraySpacing // 8
> MemoryLayout.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
> 
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

I'm not sure this bikeshed is the right color yet.

How does the user remember the distinction between MemoryLayout and
MemoryLayout.of(Int) ? To keep it clear, how about ofValue() rather than
of() ?

Also, could the implementation be simply

static func ofValue(_ value: @autoclosure () -> T) ->
MemoryLayout.Type {
return self
}

?

Jacob

On Wed, Jun 29, 2016 at 7:36 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> 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 
> wrote:
>
>> That’s the “as proposed” usage for getting the size of a value (from
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e)
>>
>> // Types
>> MemoryLayout.size // 8
>> MemoryLayout.arraySpacing // 8
>> MemoryLayout.alignment // 8
>> // Valuelet 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.
>
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>
> // Types
> MemoryLayout.size // 8
> MemoryLayout.arraySpacing // 8
> MemoryLayout.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
>
>
> -- E
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris  > wrote:
> That’s the “as proposed” usage for getting the size of a value (from 
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 
> ) 
> // Types
> MemoryLayout.size // 8 
> MemoryLayout.arraySpacing // 8
> MemoryLayout.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.

https://gist.github.com/erica/57a64163870486468180b8bab8a6294e

// Types
MemoryLayout.size // 8
MemoryLayout.arraySpacing // 8
MemoryLayout.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


-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Jun 29, 2016, at 4:59 PM, Xiaodi Wu  wrote:
> 
> There must be a typo in these examples. `MemoryLayout(x.dynamicType).size` 
> perhaps?

Dunno if it’s intentional or not. Hooman Mehr already suggested we add instance 
properties:
> On Jun 28, 2016, at 8:27 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> How about we get rid of dynamicType by adding instance level properties as 
> well:
> 
> public struct MemoryLayout {
> 
> public static var size: Int { return sizeof(T) }
> public static var interval: Int { return strideof(T) }
> public static var alignment: Int { return alignof(T) }
> 
> public var size: Int { return sizeof(T) }
> public var interval: Int { return strideof(T) }
> public var alignment: Int { return alignof(T) }
> 
> init(_ : @autoclosure () -> T) {}
> }
> 
> print(MemoryLayout.size) // 8
> print(MemoryLayout.interval) // 8
> print(MemoryLayout.alignment) // 8
> 
> let x = 8
> 
> print(MemoryLayout(x).size) // 8
> print(MemoryLayout(x).interval) // 8
> print(MemoryLayout(x).alignment) // 8


Doing that makes that list look like this:
MemoryLayout.size   // 1, correct
MemoryLayout(Int8.self).size  // 1, almost certainly correct
MemoryLayout(Int8).size   // 1, almost certainly correct
MemoryLayout(0 as Int8).size  // 1, correct
MemoryLayout.size  // 8, correct
MemoryLayout(Int8.Type.self).size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).size  // 8, correct

I thought of something else… if we had a way to intentionally trigger a 
compile-time error in code that’s otherwise correct, we could define the 
`init(_: T.self)` function like this:
extension MemoryLayout {
public init(_ : T.Type) { #throwErrorIfReached("Incorrect Usage... 
NOCOMPILINGFORYOU!!!") }
}

Then the list of statements which compile would be much simpler:
let x: Int8 = 0
MemoryLayout.size  // 1, correct and unambiguous
MemoryLayout(x).size // 1, correct and unambiguous (assuming the 
instance properties are added)
MemoryLayout.size // 8, correct and unambiguous

But that’s its own proposal, and one I’m not sure is worth making.

- Dave Sweeris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris  wrote:

> That’s the “as proposed” usage for getting the size of a value (from
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e)
>
> // Types
> MemoryLayout.size // 8
> MemoryLayout.arraySpacing // 8
> MemoryLayout.alignment // 8
> // Valuelet 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?


>
> - Dave Sweeris
>
>
> On Jun 29, 2016, at 4:36 PM, Xiaodi Wu  wrote:
>
>
>
> On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> (While I was typing this up, I realized that the exact usage you’re
>> worried about, “MemoryLayout(Int.self).size” won’t compile, since
>> `MemoryLayout` currently doesn’t have instance properties. If you’re
>> worried about someone incorrectly typing out
>> “MemoryLayout(Int.self).dynamicType.size”, though…)
>>
>> I made a rather critical typo in my earlier reply. It should’ve been
>> “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
>> extension MemoryLayout { // assuming `MemoryLayout` is already
>> defined as proposed
>> public init(_ : T.Type) {} // makes it so that
>> `MemoryLayout(T.self)` still has the correct type for `T`
>> }
>>
>> Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
>> // without `init(_ : T.Type)` defined
>> MemoryLayout.size   // 1, correct
>> MemoryLayout(Int8.self).dynamicType.size  // 8, almost certainly
>> wrong
>> //MemoryLayout(Int8).dynamicType.size   // error
>> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
>> MemoryLayout.size  // 8, correct
>> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
>> oddly worded
>> //MemoryLayout(Int8.Type).dynamicType.size  // error
>>
>> // with `init(_ : T.Type)` defined
>> MemoryLayout.size   // 1, correct
>> MemoryLayout(Int8.self).dynamicType.size  // 1, almost certainly
>> correct
>> MemoryLayout(Int8).dynamicType.size   // 1, almost certainly
>> correct
>> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
>> MemoryLayout.size  // 8, correct
>> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
>> oddly worded
>> MemoryLayout(Int8.Type).dynamicType.size  // 8, correct
>>
>> The only value that changes (aside from the errors) is the one “typo”
>> that you were worried about.
>>
>> Do this change your mind?
>>
>
> These examples make no sense to me. Why are we asking for the size of the
> dynamicType of MemoryLayout?
>
>
>>
>>
>>
>> On Jun 29, 2016, at 12:34 PM, Dave Abrahams  wrote:
>>
>>
>>
>> on Wed Jun 29 2016, David Sweeris > > wrote:
>>
>> Would adding a "init(_: T.self) {...}" solve that issue?
>>
>>
>> ? I don't see how.
>>
>>
>> Sent from my iPhone
>>
>> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> My worry is that people will write
>>
>> MemoryLayout(Int.self).size
>>
>> when they mean
>>
>> MemoryLayout.size
>>
>> (often because for some reason they don't like angle brackets).
>>
>> I prefer to make the uncommon case much harder to write.
>>
>>
>> --
>> Dave
>>
>>
>>
>> - Dave Sweeris
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

That’s the “as proposed” usage for getting the size of a value (from 
https://gist.github.com/erica/57a64163870486468180b8bab8a6294e) 
// Types
MemoryLayout.size // 8 
MemoryLayout.arraySpacing // 8
MemoryLayout.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.

- Dave Sweeris

> On Jun 29, 2016, at 4:36 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution 
> > wrote:
> (While I was typing this up, I realized that the exact usage you’re worried 
> about, “MemoryLayout(Int.self).size” won’t compile, since `MemoryLayout` 
> currently doesn’t have instance properties. If you’re worried about someone 
> incorrectly typing out “MemoryLayout(Int.self).dynamicType.size”, though…)
> 
> I made a rather critical typo in my earlier reply. It should’ve been “init(_: 
> T.Type)”, instead of “init(_: T.self)”, which is to say this:
> extension MemoryLayout { // assuming `MemoryLayout` is already defined as 
> proposed
> public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` 
> still has the correct type for `T`
> }
> 
> Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
> // without `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 8, almost certainly wrong
> //MemoryLayout(Int8).dynamicType.size   // error
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly 
> worded
> //MemoryLayout(Int8.Type).dynamicType.size  // error
> 
> // with `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 1, almost certainly correct
> MemoryLayout(Int8).dynamicType.size   // 1, almost certainly correct
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly 
> worded
> MemoryLayout(Int8.Type).dynamicType.size  // 8, correct
> 
> The only value that changes (aside from the errors) is the one “typo” that 
> you were worried about.
> 
> Do this change your mind? 
> 
> These examples make no sense to me. Why are we asking for the size of the 
> dynamicType of MemoryLayout?
>  
> 
> 
> 
> On Jun 29, 2016, at 12:34 PM, Dave Abrahams  > wrote:
>> 
>> 
>> on Wed Jun 29 2016, David Sweeris > > wrote:
>> 
>>> Would adding a "init(_: T.self) {...}" solve that issue?
>>> 
>> 
>> ? I don't see how.
>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution 
 > wrote:
 
 My worry is that people will write 
 
 MemoryLayout(Int.self).size 
 
 when they mean
 
 MemoryLayout.size 
 
 (often because for some reason they don't like angle brackets).
 
 I prefer to make the uncommon case much harder to write.
>> 
>> -- 
>> Dave
> 
> 
> - Dave Sweeris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> (While I was typing this up, I realized that the exact usage you’re
> worried about, “MemoryLayout(Int.self).size” won’t compile, since
> `MemoryLayout` currently doesn’t have instance properties. If you’re
> worried about someone incorrectly typing out
> “MemoryLayout(Int.self).dynamicType.size”, though…)
>
> I made a rather critical typo in my earlier reply. It should’ve been
> “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
> extension MemoryLayout { // assuming `MemoryLayout` is already defined
> as proposed
> public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)`
> still has the correct type for `T`
> }
>
> Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
> // without `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 8, almost certainly wrong
> //MemoryLayout(Int8).dynamicType.size   // error
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly
> worded
> //MemoryLayout(Int8.Type).dynamicType.size  // error
>
> // with `init(_ : T.Type)` defined
> MemoryLayout.size   // 1, correct
> MemoryLayout(Int8.self).dynamicType.size  // 1, almost certainly
> correct
> MemoryLayout(Int8).dynamicType.size   // 1, almost certainly
> correct
> MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
> MemoryLayout.size  // 8, correct
> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly
> worded
> MemoryLayout(Int8.Type).dynamicType.size  // 8, correct
>
> The only value that changes (aside from the errors) is the one “typo” that
> you were worried about.
>
> Do this change your mind?
>

These examples make no sense to me. Why are we asking for the size of the
dynamicType of MemoryLayout?


>
>
>
> On Jun 29, 2016, at 12:34 PM, Dave Abrahams  wrote:
>
>
>
> on Wed Jun 29 2016, David Sweeris  > wrote:
>
> Would adding a "init(_: T.self) {...}" solve that issue?
>
>
> ? I don't see how.
>
>
> Sent from my iPhone
>
> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My worry is that people will write
>
> MemoryLayout(Int.self).size
>
> when they mean
>
> MemoryLayout.size
>
> (often because for some reason they don't like angle brackets).
>
> I prefer to make the uncommon case much harder to write.
>
>
> --
> Dave
>
>
>
> - Dave Sweeris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

(While I was typing this up, I realized that the exact usage you’re worried 
about, “MemoryLayout(Int.self).size” won’t compile, since `MemoryLayout` 
currently doesn’t have instance properties. If you’re worried about someone 
incorrectly typing out “MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been “init(_: 
T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout` is already defined as 
proposed
public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` still 
has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout.size   // 1, correct
MemoryLayout(Int8.self).dynamicType.size  // 8, almost certainly wrong
//MemoryLayout(Int8).dynamicType.size   // error
MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
MemoryLayout.size  // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
//MemoryLayout(Int8.Type).dynamicType.size  // error

// with `init(_ : T.Type)` defined
MemoryLayout.size   // 1, correct
MemoryLayout(Int8.self).dynamicType.size  // 1, almost certainly correct
MemoryLayout(Int8).dynamicType.size   // 1, almost certainly correct
MemoryLayout(0 as Int8).dynamicType.size  // 1, correct
MemoryLayout.size  // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).dynamicType.size  // 8, correct

The only value that changes (aside from the errors) is the one “typo” that you 
were worried about.

Do this change your mind? 



On Jun 29, 2016, at 12:34 PM, Dave Abrahams  wrote:
> 
> 
> on Wed Jun 29 2016, David Sweeris  wrote:
> 
>> Would adding a "init(_: T.self) {...}" solve that issue?
>> 
> 
> ? I don't see how.
> 
>> 
>> Sent from my iPhone
>> 
>>> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> My worry is that people will write 
>>> 
>>> MemoryLayout(Int.self).size 
>>> 
>>> when they mean
>>> 
>>> MemoryLayout.size 
>>> 
>>> (often because for some reason they don't like angle brackets).
>>> 
>>> I prefer to make the uncommon case much harder to write.
> 
> -- 
> Dave


- Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jun 29 2016, David Sweeris  wrote:

> Would adding a "init(_: T.self) {...}" solve that issue?
>

? I don't see how.

>
> Sent from my iPhone
>
>> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> My worry is that people will write 
>> 
>>  MemoryLayout(Int.self).size 
>> 
>> when they mean
>> 
>>  MemoryLayout.size 
>> 
>> (often because for some reason they don't like angle brackets).
>> 
>> I prefer to make the uncommon case much harder to write.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

Would adding a "init(_: T.self) {...}" solve that issue?

- Dave Sweeris

Sent from my iPhone

> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution 
>  wrote:
> 
> My worry is that people will write 
> 
>  MemoryLayout(Int.self).size 
> 
> when they mean
> 
>  MemoryLayout.size 
> 
> (often because for some reason they don't like angle brackets).
> 
> I prefer to make the uncommon case much harder to write.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 28 2016, Hooman Mehr  wrote:

> How about we get rid of dynamicType by adding instance level properties as 
> well:
>
> public struct MemoryLayout {
>
> public static var size: Int { return sizeof(T) }
> public static var interval: Int { return strideof(T) }
> public static var alignment: Int { return alignof(T) }
>
> public var size: Int { return sizeof(T) }
> public var interval: Int { return strideof(T) }
> public var alignment: Int { return alignof(T) }
>
> init(_ : @autoclosure () -> T) {}
> }
>
> print(MemoryLayout.size) // 8
> print(MemoryLayout.interval) // 8
> print(MemoryLayout.alignment) // 8
>
> let x = 8
>
> print(MemoryLayout(x).size) // 8
> print(MemoryLayout(x).interval) // 8
> print(MemoryLayout(x).alignment) // 8

My worry is that people will write 

  MemoryLayout(Int.self).size 

when they mean

  MemoryLayout.size 
 
(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

>
>> On Jun 28, 2016, at 5:08 PM, Dave Abrahams via swift-evolution
>>  wrote:
>> 
>> 
>> on Tue Jun 28 2016, Brandon Knope  wrote:
>> 
>>> Isn't dynamicType possibly changing soon to a method?
>> 
>> A free function, I think.
>> 
>>> This could look much different
>> 
>> Yes, It will be uglier.  But this very uncommon case is not important to
>> optimize for beauty.
>> 
>> -- 
>> Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 6:08 PM, Dave Abrahams  wrote:
> -- 
> Dave

Reload https://gist.github.com/erica/57a64163870486468180b8bab8a6294e and 
please make sure I properly updated the comments, the design, the examples.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brandon Knope via swift-evolution]

Just wanting to point out that option 2 could look vastly different! Neither 
looks "pretty", but the first one sure looks good 

Brandon 

> On Jun 28, 2016, at 8:08 PM, Dave Abrahams  wrote:
> 
> 
>> on Tue Jun 28 2016, Brandon Knope  wrote:
>> 
>> Isn't dynamicType possibly changing soon to a method?
> 
> A free function, I think.
> 
>> This could look much different
> 
> Yes, It will be uglier.  But this very uncommon case is not important to
> optimize for beauty.
> 
> -- 
> Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 28 2016, Brandon Knope  wrote:

> Isn't dynamicType possibly changing soon to a method?

A free function, I think.

> This could look much different

Yes, It will be uglier.  But this very uncommon case is not important to
optimize for beauty.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brandon Knope via swift-evolution]

Isn't dynamicType possibly changing soon to a method?

This could look much different

Brandon 

> On Jun 28, 2016, at 4:53 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution 
>  wrote:
 I think it would.  It would *really* help if someone would prepare a
 patch that uses both APIs so we could see how the resulting code looks
 in practice. :-)
 
 -- 
 Dave
>>> 
>>> Here you go:
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>> 
>> 
>> Thanks for the proposal, Erica.  It contains some errors that I pointed
>> out in a comment on the Gist.  Care to fix those?
>> 
> 
> public struct MemoryLayout {
> public static var size: Int { return sizeof(T) }
> public static var interval: Int { return strideof(T) }
> public static var alignment: Int { return alignof(T) }
> 
> init(_ : @autoclosure () -> T) {}
> }
> 
> print(MemoryLayout.size) // 8
> print(MemoryLayout.interval) // 8
> print(MemoryLayout.alignment) // 8
> 
> let x = 8
> 
> print(MemoryLayout(x).dynamicType.size) // 8
> print(MemoryLayout(x).dynamicType.interval) // 8
> print(MemoryLayout(x).dynamicType.alignment) // 8
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution 
 wrote:
>>> I think it would.  It would *really* help if someone would prepare a
>>> patch that uses both APIs so we could see how the resulting code looks
>>> in practice. :-)
>>> 
>>> -- 
>>> Dave
>> 
>> Here you go:
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> > >
> 
> Thanks for the proposal, Erica.  It contains some errors that I pointed
> out in a comment on the Gist.  Care to fix those?
> 

public struct MemoryLayout {
public static var size: Int { return sizeof(T) }
public static var interval: Int { return strideof(T) }
public static var alignment: Int { return alignof(T) }

init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout.size) // 8
print(MemoryLayout.interval) // 8
print(MemoryLayout.alignment) // 8

let x = 8

print(MemoryLayout(x).dynamicType.size) // 8
print(MemoryLayout(x).dynamicType.interval) // 8
print(MemoryLayout(x).dynamicType.alignment) // 8

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Thu Jun 23 2016, Erica Sadun  wrote:

>> On Jun 22, 2016, at 1:32 PM, Dave Abrahams via swift-evolution
>>  wrote:
>> 
>> 
>> on Wed Jun 22 2016, Erica Sadun  wrote:
>
>> 
 On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution
  wrote:
 
 
 on Wed Jun 22 2016, Erica Sadun  wrote:
> 
> No, I'd do edits on a gist page not in-place
 
 Then feel free, of course!  It's your choice, y'know.  I wouldn't want
 to ask you to propose something you don't believe in...
 
>>> 
>>> I believe the current approach needs improving. I am fine with both
>>> approaches.  You've more or less convinced me on a very good reason
>>> why a less perfect solution is a better approach.
>>> 
>>> I just want to know if it would help going into the core team review
>>> to have that rationale written up and formal in advance. 
>> 
>> I think it would.  It would *really* help if someone would prepare a
>> patch that uses both APIs so we could see how the resulting code looks
>> in practice. :-)
>> 
>> -- 
>> Dave
>
> Here you go:
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
> 

Thanks for the proposal, Erica.  It contains some errors that I pointed
out in a comment on the Gist.  Care to fix those?

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jun 22 2016, Erica Sadun  wrote:

>> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 22 2016, Erica Sadun  wrote:
>>> 
>>> No, I'd do edits on a gist page not in-place
>> 
>> Then feel free, of course!  It's your choice, y'know.  I wouldn't want
>> to ask you to propose something you don't believe in...
>> 
>
> I believe the current approach needs improving. I am fine with both
> approaches.  You've more or less convinced me on a very good reason
> why a less perfect solution is a better approach.
>
> I just want to know if it would help going into the core team review
> to have that rationale written up and formal in advance. 

I think it would.  It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 22 2016, Erica Sadun  wrote:
>> 
>> No, I'd do edits on a gist page not in-place
> 
> Then feel free, of course!  It's your choice, y'know.  I wouldn't want
> to ask you to propose something you don't believe in...
> 

I believe the current approach needs improving. I am fine with both approaches.
You've more or less convinced me on a very good reason why a less perfect 
solution is
a better approach. 

I just want to know if it would help going into the core team review to have 
that rationale
written up and formal in advance. If not, and this email back and forth is 
sufficient, I'm good.

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jun 22 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 7:07 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jun 21 2016, Erica Sadun > > wrote:
>> 
>
 On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
 
 It's just that I don't think this part of the library API is important
 enough, to enough people, that this readability is worth the additional
 exposed surface area (and further exposure later on—I can easily imagine
 a “minimumAlignment”).  I would *much* rather keep this stuff corralled
 in a single namespace where it can all be found.
>>> 
>>> See? That, I totally get.
>>> 
 I think you represented it just fine, thanks... I just don't think
 you're accounting for the big picture.  These APIs are not like “map,”
 “filter,” and “Dictionary.”  They're specialty items that you should
 only reach for when performing unsafe operations, mostly inside the guts
 of higher-level constructs.
 
 -- 
 Dave
>>> 
>>> Would you like me to edit it and flip the proposal then? Put the
>>> MemoryLayout in as primary, mine as secondary, and add in text to
>>> explain that the motivation is less usability than serving an unsafe
>>> API with minimal surface area?
>> 
>> Well, the review has already started, so I don't think we ought to go
>> inverting the proposal now.  Let's see how the discussion plays out.  If
>> at the end, you agree with my point-of-view, you can say so and the
>> review manager and core team will take that into account.
>
> No, I'd do edits on a gist page not in-place

Then feel free, of course!  It's your choice, y'know.  I wouldn't want
to ask you to propose something you don't believe in...

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 7:07 PM, Dave Abrahams  wrote:
> 
> 
> on Tue Jun 21 2016, Erica Sadun  > wrote:
> 
>>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
>>> 
>>> It's just that I don't think this part of the library API is important
>>> enough, to enough people, that this readability is worth the additional
>>> exposed surface area (and further exposure later on—I can easily imagine
>>> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
>>> in a single namespace where it can all be found.
>> 
>> See? That, I totally get.
>> 
>>> I think you represented it just fine, thanks... I just don't think
>>> you're accounting for the big picture.  These APIs are not like “map,”
>>> “filter,” and “Dictionary.”  They're specialty items that you should
>>> only reach for when performing unsafe operations, mostly inside the guts
>>> of higher-level constructs.
>>> 
>>> -- 
>>> Dave
>> 
>> Would you like me to edit it and flip the proposal then? Put the
>> MemoryLayout in as primary, mine as secondary, and add in text to
>> explain that the motivation is less usability than serving an unsafe
>> API with minimal surface area?
> 
> Well, the review has already started, so I don't think we ought to go
> inverting the proposal now.  Let's see how the discussion plays out.  If
> at the end, you agree with my point-of-view, you can say so and the
> review manager and core team will take that into account.

No, I'd do edits on a gist page not in-place

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

>   * What is your evaluation of the proposal?

-1.  I prefer the MemoryLayout struct approach that Dave Abrahams has 
suggested.  The proposed names retain the  the disadvantage of several top 
level names and introduce a new disadvantage that they are not directly related 
to familiar terms of art (sizeof from C, etc).

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I don’t think it is a critical change given the current names are related to 
terms of art.  If we are going to make a change I think it is better to reduce 
the number of top level names and make the relationship of them clear by making 
them members of a type.

>   * Does this proposal fit well with the feel and direction of Swift?

It fits the Swift 3 directive to do any breaking change bike shedding now.  
However, the overall direction of Swift is away from top level functions 
without a compelling reason that a top level function is necessary.  I don’t 
think these cases are compelling.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

They break the tie to familiar naming from other languages.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Participated quite a bit in the initial discussion and read the final proposal.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Patrick Smith via swift-evolution]

+1 to MemoryLayout, as I do like how it is namespaced under one type, which 
allows straight forward looking up of documentation. Writers from C or other 
sizeof() languages will able to see all available methods, allowing them to be 
educated to say not go for size but interval/spacing as the better choice.

Patrick

> On 22 Jun 2016, at 10:26 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams > > wrote:
>> 
>> It's just that I don't think this part of the library API is important
>> enough, to enough people, that this readability is worth the additional
>> exposed surface area (and further exposure later on—I can easily imagine
>> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
>> in a single namespace where it can all be found.
> 
> See? That, I totally get.
> 
>> I think you represented it just fine, thanks... I just don't think
>> you're accounting for the big picture.  These APIs are not like “map,”
>> “filter,” and “Dictionary.”  They're specialty items that you should
>> only reach for when performing unsafe operations, mostly inside the guts
>> of higher-level constructs.
>> 
>> -- 
>> Dave
> 
> Would you like me to edit it and flip the proposal then? Put the MemoryLayout 
> in as primary,
> mine as secondary, and add in text to explain that the motivation is less 
> usability than serving
> an unsafe API with minimal surface area?
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
>> 
>> It's just that I don't think this part of the library API is important
>> enough, to enough people, that this readability is worth the additional
>> exposed surface area (and further exposure later on—I can easily imagine
>> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
>> in a single namespace where it can all be found.
>
> See? That, I totally get.
>
>> I think you represented it just fine, thanks... I just don't think
>> you're accounting for the big picture.  These APIs are not like “map,”
>> “filter,” and “Dictionary.”  They're specialty items that you should
>> only reach for when performing unsafe operations, mostly inside the guts
>> of higher-level constructs.
>> 
>> -- 
>> Dave
>
> Would you like me to edit it and flip the proposal then? Put the
> MemoryLayout in as primary, mine as secondary, and add in text to
> explain that the motivation is less usability than serving an unsafe
> API with minimal surface area?

Well, the review has already started, so I don't think we ought to go
inverting the proposal now.  Let's see how the discussion plays out.  If
at the end, you agree with my point-of-view, you can say so and the
review manager and core team will take that into account.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
> 
> It's just that I don't think this part of the library API is important
> enough, to enough people, that this readability is worth the additional
> exposed surface area (and further exposure later on—I can easily imagine
> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
> in a single namespace where it can all be found.

See? That, I totally get.

> I think you represented it just fine, thanks... I just don't think
> you're accounting for the big picture.  These APIs are not like “map,”
> “filter,” and “Dictionary.”  They're specialty items that you should
> only reach for when performing unsafe operations, mostly inside the guts
> of higher-level constructs.
> 
> -- 
> Dave

Would you like me to edit it and flip the proposal then? Put the MemoryLayout 
in as primary,
mine as secondary, and add in text to explain that the motivation is less 
usability than serving
an unsafe API with minimal surface area?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

Generally in support, with two small exceptions:

1. I think the type variants should have the parameter label `of`. 
`memorySize(of: Int.self)` reads grammatically (other than the hopefully 
soon-to-be-vestigial `self`); `memorySize(Int.self)` does not.

2. I am not convinced that the `ofValue` variants are valuable enough to keep, 
although they do help support the (I think necessary, though I could probably 
be convinced otherwise now that these three all have a `memory` prefix) change 
to `type(ofValue:)`.

(Actually, I'm now considering the idea that these should be `valueSize(of: 
T.Type)`, etc., since they measure only the size of the immediate value, not 
any objects that value might reference. But that thought is underdeveloped, so 
I'm not ready to stand behind it.)

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes; these are inconsistent with the API guidelines.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I like that it's a little clearer what sort of "size" is meant; people are 
unlikely to imagine this will tell them an array's length, for instance.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> If I didn't think it would produce semantic confusion, these would be
>> static members e.g. `Array.memoryAlignment`, and you'd have to “scan
>> past” `Array`.  It's a perfectly natural way to express a property of a
>> type.
>
> I think
>
> Array.memoryAlignment 
>
> is quite different to scan than
>
> MemoryLayout(Array).alignment
>
> (And I obviously like the former a lot more if it wouldn't produce
> semantic confusion -- I assume you mean in the compiler and not
> the reader of the code). 

No, I mean to the reader of the code.  The former might easily be
interpreted as the memory alignment of the elements in the array, for
example.  And the effect is much worse with the counterpart to sizeof.

> That said, I think
>
> memoryAlignment(Array.self)
>
> reads better than
>
> MemoryLayout(Array).alignment
>
> You don't have to brainparse(TM by Cognition Inc) two other things 
> before arriving at alignment.  The MemoryLayout feels more prominent
> than it should. The alignment feels less prominent than it should.
>
> I recognize we disagree on this, 

We don't, actually.  I agree that by themselves the APIs you are
proposing look better.

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”).  I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

So, my argument is really about the overall shape of the standard
library and its effect on ordinary users more than the look/feel of
these particular APIs.

> and we're unlikely to convince each other on-list, which is why I
> tried hard to make sure that your alternative was properly presented
> in the proposal. If I have made any errors in expressing your design,
> its intent, and rationale, please let me know and I will edit the
> proposal to fix.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture.  These APIs are not like “map,”
“filter,” and “Dictionary.”  They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> If I didn't think it would produce semantic confusion, these would be
> static members e.g. `Array.memoryAlignment`, and you'd have to “scan
> past” `Array`.  It's a perfectly natural way to express a property of a
> type.


I think

Array.memoryAlignment 

is quite different to scan than

MemoryLayout(Array).alignment

(And I obviously like the former a lot more if it wouldn't produce
semantic confusion -- I assume you mean in the compiler and not
the reader of the code). That said, I think

memoryAlignment(Array.self)

reads better than

MemoryLayout(Array).alignment

You don't have to brainparse(TM by Cognition Inc) two other things 
before arriving at alignment.  The MemoryLayout feels more prominent
than it should. The alignment feels less prominent than it should.

I recognize we disagree on this, and we're unlikely to convince each other 
on-list, which is why I tried hard to make sure that your alternative was 
properly presented in the proposal. If  I have made any errors in expressing 
your design, its intent, and rationale, please let me know and I will edit the 
proposal to fix.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On Jun 21, 2016, at 1:23 PM, Dave Abrahams  wrote:
> 
> 
> 
> 
> on Tue Jun 21 2016, Joe Groff 
>  wrote:
> 
>> Regarding the issue of existential metatypes with sizeof:
>> 
>> Pyry Jahkola points out one instance where the memorySize(type(of: …))
>> workaround won't work. When the value is an existential, it's illegal
>> to ask for the size of its dynamic type: the result can't be retrieved
>> at compile time:
>> 
>> // Swift 2.2, 64-bit
>> let i = 123
>> print(sizeofValue(i)) //=> 8
>> let c: CustomStringConvertible = i
>> print(sizeofValue(c)) //=> 40
>> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
>> argument list of type '(CustomStringCo
>> This could be enabled by having sizeof and friends formally take an
>> Any.Type instead of  T.Type. (This might need some tweaking of the
>> underlying builtins to be able to open existential metatypes, but it
>> seems implementable.)
> 
> Would it be as fully specializable down to a compile-time constant?

Seems like it ought to be. sizeof() is just a transparent wrapper around 
Builtin.sizeof IIRC, and we can control the codegen of the builtin.

-Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Joe Groff 
 wrote:

> Regarding the issue of existential metatypes with sizeof:
>
> Pyry Jahkola points out one instance where the memorySize(type(of: …))
> workaround won't work. When the value is an existential, it's illegal
> to ask for the size of its dynamic type: the result can't be retrieved
> at compile time:
>
> // Swift 2.2, 64-bit
> let i = 123
> print(sizeofValue(i)) //=> 8
> let c: CustomStringConvertible = i
> print(sizeofValue(c)) //=> 40
> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
> argument list of type '(CustomStringCo
> This could be enabled by having sizeof and friends formally take an
> Any.Type instead of  T.Type. (This might need some tweaking of the
> underlying builtins to be able to open existential metatypes, but it
> seems implementable.)

Would it be as fully specializable down to a compile-time constant?

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 2:36 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jun 21 2016, Erica Sadun > > wrote:
>> 
>
 On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution
  wrote:
 This could be enabled by having sizeof and friends formally take an
 Any.Type instead of  T.Type. (This might need some tweaking of
 the underlying builtins to be able to open existential metatypes,
 but it seems implementable.)
>>> 
>>> While I'm not a huge fan of Dave A's generic struct approach (for
>>> reasons detailed in the proposal), 
>> 
>> Some of the examples used to justify avoiding that approach look
>> wrong or overly complicated to me.  Am I missing something?
>> 
>>let errnoSize = MemoryLayout.init(t: errno).size
>> 
>>_class_getInstancePositiveExtentSize(bufferClass) ==
>>MemoryLayout<_HeapObject.self>.size
>> 
>> wouldn't that be:
>> 
>>let errnoSize = MemoryLayout(errno).size
>> 
>>_class_getInstancePositiveExtentSize(bufferClass) == 
>>MemoryLayout<_HeapObject>.size
>> 
>> ? 
>> 
>> Once you fix those issues, I don't find my proposal to hurt
>> readability at all.  One has to put those examples into their actual
>> contexts rather than packing them all next to one another, to evaluate
>> it fairly.
>> 
>> Finally, I still object to doubling the API surface area just so you can
>> pass values instead of types to these functions.  Having three global
>> functions is acceptable, but six is too many, and arguably, having a
>> single type would be better.
>
> * I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
>   Only qualification was that I was looking for examples of sizeof.

I understand that, but I don't see how it's relevant.  My point was that
these don't appear in code stacked one on top of another like that.

> * In regard to offering both of and ofValue, I agree: I'd rather offer
> half the surface area, especially since Joe says the main issue is
> technically avoidable.
>
> * I don't like having to scan past the MemoryLayout and the type in question 
> to
> get to the member name that defines what property is requested. You have to 
> read it back
> to front. I find that to be a human factors limitation that makes it
> less desirable to use.

The “type in question” is very much relevant, just as in
`customers.count`, `customers` is relevant.  

If I didn't think it would produce semantic confusion, these would be
static members e.g. `Array.memoryAlignment`, and you'd have to “scan
past” `Array`.  It's a perfectly natural way to express a property of a
type.

> * At the same time, what I do like about the struct is that it's
> extensible without introducing standalone functions (and shrinks the
> number of functions that exist in the stdlib), and that the properties
> express intrinsic characteristics of the memory layout of a given
> type. The functions are measure-y. The properties are
> characteristic-y.

It even directly supports the -Value variants without expanding the
global API surface area, per

   MemoryLayout(errno).size

however, I don't think this is a good idea because of the potential for
confusion in cases like this:

   MemoryLayout(Int.self).size

-- 
Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 2:36 PM, Dave Abrahams  wrote:
> 
> 
> on Tue Jun 21 2016, Erica Sadun  > wrote:
> 
>>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> This could be enabled by having sizeof and friends formally take an
>>> Any.Type instead of  T.Type. (This might need some tweaking of
>>> the underlying builtins to be able to open existential metatypes,
>>> but it seems implementable.)
>> 
>> While I'm not a huge fan of Dave A's generic struct approach (for
>> reasons detailed in the proposal), 
> 
> Some of the examples used to justify avoiding that approach look
> wrong or overly complicated to me.  Am I missing something?
> 
>let errnoSize = MemoryLayout.init(t: errno).size
> 
>_class_getInstancePositiveExtentSize(bufferClass) ==
>MemoryLayout<_HeapObject.self>.size
> 
> wouldn't that be:
> 
>let errnoSize = MemoryLayout(errno).size
> 
>_class_getInstancePositiveExtentSize(bufferClass) == 
>MemoryLayout<_HeapObject>.size
> 
> ? 
> 
> Once you fix those issues, I don't find my proposal to hurt
> readability at all.  One has to put those examples into their actual
> contexts rather than packing them all next to one another, to evaluate
> it fairly.
> 
> Finally, I still object to doubling the API surface area just so you can
> pass values instead of types to these functions.  Having three global
> functions is acceptable, but six is too many, and arguably, having a
> single type would be better.

* I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
Only qualification was that I was looking for examples of sizeof.

* In regard to offering both of and ofValue, I agree: I'd rather offer half the 
surface area,
especially since Joe says the main issue is technically avoidable.

* I don't like having to scan past the MemoryLayout and the type in question to
get to the member name that defines what property is requested. You have to 
read it back
to front. I find that to be a human factors limitation that makes it less 
desirable to use.

* At the same time, what I do like about the struct is that it's extensible 
without introducing
standalone functions (and shrinks the number of functions that exist in the 
stdlib), and that 
the properties express intrinsic characteristics of the memory layout of a 
given type. The
functions are measure-y. The properties are characteristic-y.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Regarding the issue of existential metatypes with sizeof:
>> 
>> Pyry Jahkola points out one instance where the memorySize(type(of:
>
>> …)) workaround won't work. When the value is an existential, it's
>> illegal to ask for the size of its dynamic type: the result can't be
>> retrieved at compile time:
>> 
>> let i = 123
>> let c: CustomStringConvertible = i
>> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
>> argument list of type '(CustomStringCo
>> This could be enabled by having sizeof and friends formally take an
>> Any.Type instead of  T.Type. (This might need some tweaking of
>> the underlying builtins to be able to open existential metatypes,
>> but it seems implementable.)
>
> While I'm not a huge fan of Dave A's generic struct approach (for
> reasons detailed in the proposal), 

Some of the examples used to justify avoiding that approach look
wrong or overly complicated to me.  Am I missing something?

let errnoSize = MemoryLayout.init(t: errno).size

_class_getInstancePositiveExtentSize(bufferClass) ==
MemoryLayout<_HeapObject.self>.size

wouldn't that be:

let errnoSize = MemoryLayout(errno).size

_class_getInstancePositiveExtentSize(bufferClass) == 
MemoryLayout<_HeapObject>.size

? 

Once you fix those issues, I don't find my proposal to hurt
readability at all.  One has to put those examples into their actual
contexts rather than packing them all next to one another, to evaluate
it fairly.

Finally, I still object to doubling the API surface area just so you can
pass values instead of types to these functions.  Having three global
functions is acceptable, but six is too many, and arguably, having a
single type would be better.

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Regarding the issue of existential metatypes with sizeof:
> 
> Pyry Jahkola points out one instance where the memorySize(type(of: …)) 
> workaround won't work. When the value is an existential, it's illegal to ask 
> for the size of its dynamic type: the result can't be retrieved at compile 
> time:
> 
> let i = 123
> let c: CustomStringConvertible = i
> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
> argument list of type '(CustomStringCo
> This could be enabled by having sizeof and friends formally take an Any.Type 
> instead of  T.Type. (This might need some tweaking of the underlying 
> builtins to be able to open existential metatypes, but it seems 
> implementable.)

While I'm not a huge fan of Dave A's generic struct approach (for reasons 
detailed in the proposal), this could resolve one major issue I currently have 
with his alternative.

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

On 21 June 2016 at 14:03, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The review of "SE-0101: Rename sizeof and related functions to comply with 
> API Guidelines" begins now and runs through June 27. The proposal is 
> available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
>
> * What is your evaluation of the proposal?

After a carefull review of the proposal, I will be obligated to
decline it. After studying the proposal I ended up thinking I was
writing more code to get the data and in comparison with dynamicType
-> type(of:) it lead me to think at first the proposal would suggest
renaming size* functions to size(of*:) and so forth, which would seem
to go more towards the compared proposal (SE-0096). This idea doesn't
even made into the alternatives considered and I think it would making
reading and understanding the code much clearer than the proposed
nested function calls.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

I'm not sure. Given the reasoning I'd say yes but given proposal
SE-0096 I'd say yes only if the new function names were to be
size(of*:), stride(of*:) and align(of*:) and thus not depending of the
nested result of type(of*:).

> * Does this proposal fit well with the feel and direction of Swift?

I don't think so. As I said, when I finished reading the proposal, I
ended up thinking I was writing more code in the new version and it
didn't seem very clear to me what was the size I was getting.
Moreover, it seems I'll always have to invoke these functions to the
result of type(of*:) which would be unnecessary redundant code.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Many languages (like C/C++, C#, D) have both sizeof and typeof and in
most these two functions have similar names and syntaxes. In this case
I believe making them different makes it hard to discover those
functions exist and relate their purpose.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick study was enough for me.

L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution