Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Charlie Monroe via swift-evolution]

This is a good point. This should, perhaps, be address using #if arch(x86_64), 
but you are right that many systems have some system typedefs defined otherwise 
even on the same architecture, which may be painful to deal with.

> Is there any need to consider the following common C sizeof() usage, which is 
> currently illegal in Swift?
> 
> #if sizeof(MyType) != sizeof(Int)
> # error "Someone added too much data to MyType"
> #endif
> 
> It is not that I like fancy conditional compile, but having such compile time 
> assertion is useful; at least in my day-time low-level C world. Most of the 
> discussion seem to have been around sizeof() being more of a runtime function 
> than a compiler directive; which would preclude being able to do compile time 
> assertion to validate type size.
> 
> Dany
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Jose Cheyo Jimenez via swift-evolution]

+1 on #3
3. MemoryLayout.size

http://i.gifntext.com/29412-number-3-my-lord.gif 


> On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Jun 06 2016, Nate Cook  wrote:
> 
>> I'd like to cast another vote in favor of something like the
>> MemoryLayout struct. In general, people aren't always making the right
>> choice about which of these values to use. Combining them into one
>> data type would mean they see that there are three related values and
>> can find out when to use which easily.
>> 
>> Would MemoryLayout need to be generic? Accessing a static property on
>> a generic type doesn't seem as straightforward as a function call or
>> the properties of a struct. I think I'd prefer something closer to the
>> way Mirror works, but really, I defer to those with stronger
>> convictions / actual reasons:
>> 
>> func type(of value: T) -> T.Type {
>>return T.self
>> }
>> 
>> struct MemoryLayout {
>>let size: Int
>>let stride: Int
>>let alignment: Int
>> 
>>init(of type: T.Type) {
> 
> I see no need for an argument label here.
> 
>>size = sizeof(type)
>>stride = strideof(type)
>>alignment = alignof(type)
>>}
>> }
> 
> These are all possible syntaxes, but I think #3 is best:
> 
> 1. MemoryLayout(Int.self).size
> 2. memoryLayout(Int.self).size
> 3. MemoryLayout.size
> 
> I don't see any advantage of #1 over #2, and there's no need at all to
> define a new nominal type if we only want #2:
> 
> func memoryLayout(_ T.type) -> (size: Int, stride: Int, alignment: Int) {
>// implementation
> }
> 
>> Nate
>> 
>>> On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Thu Jun 02 2016, John McCall >> > wrote:
>>> 
 On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
 
 On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
 
 wrote:
 
 I still think the value-based APIs are misleading and that it would be 
 better to ask people to just use a type explicitly.
 
 John.
 
 I agree; in fact why aren’t these properties on the type itself? The type 
 is what matters; why can’t the type just tell me it’s size? 
 Having free functions or magic operators seems to be another holdover from 
 C. 
 
 Int.size
 Int.alignment
 Int.spacing
 
 let x: Any = 5
 type(of: x).size
 
 The compiler should be able to statically know the first three values and 
 inline them. The second is discovering the size dynamically.
 
 Two reasons. The first is that this is a user-extensible namespace via
 static members, so it's somewhat unfortunate to pollute it with names
 from the library. The second is that there's currently no language
 mechanism for adding a static member to every type, so this would have
 to be built-in. 
>>> 
>>> More fundamental reasons:
>>> 
>>> 
>>> * `Array.size` is easily misinterpreted.  The identifier
>>> `MemoryLayout` was suggested in order to set the proper mental context
>>> at the use site.
>>> 
>>> * I don't want “size,” “alignment,” and “spacing” appearing in the
>>> code-completion list for every type.  
>>> 
>>> * I can easily imagine users wanting to use static properties by these
>>> names for their own types, with completely different meaning.
>>> 
 But I agree that in the abstract a static property would be
 preferable.
 
 John.
 
 ___
 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 
>>> 
> 
> -- 
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dany St-Amant via swift-evolution]

> Le 3 juin 2016 à 17:11, Erica Sadun via swift-evolution 
>  a écrit :
> 
> Discussion has more or less drawn down. Are there any further significant 
> requests / issues that need addressing? Both standalone functions (my 
> recommended approach)  and the MemoryLayout struct approach (alternative, 
> with reasons why I think it's not as ideal) are discussed in-proposal.
> 
> Pull Request: https://github.com/apple/swift-evolution/pull/350

Is there any need to consider the following common C sizeof() usage, which is 
currently illegal in Swift?

#if sizeof(MyType) != sizeof(Int)
# error "Someone added too much data to MyType"
#endif

It is not that I like fancy conditional compile, but having such compile time 
assertion is useful; at least in my day-time low-level C world. Most of the 
discussion seem to have been around sizeof() being more of a runtime function 
than a compiler directive; which would preclude being able to do compile time 
assertion to validate type size.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dave Abrahams via swift-evolution]

on Mon Jun 06 2016, Nate Cook  wrote:

> I'd like to cast another vote in favor of something like the
> MemoryLayout struct. In general, people aren't always making the right
> choice about which of these values to use. Combining them into one
> data type would mean they see that there are three related values and
> can find out when to use which easily.
>
> Would MemoryLayout need to be generic? Accessing a static property on
> a generic type doesn't seem as straightforward as a function call or
> the properties of a struct. I think I'd prefer something closer to the
> way Mirror works, but really, I defer to those with stronger
> convictions / actual reasons:
>
> func type(of value: T) -> T.Type {
> return T.self
> }
>
> struct MemoryLayout {
> let size: Int
> let stride: Int
> let alignment: Int
>
> init(of type: T.Type) {

I see no need for an argument label here.

> size = sizeof(type)
> stride = strideof(type)
> alignment = alignof(type)
> }
> }

These are all possible syntaxes, but I think #3 is best:

1. MemoryLayout(Int.self).size
2. memoryLayout(Int.self).size
3. MemoryLayout.size

I don't see any advantage of #1 over #2, and there's no need at all to
define a new nominal type if we only want #2:

 func memoryLayout(_ T.type) -> (size: Int, stride: Int, alignment: Int) {
// implementation
 }

> Nate
>
>> On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Thu Jun 02 2016, John McCall > > wrote:
>> 
>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>>> 
>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>>> 
>>> wrote:
>>> 
>>> I still think the value-based APIs are misleading and that it would be 
>>> better to ask people to just use a type explicitly.
>>> 
>>> John.
>>> 
>>> I agree; in fact why aren’t these properties on the type itself? The type 
>>> is what matters; why can’t the type just tell me it’s size? 
>>> Having free functions or magic operators seems to be another holdover from 
>>> C. 
>>> 
>>> Int.size
>>> Int.alignment
>>> Int.spacing
>>> 
>>> let x: Any = 5
>>> type(of: x).size
>>> 
>>> The compiler should be able to statically know the first three values and 
>>> inline them. The second is discovering the size dynamically.
>>> 
>>> Two reasons. The first is that this is a user-extensible namespace via
>>> static members, so it's somewhat unfortunate to pollute it with names
>>> from the library. The second is that there's currently no language
>>> mechanism for adding a static member to every type, so this would have
>>> to be built-in. 
>> 
>> More fundamental reasons:
>> 
>> 
>> * `Array.size` is easily misinterpreted.  The identifier
>>  `MemoryLayout` was suggested in order to set the proper mental context
>>  at the use site.
>> 
>> * I don't want “size,” “alignment,” and “spacing” appearing in the
>>  code-completion list for every type.  
>> 
>> * I can easily imagine users wanting to use static properties by these
>>  names for their own types, with completely different meaning.
>> 
>>> But I agree that in the abstract a static property would be
>>> preferable.
>>> 
>>> John.
>>> 
>>> ___
>>> 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 
>> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Nate Cook via swift-evolution]

I'd like to cast another vote in favor of something like the MemoryLayout 
struct. In general, people aren't always making the right choice about which of 
these values to use. Combining them into one data type would mean they see that 
there are three related values and can find out when to use which easily.

Would MemoryLayout need to be generic? Accessing a static property on a generic 
type doesn't seem as straightforward as a function call or the properties of a 
struct. I think I'd prefer something closer to the way Mirror works, but 
really, I defer to those with stronger convictions / actual reasons:

func type(of value: T) -> T.Type {
return T.self
}

struct MemoryLayout {
let size: Int
let stride: Int
let alignment: Int

init(of type: T.Type) {
size = sizeof(type)
stride = strideof(type)
alignment = alignof(type)
}
}
Nate

> On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Thu Jun 02 2016, John McCall  > wrote:
> 
>> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>> 
>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>> 
>> wrote:
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
>> 
>> John.
>> 
>> I agree; in fact why aren’t these properties on the type itself? The type is 
>> what matters; why can’t the type just tell me it’s size? 
>> Having free functions or magic operators seems to be another holdover from 
>> C. 
>> 
>> Int.size
>> Int.alignment
>> Int.spacing
>> 
>> let x: Any = 5
>> type(of: x).size
>> 
>> The compiler should be able to statically know the first three values and 
>> inline them. The second is discovering the size dynamically.
>> 
>> Two reasons. The first is that this is a user-extensible namespace via
>> static members, so it's somewhat unfortunate to pollute it with names
>> from the library. The second is that there's currently no language
>> mechanism for adding a static member to every type, so this would have
>> to be built-in. 
> 
> More fundamental reasons:
> 
> 
> * `Array.size` is easily misinterpreted.  The identifier
>  `MemoryLayout` was suggested in order to set the proper mental context
>  at the use site.
> 
> * I don't want “size,” “alignment,” and “spacing” appearing in the
>  code-completion list for every type.  
> 
> * I can easily imagine users wanting to use static properties by these
>  names for their own types, with completely different meaning.
> 
>> But I agree that in the abstract a static property would be
>> preferable.
>> 
>> John.
>> 
>> ___
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dave Abrahams via swift-evolution]

on Thu Jun 02 2016, John McCall  wrote:

>  On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>
>  On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
> 
>  wrote:
>
>  I still think the value-based APIs are misleading and that it would be 
> better to ask people to just use a type explicitly.
>
>  John.
>
>  I agree; in fact why aren’t these properties on the type itself? The type is 
> what matters; why can’t the type just tell me it’s size? 
>  Having free functions or magic operators seems to be another holdover from 
> C. 
>
>  Int.size
>  Int.alignment
>  Int.spacing
>
>  let x: Any = 5
>  type(of: x).size
>
>  The compiler should be able to statically know the first three values and 
> inline them. The second is discovering the size dynamically.
>
> Two reasons. The first is that this is a user-extensible namespace via
> static members, so it's somewhat unfortunate to pollute it with names
> from the library. The second is that there's currently no language
> mechanism for adding a static member to every type, so this would have
> to be built-in. 

More fundamental reasons:


* `Array.size` is easily misinterpreted.  The identifier
  `MemoryLayout` was suggested in order to set the proper mental context
  at the use site.

* I don't want “size,” “alignment,” and “spacing” appearing in the
  code-completion list for every type.  

* I can easily imagine users wanting to use static properties by these
  names for their own types, with completely different meaning.

> But I agree that in the abstract a static property would be
> preferable.
>
> John.
>
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dave Abrahams via swift-evolution]

on Thu Jun 02 2016, John McCall  wrote:

>  On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
> 
>  wrote:
>
>  On Jun 2, 2016, at 10:38 AM, Xiaodi Wu  wrote:
>
>  Well, as I understand it, it's not actually possible to write your own 
> type(of:), so we're going from a "magic" property to a "magic"
>  function at least for now.
>
>  No, but you *can* write `func foo(_ t: T)` which accepts any value (you 
> *cannot* write a property that is available for all properties -
>  that would require the ability to write `extension Any`. This is the 
> distinction I am making. Of course the implementation is compiler
>  magic no matter how we express it syntactically. But we can make it *appear* 
> just like it might if the implementation *wasn’t* compiler
>  magic. That makes it fit into the language better IMO and was the biggest 
> motivator for changing `dynamicType`.
>
>  I'm most alarmed that one implication of the MemoryLayout proposal is loss 
> of the `ofValue` family of functions. These functions
>  don't fit with the design: imagine, what is 
> `MemoryLayout.size(ofValue: Float(42))`? But the response seems to be 
> that
>  these functions don't seem necessary at all and should be removed. "I don't 
> see a use for it" is an insufficient justification for a
>  feature removal. Looking to other languages, C# has sizeof as a static 
> property but tellingly offers the equivalent of sizeofValue
>  (well, strideofValue) as a function in a different module. Essentially every 
> other C-family language that exposes pointers to the
>  user offers both of and ofValue equivalents. The question is, how does a 
> user with existing code using sizeofValue() migrate to
>  Swift 3? I do not see a viable answer with the MemoryLayout design.
>
>  Going with MemoryLayout *does not* mean we would have to give up the value 
> functions if we don’t want to:
>
>  struct MemoryLayout {
>  init() {}
>  init(t: T) { /* throw away the value */ }
>  // we could omit the static properties and require 
>  // writing MemoryLayout() if we don’t like the duplication
>  static let size: Int
>  static let spacing: Int
>  static let alignment: Int
>
>  let size: Int
>  let spacing: Int
>  let alignment: Int
>  }
>
>  let size = MemoryLayout.size
>  let sizeOfValue = MemoryLayout(42).size
>
> There's no good reason for this type to be generic. 

I can think of at least two: improved syntax at the use-site and lower
API surface area.  But I'm comparing a design I had in my mind for
MemoryLayout with the only other alternative I've thought of.  Maybe
you'd care offer an alternative design.

> It should be non-generic and require the use of the instance
> properties.

Instance properties?  Why should we ever create an instance of this
thing?

> It's actively harmful for this type to appear to be computed from a
> value. 

I agree.

> The layout is not in any way tied to the dynamic type of the value —
> for example, it is not the instance layout of the most-derived class
> or the value layout of the dynamic type of an
> existential. Furthermore, saying that it is computed from a value
> means that attempting to compute it from a type will succeed using the
> layout of the metatype, which seems like a catastrophic failure of API
> design.
>
> John.
>
>  On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson  
> wrote:
>
>  Sent from my iPad
>
>  On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
>  wrote:
>
>  On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  wrote:
>
>  I really like this idea. This IMO is lower level functionality than 
> `type(of:)` (née dynamicType), so I think it makes
>  sense for it to be grouped under its own domain, the MemoryLayout type.
>
>  Plus MemoryLayout can be extended with new convenience methods.
>
>  I’m fine with those old methods being removed, but I never use them so! Is 
> it the same as calling type(of:) then
>  using that with MemoryLayout? I imagine they could be fixit’d easily, and 
> that they compile down to the same
>  underlying code.
>
>  I'm actually souring to the idea. It goes in the diametrically opposite 
> direction from dynamicType. There, something
>  was changed from being property-like to being function-like. Here, Dave's 
> proposal would take something that's a
>  function and turn it into a property. Hmm.
>
>  That's not a fair comparison though. With dynamicType we removed a "magic" 
> property visible on all types, which isn't
>  something you can write and turned it into a function (which is obviously 
> something you can write). 
>
>  Dave's MemoryLayout creates a new type to bundle together related items 
> which makes their semantic relationship more
>  clear. It also receives the type via a generic argument rather than a 
> function argument and makes the properties static. That
>  is more representative of what 

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dave Abrahams via swift-evolution]

on Thu Jun 02 2016, Matthew Johnson  wrote:

>  On Jun 2, 2016, at 10:03 AM, Xiaodi Wu  wrote:
>
>  That proposal was returned for revision; as far as user ergonomics in Swift 
> 3, .self is going to be a consideration. Best to find a solution
>  that reads nicely regardless of the situation with .self removal.
>
> From the core team decision:
>
> "The core team would definitely like to circle back to this proposal after 
> Swift 3 is out the door."
>
> I think we should consider the best long-term design. 

Yes.  While it is true that disturbing the language as little as
possible helps ensure acceptance, a proposal that makes incremental
steps when the best solution is already acheivable is at a great
disadvantage, as it creates needless churn for users.

> If that happens to be dropping labels great, but if not, maybe we
> don’t want to do that just because it will look better in Swift 3 at
> the cost of a better design when “.self” is not required.
>
> Dave’s MemoryLayout approach avoids the question of labels entirely. This is 
> another subtle nudge in that direction IMO.
>
>  On Thu, Jun 2, 2016 at 9:57 AM Matthew Johnson  
> wrote:
>
>  On Jun 2, 2016, at 9:43 AM, Erica Sadun  wrote:
>
>  Supporting Dave A, type-based calls are much more likely to be used than 
> instance calls, unlike with dynamicType/type(of:)
>
>  Term stdlib search gist search Google site:github +swift 
>  sizeof 157 169 4880 
>  sizeofValue 4 34 584 
>  alignof 44 11 334 
>  alignofValue 5 5 154 
>  strideof 347 19 347 
>  strideofValue 4 5 163 
>  Type-based calls like sizeof() are poor candidates for parameter labels. 
> While it's acceptable to write sizeof(Int), but one
>  must write size(of: Int.self) (with the trailing self) when the function has 
> a label. 
>
>  Isn’t this a short-term concern? I thought that requirement was going away.
>
>  For this reason, this proposal prefers using no-label calls for types 
> (otherwise they would have been ofType) and labeled
>  calls for values:
>
> print(sizeof(Int)) // works
> print(sizeof(Int.self)) // works
>
> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
>
> // Works
> print(withoutLabel(Int))
>
> // Works
> print(withLabel(label: Int.self))
>
> // Does not work
> // error: cannot create a single-element tuple with an element label
> // print(withLabel(label: Int)) 
>
>  So with this in mind:
>
> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(_: T.Type) -> Int
>
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(of: T) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(_: T.Type) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(_: T.Type) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(of: T) -> Int
>  -- E
>
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Dave Abrahams via swift-evolution]

on Thu Jun 02 2016, Matthew Johnson  wrote:

>  On Jun 2, 2016, at 10:01 AM, Charlie Monroe  
> wrote:
>
>  Isn’t this a short-term concern? I thought that requirement was going away.
>
>  AFAIK there are still concerns about ambiguity - [Int] - is it an array with 
> one element (Int.self), or is it [Int].self?
>
> IIRC Joe Groff was going to work on sorting out the remaining issues
> but the plan is to move ahead eventually.

FWIW, there is no such plan.  A number of us would like to see something
happen in this area, but we are waiting to see the results of Joe's
work.

>
>  For this reason, this proposal prefers using no-label calls for types 
> (otherwise they would have been ofType) and labeled calls for
>  values:
>
> print(sizeof(Int)) // works
> print(sizeof(Int.self)) // works
>
> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
>
> // Works
> print(withoutLabel(Int))
>
> // Works
> print(withLabel(label: Int.self))
>
> // Does not work
> // error: cannot create a single-element tuple with an element label
> // print(withLabel(label: Int)) 
>
>  So with this in mind:
>
> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(_: T.Type) -> Int
>
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(of: T) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(_: T.Type) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(_: T.Type) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(of: T) -> Int
>  -- 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
>

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Pyry Jahkola via swift-evolution]

> On 04 Jun 2016, Erica Sadun wrote:
> 
> Discussion has more or less drawn down. Are there any further significant 
> requests / issues that need addressing? Both standalone functions (my 
> recommended approach)  and the MemoryLayout struct approach (alternative, 
> with reasons why I think it's not as ideal) are discussed in-proposal.
> 
> Pull Request: https://github.com/apple/swift-evolution/pull/350

Good proposal, Erica!

Regardless of the little input I've given to this discussion, I actually prefer 
the set of `memory*` prefixed top-level functions to a `MemoryLayout` struct or 
tuple.

However, I think it's most common to call these functions with a type argument, 
and we should thus stick to the practice of keeping that use case short, and 
the call-with-value case explicit. In particular, I'd avoid the label for a 
type argument, and say `ofValue:` when passing a value:

memorySize(ofType:)  → memorySize(_:)
memorySize(of:)  → memorySize(ofValue:)
memoryInterval(ofType:)  → memoryInterval(_:)
memoryInterval(of:)  → memoryInterval(ofValue:)
memoryAlignment(ofType:) → memoryAlignment(_:)
memoryAlignment(of:) → memoryAlignment(ofValue:)

Secondly, (this might be over-engineering but) would it still make sense to use 
`@autoclosure` in the `ofValue:` functions because they don't really need their 
arguments evaluated?

public func memorySize(ofValue _: @autoclosure T -> ()) -> Int
public func memoryInterval(ofValue _: @autoclosure T -> ()) -> Int
public func memoryAlignment(ofValue _: @autoclosure T -> ()) -> Int

— Pyry, whose name gets autocoerced in various ways apparently.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Sean Heber via swift-evolution]

There was also my suggestion for a function such as memoryLayout(of:) that 
returned an instance of a simple MemoryLayout struct which I believe is a bit 
different than the MemoryLayout generics approach. I’m not sure if that was 
expressly shot down or ruled out or not, though.

l8r
Sean


> On Jun 3, 2016, at 4:11 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Discussion has more or less drawn down. Are there any further significant 
> requests / issues that need addressing? Both standalone functions (my 
> recommended approach)  and the MemoryLayout struct approach (alternative, 
> with reasons why I think it's not as ideal) are discussed in-proposal.
> 
> Pull Request: https://github.com/apple/swift-evolution/pull/350
> 
> Thanks, -- Erica
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[David Sweeris via swift-evolution]

In defense of MemoryLayout's "less clarity", the people who know enough to 
use that stuff won't have trouble understanding it.

That said, while I like it, I'm mostly interested in sequestering this stuff 
away in a type as a step towards a some sort of vague macro system. Since 
that's obviously out of scope for, well, everything, I'm +1 regardless.

- Dave Sweeris



> On Jun 3, 2016, at 16:11, Erica Sadun via swift-evolution 
>  wrote:
> 
> Discussion has more or less drawn down. Are there any further significant 
> requests / issues that need addressing? Both standalone functions (my 
> recommended approach)  and the MemoryLayout struct approach (alternative, 
> with reasons why I think it's not as ideal) are discussed in-proposal.
> 
> Pull Request: https://github.com/apple/swift-evolution/pull/350
> 
> Thanks, -- Erica
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

Discussion has more or less drawn down. Are there any further significant 
requests / issues that need addressing? Both standalone functions (my 
recommended approach)  and the MemoryLayout struct approach (alternative, 
with reasons why I think it's not as ideal) are discussed in-proposal.

Pull Request: https://github.com/apple/swift-evolution/pull/350

Thanks, -- Erica

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Jun 3, 2016, at 7:08 AM, Brent Royal-Gordon  wrote:

>> This might be silly, but what if there were a struct with all of the 
>> relevant fields (not sure what the best name would be):
>> 
>> struct MemoryLayout {
>> let size: Int
>> let alignment: Int
>> let stride: Int
>> // etc
>> }
>> 
>> Then you’d only maybe need two functions:
>> 
>> memoryLayout(of:) and memoryLayout(ofType:)
> 
> Could the `memoryLayout` functions just return `(size: Int, alignment: Int, 
> spacing: Int)` tuples? It's hard to tell because it goes into Builtin land, 
> but I get the impression that these values are calculated at compile time 
> anyway, and if you only used one of them the optimizer could throw the others 
> away.

What would be the advantage of this over returning a value of a MemoryLayout 
type?  Obviously tuples can be destructured, but I can't think of any others.  
I would like to see struct destructuring someday.  I'm not sure destructuring 
is a strong enough argument to go with a tuple here.  If there is a good reason 
to have a MemoryLayout type we shouldn't drop it just for destructuring, which 
may eventually be possible anyway (I hope anyway).

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Brent Royal-Gordon via swift-evolution]

> This might be silly, but what if there were a struct with all of the relevant 
> fields (not sure what the best name would be):
> 
> struct MemoryLayout {
>  let size: Int
>  let alignment: Int
>  let stride: Int
> // etc
> }
> 
> Then you’d only maybe need two functions:
> 
> memoryLayout(of:) and memoryLayout(ofType:)

Could the `memoryLayout` functions just return `(size: Int, alignment: Int, 
spacing: Int)` tuples? It's hard to tell because it goes into Builtin land, but 
I get the impression that these values are calculated at compile time anyway, 
and if you only used one of them the optimizer could throw the others away.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[David Sweeris via swift-evolution]

On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution 
> wrote:

> This might be silly, but what if there were a struct with all of the relevant 
> fields (not sure what the best name would be):
> 
> struct MemoryLayout {
>  let size: Int
>  let alignment: Int
>  let stride: Int
> // etc
> }
> 
> Then you’d only maybe need two functions:
> 
> memoryLayout(of:) and memoryLayout(ofType:)
> 
> Or perhaps just a single property on all types named “memoryLayout” (or 
> whatever) that returns the MemoryLayout struct:
> 
> Int.memory.size
> type(of: 42).memoryLayout.size
> // etc
> 
> Or just a single property on UnsafePointer if we went that route..
> 
> It seems like this sort of approach would keep namespace pollution down, at 
> least?
I was about to suggest the something very much like that.

In addition to reducing namespace "pollution", I like that it kinda moves 
implementation and target-level details into their own little "type 
terrarium"... I might suggest renaming "MemoryLayout" to something like 
"ImplementationDetails". The latter seems more to-the-point, but, aside from 
endianness, I'm not sure if any such details wouldn't fall under the umbrella 
of "memory layout" anyway.

Hmm… If all the details of a type’s memory layout can be represented in this 
“MemoryLayout" type, could we use it to manually construct a type "in-code" 
instead of going through the compiler? I’m not sure it works "that way”… Nor am 
I sure what the point would be, but it might be handy if you have clever idea 
that the compiler can’t understand.

I clearly shouldn’t be up this early.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 4:57 PM, Sean Heber  wrote:
> 
> This might be silly, but what if there were a struct with all of the relevant 
> fields (not sure what the best name would be):
> 
> struct MemoryLayout {
>  let size: Int
>  let alignment: Int
>  let stride: Int
> // etc
> }
> 
> Then you’d only maybe need two functions:
> 
> memoryLayout(of:) and memoryLayout(ofType:)

I like this much better than individual functions.  I do not like the next idea 
that considers using a property.  We moved away from that approach with 
dynamicType and should stick with that direction.  It's not worth bringing up 
that debate again IMO.

> 
> Or perhaps just a single property on all types named “memoryLayout” (or 
> whatever) that returns the MemoryLayout struct:
> 
> Int.memory.size
> type(of: 42).memoryLayout.size
> // etc
> 
> Or just a single property on UnsafePointer if we went that route..
> 
> It seems like this sort of approach would keep namespace pollution down, at 
> least?
> 
> l8r
> Sean
> 
> 
>>> On Jun 2, 2016, at 4:55 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> I don't disagree with the points you make.  But one can argue that this is 
>>> a good thing.  It calls attention to code that requires extra attention and 
>>> care.  In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  
>>> Verbosity was a deliberate choice in that case.
>> 
>> You know...rather than introducing a new type like MemoryLayout, would it 
>> make sense to do this with static properties on UnsafePointer?
>> 
>>UnsafePointer.pointeeSize
>>UnsafePointer.pointeeAlignment
>>UnsafePointer.pointeeSpacing
>> 
>> If you need this information, 90% of the time you're probably using 
>> UnsafePointer or one of its friends, right?
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Isn't this the same argument for .dynamicType over type(of:) though?
> 
> Given that that debate has been settled in favor of the latter, I think the 
> question today is how best to come up with a consistent scheme.
> 
> Earlier in this conversation, it was pointed out (by Matt, I think?) that one 
> key advantage of type(of:) is that it takes on a syntax that is actually 
> possible to write in Swift, since one cannot extend Any.

Yep, IMO we should stick with the strategy that if something *looks* like a 
user-definable construct it should be possible to at least write the 
declaration even if it wouldn't be possible to implement.  That rules out 
static or instance properties or methods that apply to all types.

> 
> If we take this principle to its logical conclusion, properties (of a type or 
> instance) which apply to Any should be global functions.
> 
>> On Thu, Jun 2, 2016 at 16:26 Russ Bishop  wrote:
>> 
>>> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> In the earlier conversation, it was pointed out (by Dave A., I think?) that 
>>> examples such as Array.size show how this solution can get confusing. And 
>>> even though there aren't fixed-length arrays in Swift, those may come one 
>>> day, making the syntax even more confusing.
>> 
>> 
>> Array.count is a function taking an instance; I’m not sure I agree it would 
>> be terribly confusing… then again I run in Xcode with the quick help pane 
>> open so I see the doc comments for every type, property, and function as I 
>> move around the code. It’s quite handy :)
>> 
>> I could see including memory in the name (or something similar) if we want 
>> to be extra clear about it.
>> 
>> Int.memorySize
>> Int.memoryAlignment
>> 
>> 
>> Ultimately the type’s size in memory is a property of the type so it seems 
>> clear that is where it belongs (being careful not to steal too much of the 
>> namespace of course).
>> 
>> 
>> Russ
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

As I said above, I disagree. Unsafe things should have names that call
attention to themselves. Safe things should not, *especially* if they're
unsafe-adjacent. It's not useful in a line of code to have every part of it
competing for your attention merely because they're typically used in
conjunction with an unsafe operation. It's essential that the unsafe
operation itself stand out.

Ever see a doctor clicking their mouse faster than a video gamer to dismiss
20 warnings in a row on a computer screen? That's what happens when
everything unsafe-adjacent calls attention to itself.
On Thu, Jun 2, 2016 at 19:53 Matthew Johnson  wrote:

>
>
> Sent from my iPad
>
> On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On the other hand, on its own sizeof() is not unsafe, and so the argument
> that it should be longer to call attention to itself (by analogy with
> UnsafePointer) isn't quite apt.
>
>
> These operations aren't themselves unsafe.  But they are low level details
> that are not useful unless you are doing something that requires special
> care.  A name that stands out more calls attention to the surrounding
> code.  That is a good thing IMO.
>
>
> And I'm not sure we really want to encourage anyone else to be defining a
> global function named size(of:) anyway, so I wouldn't consider vacating
> that name for end-user purposes to be a meaningful positive.
> On Thu, Jun 2, 2016 at 16:15 Tony Allevato  wrote:
>
>> Given that these are fairly low-level values with very specialized uses,
>> I definitely agree that they should be somehow namespaced in a way that
>> doesn't cause us to make very common words unusable for our users.
>>
>> Even size(of:) seems more general to me than I'd like. I'd like to see
>> the word "memory" as part of the name somehow, whether it's a wrapping type
>> or a function prefix of some sort. These values are specialized; we don't
>> need to optimize typing them, IMO.
>>
>> On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:

 On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
 swift-evolution@swift.org> wrote:

 I still think the value-based APIs are misleading and that it would be
 better to ask people to just use a type explicitly.

 John.



 I agree; in fact *why aren’t these properties on the type itself*? The
 type is what matters; why can’t the type just tell me it’s size?
 Having free functions or magic operators seems to be another holdover
 from C.


 Int.size
 Int.alignment
 Int.spacing

 let x: Any = 5
 type(of: x).size


 The compiler should be able to statically know the first three values
 and inline them. The second is discovering the size dynamically.


 Two reasons.  The first is that this is a user-extensible namespace via
 static members, so it's somewhat unfortunate to pollute it with names from
 the library.  The second is that there's currently no language mechanism
 for adding a static member to every type, so this would have to be
 built-in.  But I agree that in the abstract a static property would be
 preferable.

>>>
>>> In the earlier conversation, it was pointed out (by Dave A., I think?)
>>> that examples such as Array.size show how this solution can get confusing.
>>> And even though there aren't fixed-length arrays in Swift, those may come
>>> one day, making the syntax even more confusing.
>>>
>>> ___
>>> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On the other hand, on its own sizeof() is not unsafe, and so the argument 
> that it should be longer to call attention to itself (by analogy with 
> UnsafePointer) isn't quite apt.

These operations aren't themselves unsafe.  But they are low level details that 
are not useful unless you are doing something that requires special care.  A 
name that stands out more calls attention to the surrounding code.  That is a 
good thing IMO.

> 
> And I'm not sure we really want to encourage anyone else to be defining a 
> global function named size(of:) anyway, so I wouldn't consider vacating that 
> name for end-user purposes to be a meaningful positive.
>> On Thu, Jun 2, 2016 at 16:15 Tony Allevato  wrote:
>> Given that these are fairly low-level values with very specialized uses, I 
>> definitely agree that they should be somehow namespaced in a way that 
>> doesn't cause us to make very common words unusable for our users.
>> 
>> Even size(of:) seems more general to me than I'd like. I'd like to see the 
>> word "memory" as part of the name somehow, whether it's a wrapping type or a 
>> function prefix of some sort. These values are specialized; we don't need to 
>> optimize typing them, IMO.
>> 
>>> On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution 
>>>  wrote:
>> 
>>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution 
>>>  wrote:
>> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>>  wrote:
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
>> 
>> John.
> 
> 
> I agree; in fact why aren’t these properties on the type itself? The type 
> is what matters; why can’t the type just tell me it’s size? 
> Having free functions or magic operators seems to be another holdover 
> from C. 
> 
> 
> Int.size
> Int.alignment
> Int.spacing
> 
> let x: Any = 5
> type(of: x).size
> 
> 
> The compiler should be able to statically know the first three values and 
> inline them. The second is discovering the size dynamically.
 
 Two reasons.  The first is that this is a user-extensible namespace via 
 static members, so it's somewhat unfortunate to pollute it with names from 
 the library.  The second is that there's currently no language mechanism 
 for adding a static member to every type, so this would have to be 
 built-in.  But I agree that in the abstract a static property would be 
 preferable.
>>> 
>>> In the earlier conversation, it was pointed out (by Dave A., I think?) that 
>>> examples such as Array.size show how this solution can get confusing. And 
>>> even though there aren't fixed-length arrays in Swift, those may come one 
>>> day, making the syntax even more confusing.
>>> 
>> 
>>> ___
>>> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

Nope. I use it with Metal buffers, for example :)

Moreover, there's nothing inherently unsafe about sizeof, and I think it's
important, *especially when you're working with UnsafePointers*, that safe
things look safe. If the moment a pointer comes into the picture everything
related to it is prefixed with Unsafe, that word loses its meaning entirely.
On Thu, Jun 2, 2016 at 16:54 Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > I don't disagree with the points you make.  But one can argue that this
> is a good thing.  It calls attention to code that requires extra attention
> and care.  In some ways this is similar to 'UnsafeMutablePointer' vs
> '*T'.  Verbosity was a deliberate choice in that case.
>
> You know...rather than introducing a new type like MemoryLayout, would it
> make sense to do this with static properties on UnsafePointer?
>
> UnsafePointer.pointeeSize
> UnsafePointer.pointeeAlignment
> UnsafePointer.pointeeSpacing
>
> If you need this information, 90% of the time you're probably using
> UnsafePointer or one of its friends, right?
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 3:55 PM, Brent Royal-Gordon  wrote:
> 
>> I don't disagree with the points you make.  But one can argue that this is a 
>> good thing.  It calls attention to code that requires extra attention and 
>> care.  In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  
>> Verbosity was a deliberate choice in that case.
> 
> You know...rather than introducing a new type like MemoryLayout, would it 
> make sense to do this with static properties on UnsafePointer?
> 
>   UnsafePointer.pointeeSize
>   UnsafePointer.pointeeAlignment
>   UnsafePointer.pointeeSpacing
> 
> If you need this information, 90% of the time you're probably using 
> UnsafePointer or one of its friends, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

Some quick greppage -- E

public/core/BridgeObjectiveC.swift:_sanityCheck(sizeofValue(self) >=
public/core/Builtin.swift:public func sizeofValue(_:T) -> Int {
public/core/Character.swift:let bits = sizeofValue(initialUTF8) &* 8 &- 1
public/core/Unicode.swift:  if utf8Count < sizeofValue(result) {

private/SwiftPrivateLibcExtras/Subprocess.swift:let errnoSize = 
sizeof(errno.dynamicType)
private/SwiftPrivateLibcExtras/SwiftPrivateLibcExtras.swift:return 
sizeof(UInt) * 8
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: 
, count: sizeof(UInt.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: , 
count: sizeof(T.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  fread(, 
sizeof(UInt.self), 1, stdin)
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: 
, count: sizeof(UInt.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  let pointerSize = 
UInt8(sizeof(UnsafePointer.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  let anyPointer = 
UnsafeMutablePointer(allocatingCapacity: sizeof(Any.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
anyPointer.deallocateCapacity(sizeof(Any.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction0.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction0.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction1.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction1.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction2.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction2.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction3.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction3.self))
public/core/BridgeObjectiveC.swift:   
sizeof(Optional.self) * count)
public/core/Builtin.swift:/// In particular, `sizeof(X.self)`, when `X` is a 
class type, is the
public/core/Builtin.swift:public func sizeof(_:T.Type) -> Int {
public/core/Builtin.swift:  return Int(Builtin.sizeof(T.self))
public/core/Builtin.swift:/// In particular, `sizeof(a)`, when `a` is a class 
instance, is the
public/core/Builtin.swift:  return sizeof(T.self)
public/core/Builtin.swift:  _precondition(sizeof(T.self) == sizeof(U.self),
public/core/Builtin.swift:sizeof(_HeapObject.self),
public/core/Character.swift:// Notice that the result of sizeof() is a 
small non-zero number and can't
public/core/HeapBuffer.swift:  sizeof(_HeapObject.self),
public/core/HeapBuffer.swift:  _valueOffset() + sizeof(Value.self),
public/core/ManagedBuffer.swift:  
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
public/core/ManagedBuffer.swift:  == _valueOffset + sizeof(Value.self)),
public/core/ManagedBuffer.swift:  
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
public/core/ManagedBuffer.swift:  == _valueOffset + sizeof(Value.self)),
public/core/ManagedBuffer.swift:  sizeof(_HeapObject.self),
public/core/ManagedBuffer.swift:  _valueOffset + sizeof(Value.self),
public/core/Runtime.swift.gyb:  _sanityCheck(sizeof(_Buffer32.self) == 32)
public/core/Runtime.swift.gyb:  _sanityCheck(sizeof(_Buffer72.self) == 72)
public/core/Runtime.swift.gyb:  for _ in 0..<(2 * sizeof(UnsafePointer) - 
result.utf16.count) {
public/core/Sequence.swift:// `n` * sizeof(Iterator.Element) of memory, 
because slices keep the entire
public/core/StringUTF8.swift:  let utf16Count = 
Swift.min(sizeof(_UTF8Chunk.self), count - i)
public/core/StringUTF8.swift:return 0xFF << 
numericCast((sizeof(Buffer.self) &- 1) &* 8)
public/core/Unicode.swift:  let utf8Max = sizeof(_UTF8Chunk.self)
public/core/VarArgs.swift:count: (sizeof(T.self) + sizeof(Int.self) - 1) / 
sizeof(Int.self))

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Sean Heber via swift-evolution]

This might be silly, but what if there were a struct with all of the relevant 
fields (not sure what the best name would be):

struct MemoryLayout {
  let size: Int
  let alignment: Int
  let stride: Int
 // etc
}

Then you’d only maybe need two functions:

memoryLayout(of:) and memoryLayout(ofType:)

Or perhaps just a single property on all types named “memoryLayout” (or 
whatever) that returns the MemoryLayout struct:

Int.memory.size
type(of: 42).memoryLayout.size
// etc

Or just a single property on UnsafePointer if we went that route..

It seems like this sort of approach would keep namespace pollution down, at 
least?

l8r
Sean


> On Jun 2, 2016, at 4:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I don't disagree with the points you make.  But one can argue that this is a 
>> good thing.  It calls attention to code that requires extra attention and 
>> care.  In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  
>> Verbosity was a deliberate choice in that case.
> 
> You know...rather than introducing a new type like MemoryLayout, would it 
> make sense to do this with static properties on UnsafePointer?
> 
>   UnsafePointer.pointeeSize
>   UnsafePointer.pointeeAlignment
>   UnsafePointer.pointeeSpacing
> 
> If you need this information, 90% of the time you're probably using 
> UnsafePointer or one of its friends, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Brent Royal-Gordon via swift-evolution]

> I don't disagree with the points you make.  But one can argue that this is a 
> good thing.  It calls attention to code that requires extra attention and 
> care.  In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  
> Verbosity was a deliberate choice in that case.

You know...rather than introducing a new type like MemoryLayout, would it make 
sense to do this with static properties on UnsafePointer?

UnsafePointer.pointeeSize
UnsafePointer.pointeeAlignment
UnsafePointer.pointeeSpacing

If you need this information, 90% of the time you're probably using 
UnsafePointer or one of its friends, right?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

Isn't this the same argument for .dynamicType over type(of:) though?

Given that that debate has been settled in favor of the latter, I think the
question today is how best to come up with a consistent scheme.

Earlier in this conversation, it was pointed out (by Matt, I think?) that
one key advantage of type(of:) is that it takes on a syntax that is
actually possible to write in Swift, since one cannot extend Any.

If we take this principle to its logical conclusion, properties (of a type
or instance) which apply to Any should be global functions.

On Thu, Jun 2, 2016 at 16:26 Russ Bishop  wrote:

>
> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu  wrote:
>
>
> In the earlier conversation, it was pointed out (by Dave A., I think?)
> that examples such as Array.size show how this solution can get confusing.
> And even though there aren't fixed-length arrays in Swift, those may come
> one day, making the syntax even more confusing.
>
>
>
> Array.count is a function taking an instance; I’m not sure I agree it
> would be terribly confusing… then again I run in Xcode with the quick help
> pane open so I see the doc comments for every type, property, and function
> as I move around the code. It’s quite handy :)
>
> I could see including memory in the name (or something similar) if we want
> to be extra clear about it.
>
> Int.memorySize
> Int.memoryAlignment
>
>
> Ultimately the type’s size in memory *is a property of the type* so it
> seems clear that is where it belongs (being careful not to steal too much
> of the namespace of course).
>
>
> Russ
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[John McCall via swift-evolution]

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu  wrote:
> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution 
> > wrote:
>> On Jun 2, 2016, at 1:43 PM, Russ Bishop > > wrote:
>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> I still think the value-based APIs are misleading and that it would be 
>>> better to ask people to just use a type explicitly.
>>> 
>>> John.
>> 
>> 
>> I agree; in fact why aren’t these properties on the type itself? The type is 
>> what matters; why can’t the type just tell me it’s size? 
>> Having free functions or magic operators seems to be another holdover from 
>> C. 
>> 
>> 
>> Int.size
>> Int.alignment
>> Int.spacing
>> 
>> let x: Any = 5
>> type(of: x).size
>> 
>> 
>> The compiler should be able to statically know the first three values and 
>> inline them. The second is discovering the size dynamically.
> 
> Two reasons.  The first is that this is a user-extensible namespace via 
> static members, so it's somewhat unfortunate to pollute it with names from 
> the library.  The second is that there's currently no language mechanism for 
> adding a static member to every type, so this would have to be built-in.  But 
> I agree that in the abstract a static property would be preferable.
> 
> In the earlier conversation, it was pointed out (by Dave A., I think?) that 
> examples such as Array.size show how this solution can get confusing. And 
> even though there aren't fixed-length arrays in Swift, those may come one 
> day, making the syntax even more confusing.

Yes, I think that it is clear that, even if we added a property on all types, 
it would not be acceptable to name that property something like "size"; it 
would have to be something longer like "storageSize".

John.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 3:28 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu > > wrote:
>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution 
>> > wrote:
> 
> Yes, I think that it is clear that, even if we added a property on all types, 
> it would not be acceptable to name that property something like "size"; it 
> would have to be something longer like "storageSize".

Suggested names so far for augmenting the base:

* memorySize, memoryAlignment, memorySpacing/memoryStride
* storageSize, storageAlignment, storageSpacing/storageStride

-- E


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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Russ Bishop via swift-evolution]

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu  wrote:
> 
> 
> In the earlier conversation, it was pointed out (by Dave A., I think?) that 
> examples such as Array.size show how this solution can get confusing. And 
> even though there aren't fixed-length arrays in Swift, those may come one 
> day, making the syntax even more confusing.


Array.count is a function taking an instance; I’m not sure I agree it would be 
terribly confusing… then again I run in Xcode with the quick help pane open so 
I see the doc comments for every type, property, and function as I move around 
the code. It’s quite handy :)

I could see including memory in the name (or something similar) if we want to 
be extra clear about it.

Int.memorySize
Int.memoryAlignment


Ultimately the type’s size in memory is a property of the type so it seems 
clear that is where it belongs (being careful not to steal too much of the 
namespace of course).


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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On the other hand, on its own sizeof() is not unsafe, and so the argument
that it should be longer to call attention to itself (by analogy with
UnsafePointer) isn't quite apt.

And I'm not sure we really want to encourage anyone else to be defining a
global function named size(of:) anyway, so I wouldn't consider vacating
that name for end-user purposes to be a meaningful positive.
On Thu, Jun 2, 2016 at 16:15 Tony Allevato  wrote:

> Given that these are fairly low-level values with very specialized uses, I
> definitely agree that they should be somehow namespaced in a way that
> doesn't cause us to make very common words unusable for our users.
>
> Even size(of:) seems more general to me than I'd like. I'd like to see the
> word "memory" as part of the name somehow, whether it's a wrapping type or
> a function prefix of some sort. These values are specialized; we don't need
> to optimize typing them, IMO.
>
> On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>>>
>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> I still think the value-based APIs are misleading and that it would be
>>> better to ask people to just use a type explicitly.
>>>
>>> John.
>>>
>>>
>>>
>>> I agree; in fact *why aren’t these properties on the type itself*? The
>>> type is what matters; why can’t the type just tell me it’s size?
>>> Having free functions or magic operators seems to be another holdover
>>> from C.
>>>
>>>
>>> Int.size
>>> Int.alignment
>>> Int.spacing
>>>
>>> let x: Any = 5
>>> type(of: x).size
>>>
>>>
>>> The compiler should be able to statically know the first three values
>>> and inline them. The second is discovering the size dynamically.
>>>
>>>
>>> Two reasons.  The first is that this is a user-extensible namespace via
>>> static members, so it's somewhat unfortunate to pollute it with names from
>>> the library.  The second is that there's currently no language mechanism
>>> for adding a static member to every type, so this would have to be
>>> built-in.  But I agree that in the abstract a static property would be
>>> preferable.
>>>
>>
>> In the earlier conversation, it was pointed out (by Dave A., I think?)
>> that examples such as Array.size show how this solution can get confusing.
>> And even though there aren't fixed-length arrays in Swift, those may come
>> one day, making the syntax even more confusing.
>>
>> ___
>> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Tony Allevato via swift-evolution]

Given that these are fairly low-level values with very specialized uses, I
definitely agree that they should be somehow namespaced in a way that
doesn't cause us to make very common words unusable for our users.

Even size(of:) seems more general to me than I'd like. I'd like to see the
word "memory" as part of the name somehow, whether it's a wrapping type or
a function prefix of some sort. These values are specialized; we don't need
to optimize typing them, IMO.

On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>>
>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I still think the value-based APIs are misleading and that it would be
>> better to ask people to just use a type explicitly.
>>
>> John.
>>
>>
>>
>> I agree; in fact *why aren’t these properties on the type itself*? The
>> type is what matters; why can’t the type just tell me it’s size?
>> Having free functions or magic operators seems to be another holdover
>> from C.
>>
>>
>> Int.size
>> Int.alignment
>> Int.spacing
>>
>> let x: Any = 5
>> type(of: x).size
>>
>>
>> The compiler should be able to statically know the first three values and
>> inline them. The second is discovering the size dynamically.
>>
>>
>> Two reasons.  The first is that this is a user-extensible namespace via
>> static members, so it's somewhat unfortunate to pollute it with names from
>> the library.  The second is that there's currently no language mechanism
>> for adding a static member to every type, so this would have to be
>> built-in.  But I agree that in the abstract a static property would be
>> preferable.
>>
>
> In the earlier conversation, it was pointed out (by Dave A., I think?)
> that examples such as Array.size show how this solution can get confusing.
> And even though there aren't fixed-length arrays in Swift, those may come
> one day, making the syntax even more confusing.
>
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>
> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I still think the value-based APIs are misleading and that it would be
> better to ask people to just use a type explicitly.
>
> John.
>
>
>
> I agree; in fact *why aren’t these properties on the type itself*? The
> type is what matters; why can’t the type just tell me it’s size?
> Having free functions or magic operators seems to be another holdover from
> C.
>
>
> Int.size
> Int.alignment
> Int.spacing
>
> let x: Any = 5
> type(of: x).size
>
>
> The compiler should be able to statically know the first three values and
> inline them. The second is discovering the size dynamically.
>
>
> Two reasons.  The first is that this is a user-extensible namespace via
> static members, so it's somewhat unfortunate to pollute it with names from
> the library.  The second is that there's currently no language mechanism
> for adding a static member to every type, so this would have to be
> built-in.  But I agree that in the abstract a static property would be
> preferable.
>

In the earlier conversation, it was pointed out (by Dave A., I think?) that
examples such as Array.size show how this solution can get confusing. And
even though there aren't fixed-length arrays in Swift, those may come one
day, making the syntax even more confusing.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[John McCall via swift-evolution]

> On Jun 2, 2016, at 1:43 PM, Russ Bishop  wrote:
>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
>> 
>> John.
> 
> 
> I agree; in fact why aren’t these properties on the type itself? The type is 
> what matters; why can’t the type just tell me it’s size? 
> Having free functions or magic operators seems to be another holdover from C. 
> 
> 
> Int.size
> Int.alignment
> Int.spacing
> 
> let x: Any = 5
> type(of: x).size
> 
> 
> The compiler should be able to statically know the first three values and 
> inline them. The second is discovering the size dynamically.

Two reasons.  The first is that this is a user-extensible namespace via static 
members, so it's somewhat unfortunate to pollute it with names from the 
library.  The second is that there's currently no language mechanism for adding 
a static member to every type, so this would have to be built-in.  But I agree 
that in the abstract a static property would be preferable.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 2:43 PM, Russ Bishop  wrote:
> 
> 
>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
>> 
>> John.
> 
> 
> I agree; in fact why aren’t these properties on the type itself? The type is 
> what matters; why can’t the type just tell me it’s size? 
> Having free functions or magic operators seems to be another holdover from C. 
> 
> 
> Int.size
> Int.alignment
> Int.spacing
> 
> let x: Any = 5
> type(of: x).size
> 
> 
> The compiler should be able to statically know the first three values and 
> inline them. The second is discovering the size dynamically.
> 
> 
> Russ

If achievable, this would certainly be clean and elegant.

-- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Russ Bishop via swift-evolution]

> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution 
>  wrote:
> 
> I still think the value-based APIs are misleading and that it would be better 
> to ask people to just use a type explicitly.
> 
> John.


I agree; in fact why aren’t these properties on the type itself? The type is 
what matters; why can’t the type just tell me it’s size? 
Having free functions or magic operators seems to be another holdover from C. 


Int.size
Int.alignment
Int.spacing

let x: Any = 5
type(of: x).size


The compiler should be able to statically know the first three values and 
inline them. The second is discovering the size dynamically.


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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 2:13 PM, Matthew Johnson  wrote:
> I don't disagree with the points you make.  But one can argue that this is a 
> good thing.  It calls attention to code that requires extra attention and 
> care.  In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  
> Verbosity was a deliberate choice in that case.

And mentioned.

https://github.com/erica/swift-evolution/blob/sizestride/proposals/-sidestride.md

-- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 2:58 PM, Erica Sadun  wrote:
> 
> 
>> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> On Jun 2, 2016, at 1:30 PM, John McCall  wrote:
>> 
 On Jun 2, 2016, at 11:22 AM, Matthew Johnson  
 wrote:
 On Jun 2, 2016, at 12:01 PM, John McCall  wrote:
 
>>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu  wrote:
>> We could have a primary initializer like this:
>> 
>> init(_ type: T.Type)
>> 
>> It would look better than a default initializer that requires the type to be 
>> passed as a generic argument.  The fact that it is not labeled would make it 
>> clear that this is the primary initializer.
>> 
>>> 
>>> I still think the value-based APIs are misleading and that it would be 
>>> better to ask people to just use a type explicitly.
>> 
>> Sure.  I don't necessarily disagree.  But I think it's important to make 
>> clear that this is orthogonal to the struct vs free function discussion.  
>> That was the main point I was trying to make.  :)
>> 
>>> 
 Adding the label will eliminate the potential for confusion about type vs 
 metatype.  Wanting to know the size of the metatype is probably extremely 
 rare, but there is not reason to prohibit it.
>>> 
>>> I agree that the label makes the problem better.
>>> 
>>> John.
> 
> 
> I do want to say that while I'm including this in Alternatives Considered 
> (and will update as soon as we finish lunch), that I stand by the 
> freestanding functions as preferable to this clever but extremely indirect 
> approach.
> 
> I believe the MemoryLayout type introduces a level of indirection that is 
> less helpful in the rare times the user will consume this functionality, that 
> it clutters calls and adds cognitive burden for reading code.
> 
> Let me give you some examples:
> 
> let errnoSize = sizeof(errno.dynamicType)
> return sizeof(UInt) * 8
> sendBytes(from: , count: sizeof(UInt.self))
> _class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
> bytesPerIndex: sizeof(IndexType))
> 
> In every example, calling a size function's clarity is simpler than using the 
> Memory Layout approach:
> 
> let errnoSize = MemoryLayout.init(t: errno).size
> return MemoryLayout.size * 8
> sendBytes(from: , count: MemoryLayout.size)
> _class_getInstancePositiveExtentSize(bufferClass) == 
> MemoryLayout<_HeapObject.self>.size
> bytesPerIndex: MemoryLayout.size
> 
> The full type specification lends the calls an importance and verbosity they 
> don't deserve compared to their simpler counterparts. The eye is drawn every 
> time to the "MemoryLayout" pattern:
> 
> * Prominence of the type constructor
> * Simplicity of the function call
> * Number of code characters used
> * Swift's adherence to a mantra of concision and clarity.
> 
> It fails all these. To put it in usability terms: it's a big stinking mess 
> compared to the readability and eye tracking of the simpler function. (I've 
> cc'ed in Chris Lattner, who has people who can test this kind of thing on 
> call.)

I don't disagree with the points you make.  But one can argue that this is a 
good thing.  It calls attention to code that requires extra attention and care. 
 In some ways this is similar to 'UnsafeMutablePointer' vs '*T'.  Verbosity 
was a deliberate choice in that case.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution 
>  wrote:
> On Jun 2, 2016, at 1:30 PM, John McCall  > wrote:
> 
>>> On Jun 2, 2016, at 11:22 AM, Matthew Johnson >> > wrote:
>>> On Jun 2, 2016, at 12:01 PM, John McCall >> > wrote:
>>> 
> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
> > wrote:
>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > > wrote:
> We could have a primary initializer like this:
> 
> init(_ type: T.Type)
> 
> It would look better than a default initializer that requires the type to be 
> passed as a generic argument.  The fact that it is not labeled would make it 
> clear that this is the primary initializer.
> 
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
> 
> Sure.  I don't necessarily disagree.  But I think it's important to make 
> clear that this is orthogonal to the struct vs free function discussion.  
> That was the main point I was trying to make.  :)
> 
>> 
>>> Adding the label will eliminate the potential for confusion about type vs 
>>> metatype.  Wanting to know the size of the metatype is probably extremely 
>>> rare, but there is not reason to prohibit it.
>> 
>> I agree that the label makes the problem better.
>> 
>> John.


I do want to say that while I'm including this in Alternatives Considered (and 
will update as soon as we finish lunch), that I stand by the freestanding 
functions as preferable to this clever but extremely indirect approach.

I believe the MemoryLayout type introduces a level of indirection that is less 
helpful in the rare times the user will consume this functionality, that it 
clutters calls and adds cognitive burden for reading code.

Let me give you some examples:

let errnoSize = sizeof(errno.dynamicType)
return sizeof(UInt) * 8
sendBytes(from: , count: sizeof(UInt.self))
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
bytesPerIndex: sizeof(IndexType))

In every example, calling a size function's clarity is simpler than using the 
Memory Layout approach:

let errnoSize = MemoryLayout.init(t: errno).size
return MemoryLayout.size * 8
sendBytes(from: , count: MemoryLayout.size)
_class_getInstancePositiveExtentSize(bufferClass) == 
MemoryLayout<_HeapObject.self>.size
bytesPerIndex: MemoryLayout.size

The full type specification lends the calls an importance and verbosity they 
don't deserve compared to their simpler counterparts. The eye is drawn every 
time to the "MemoryLayout" pattern:

* Prominence of the type constructor
* Simplicity of the function call
* Number of code characters used
* Swift's adherence to a mantra of concision and clarity.

It fails all these. To put it in usability terms: it's a big stinking mess 
compared to the readability and eye tracking of the simpler function. (I've 
cc'ed in Chris Lattner, who has people who can test this kind of thing on call.)

-- E


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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[John McCall via swift-evolution]

> On Jun 2, 2016, at 11:22 AM, Matthew Johnson  wrote:
> On Jun 2, 2016, at 12:01 PM, John McCall  > wrote:
> 
>>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
 On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > wrote:
 
 Well, as I understand it, it's not actually possible to write your own 
 type(of:), so we're going from a "magic" property to a "magic" function at 
 least for now.
>>> 
>>> No, but you *can* write `func foo(_ t: T)` which accepts any value (you 
>>> *cannot* write a property that is available for all properties - that would 
>>> require the ability to write `extension Any`.  This is the distinction I am 
>>> making.  Of course the implementation is compiler magic no matter how we 
>>> express it syntactically.  But we can make it *appear* just like it might 
>>> if the implementation *wasn’t* compiler magic.  That makes it fit into the 
>>> language better IMO and was the biggest motivator for changing 
>>> `dynamicType`.
>>> 
 
 I'm most alarmed that one implication of the MemoryLayout proposal is loss 
 of the `ofValue` family of functions. These functions don't fit with the 
 design: imagine, what is `MemoryLayout.size(ofValue: Float(42))`? 
 But the response seems to be that these functions don't seem necessary at 
 all and should be removed. "I don't see a use for it" is an insufficient 
 justification for a feature removal. Looking to other languages, C# has 
 sizeof as a static property but tellingly offers the equivalent of 
 sizeofValue (well, strideofValue) as a function in a different module. 
 Essentially every other C-family language that exposes pointers to the 
 user offers both of and ofValue equivalents. The question is, how does a 
 user with existing code using sizeofValue() migrate to Swift 3? I do not 
 see a viable answer with the MemoryLayout design.
>>> 
>>> Going with MemoryLayout *does not* mean we would have to give up the value 
>>> functions if we don’t want to:
>>> 
>>> struct MemoryLayout {
>>> init() {}
>>> init(t: T) { /* throw away the value */ }
>>> 
>>> // we could omit the static properties and require 
>>> // writing MemoryLayout() if we don’t like the duplication
>>> static let size: Int
>>> static let spacing: Int
>>> static let alignment: Int
>>> 
>>> let size: Int
>>> let spacing: Int
>>> let alignment: Int
>>> }
>>> 
>>> let size = MemoryLayout.size
>>> let sizeOfValue = MemoryLayout(42).size
>> 
>> There's no good reason for this type to be generic.  It should be 
>> non-generic and require the use of the instance properties.
> 
> Dave's initial suggestion was generic and Joe suggested static properties.  I 
> suppose it doesn't have to be generic if we pass the type directly to the 
> initializer, but that design would eliminate the possibility of inferring the 
> type from a value (which some people seem to want to retain).
> 
> I didn't mean to advocate either way about adding a value initializer and 
> instance properties.  I was only trying to show that it is *possible* to do 
> that if we want to preserve the ofValue capabilities.
> 
>> 
>> It's actively harmful for this type to appear to be computed from a value.  
>> The layout is not in any way tied to the dynamic type of the value — for 
>> example, it is not the instance layout of the most-derived class or the 
>> value layout of the dynamic type of an existential.  
> 
> Understood, but that same problem exists for the current ofValue operations 
> doesn't it? We can discuss removing them (I am not opposed to that), but that 
> is independent of whether we should use a MemoryLayout struct as opposed to 
> free functions.

I'm not trying to dictate the entire design.  I'm saying that, if you're going 
to have a layout structure, I see no reason for it to be generic, and you 
should absolutely not make the primary way of constructing it be implicitly 
value-based.

I still think the value-based APIs are misleading and that it would be better 
to ask people to just use a type explicitly.

> Adding the label will eliminate the potential for confusion about type vs 
> metatype.  Wanting to know the size of the metatype is probably extremely 
> rare, but there is not reason to prohibit it.

I agree that the label makes the problem better.

John.

> 
>> 
>> John.
>> 
>>> 
 
 On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson > wrote:
 
 
 Sent from my iPad
 
 On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
 > wrote:
 
> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 12:01 PM, John McCall  wrote:
> 
>>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu  wrote:
>>> 
>>> Well, as I understand it, it's not actually possible to write your own 
>>> type(of:), so we're going from a "magic" property to a "magic" function at 
>>> least for now.
>> 
>> No, but you *can* write `func foo(_ t: T)` which accepts any value (you 
>> *cannot* write a property that is available for all properties - that would 
>> require the ability to write `extension Any`.  This is the distinction I am 
>> making.  Of course the implementation is compiler magic no matter how we 
>> express it syntactically.  But we can make it *appear* just like it might if 
>> the implementation *wasn’t* compiler magic.  That makes it fit into the 
>> language better IMO and was the biggest motivator for changing `dynamicType`.
>> 
>>> 
>>> I'm most alarmed that one implication of the MemoryLayout proposal is loss 
>>> of the `ofValue` family of functions. These functions don't fit with the 
>>> design: imagine, what is `MemoryLayout.size(ofValue: Float(42))`? 
>>> But the response seems to be that these functions don't seem necessary at 
>>> all and should be removed. "I don't see a use for it" is an insufficient 
>>> justification for a feature removal. Looking to other languages, C# has 
>>> sizeof as a static property but tellingly offers the equivalent of 
>>> sizeofValue (well, strideofValue) as a function in a different module. 
>>> Essentially every other C-family language that exposes pointers to the user 
>>> offers both of and ofValue equivalents. The question is, how does a user 
>>> with existing code using sizeofValue() migrate to Swift 3? I do not see a 
>>> viable answer with the MemoryLayout design.
>> 
>> Going with MemoryLayout *does not* mean we would have to give up the value 
>> functions if we don’t want to:
>> 
>> struct MemoryLayout {
>> init() {}
>> init(t: T) { /* throw away the value */ }
>> 
>> // we could omit the static properties and require 
>> // writing MemoryLayout() if we don’t like the duplication
>> static let size: Int
>> static let spacing: Int
>> static let alignment: Int
>> 
>> let size: Int
>> let spacing: Int
>> let alignment: Int
>> }
>> 
>> let size = MemoryLayout.size
>> let sizeOfValue = MemoryLayout(42).size
> 
> There's no good reason for this type to be generic.  It should be non-generic 
> and require the use of the instance properties.

Dave's initial suggestion was generic and Joe suggested static properties.  I 
suppose it doesn't have to be generic if we pass the type directly to the 
initializer, but that design would eliminate the possibility of inferring the 
type from a value (which some people seem to want to retain).

I didn't mean to advocate either way about adding a value initializer and 
instance properties.  I was only trying to show that it is *possible* to do 
that if we want to preserve the ofValue capabilities.

> 
> It's actively harmful for this type to appear to be computed from a value.  
> The layout is not in any way tied to the dynamic type of the value — for 
> example, it is not the instance layout of the most-derived class or the value 
> layout of the dynamic type of an existential.  

Understood, but that same problem exists for the current ofValue operations 
doesn't it? We can discuss removing them (I am not opposed to that), but that 
is independent of whether we should use a MemoryLayout struct as opposed to 
free functions.

> Furthermore, saying that it is computed from a value means that attempting to 
> compute it from a type will succeed using the layout of the metatype, which 
> seems like a catastrophic failure of API design.

I was a bit hasty with the argument label and my example calling code wouldn't 
have actually worked.  I should have included a clear external label.

This is what we would want to actually do (Erica, can you update again?):

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

Used like this:

let sizeOfValue = MemoryLayout(ofValue: 42).size

Adding the label will eliminate the potential for confusion about type vs 
metatype.  Wanting to know the size of the metatype is probably extremely rare, 
but there is not reason to prohibit it.

> 
> John.
> 
>> 
>>> 
 On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson  
 wrote:
 
 
 Sent from my iPad
 
> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  
>> wrote:
>> I really like this idea. This IMO is lower level functionality than 
>> `type(of:)` (née dynamicType), so I think it makes sense for it to be 
>> grouped under its own domain, the MemoryLayout 

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[John McCall via swift-evolution]

> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
>  wrote:
>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > > wrote:
>> 
>> Well, as I understand it, it's not actually possible to write your own 
>> type(of:), so we're going from a "magic" property to a "magic" function at 
>> least for now.
> 
> No, but you *can* write `func foo(_ t: T)` which accepts any value (you 
> *cannot* write a property that is available for all properties - that would 
> require the ability to write `extension Any`.  This is the distinction I am 
> making.  Of course the implementation is compiler magic no matter how we 
> express it syntactically.  But we can make it *appear* just like it might if 
> the implementation *wasn’t* compiler magic.  That makes it fit into the 
> language better IMO and was the biggest motivator for changing `dynamicType`.
> 
>> 
>> I'm most alarmed that one implication of the MemoryLayout proposal is loss 
>> of the `ofValue` family of functions. These functions don't fit with the 
>> design: imagine, what is `MemoryLayout.size(ofValue: Float(42))`? 
>> But the response seems to be that these functions don't seem necessary at 
>> all and should be removed. "I don't see a use for it" is an insufficient 
>> justification for a feature removal. Looking to other languages, C# has 
>> sizeof as a static property but tellingly offers the equivalent of 
>> sizeofValue (well, strideofValue) as a function in a different module. 
>> Essentially every other C-family language that exposes pointers to the user 
>> offers both of and ofValue equivalents. The question is, how does a user 
>> with existing code using sizeofValue() migrate to Swift 3? I do not see a 
>> viable answer with the MemoryLayout design.
> 
> Going with MemoryLayout *does not* mean we would have to give up the value 
> functions if we don’t want to:
> 
> struct MemoryLayout {
> init() {}
> init(t: T) { /* throw away the value */ }
> 
> // we could omit the static properties and require 
> // writing MemoryLayout() if we don’t like the duplication
> static let size: Int
> static let spacing: Int
> static let alignment: Int
> 
> let size: Int
> let spacing: Int
> let alignment: Int
> }
> 
> let size = MemoryLayout.size
> let sizeOfValue = MemoryLayout(42).size

There's no good reason for this type to be generic.  It should be non-generic 
and require the use of the instance properties.

It's actively harmful for this type to appear to be computed from a value.  The 
layout is not in any way tied to the dynamic type of the value — for example, 
it is not the instance layout of the most-derived class or the value layout of 
the dynamic type of an existential.  Furthermore, saying that it is computed 
from a value means that attempting to compute it from a type will succeed using 
the layout of the metatype, which seems like a catastrophic failure of API 
design.

John.

> 
>> 
>> On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson > > wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith >> > wrote:
>>> I really like this idea. This IMO is lower level functionality than 
>>> `type(of:)` (née dynamicType), so I think it makes sense for it to be 
>>> grouped under its own domain, the MemoryLayout type.
>>> 
>>> Plus MemoryLayout can be extended with new convenience methods.
>>> 
>>> I’m fine with those old methods being removed, but I never use them so! Is 
>>> it the same as calling type(of:) then using that with MemoryLayout? I 
>>> imagine they could be fixit’d easily, and that they compile down to the 
>>> same underlying code.
>>> 
>>> I'm actually souring to the idea. It goes in the diametrically opposite 
>>> direction from dynamicType. There, something was changed from being 
>>> property-like to being function-like. Here, Dave's proposal would take 
>>> something that's a function and turn it into a property. Hmm.
>> 
>> That's not a fair comparison though.  With dynamicType we removed a "magic" 
>> property visible on all types, which isn't something you can write and 
>> turned it into a function (which is obviously something you can write).  
>> 
>> Dave's MemoryLayout creates a new type to bundle together related items 
>> which makes their semantic relationship more clear.  It also receives the 
>> type via a generic argument rather than a function argument and makes the 
>> properties static.  That is more representative of what is actually 
>> happening and could help to prevent confusion.  
>> 
>> If we really need an 'ofValue' option that infers T from a value the 
>> properties on MemoryLayout could also be made available 

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 2, 2016, at 10:12 AM, Matthew Johnson  wrote:
>> On Jun 2, 2016, at 11:04 AM, Erica Sadun > > wrote:
>>> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> struct MemoryLayout {
>>> init() {}
>>> init(t: T) { /* throw away the value */ }
>> 
>> And amended Alternatives with this. :)
> 
> Thanks!  Can you change the init signature with Pyry’s improvement: `init(_: 
> @autoclosure () -> T) {}`?

https://github.com/erica/swift-evolution/blob/sizestride/proposals/-sidestride.md

-- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 11:04 AM, Erica Sadun  wrote:
> 
> 
>> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> struct MemoryLayout {
>> init() {}
>> init(t: T) { /* throw away the value */ }
>> 
>> // we could omit the static properties and require 
>> // writing MemoryLayout() if we don’t like the duplication
>> static let size: Int
>> static let spacing: Int
>> static let alignment: Int
>> 
>> let size: Int
>> let spacing: Int
>> let alignment: Int
>> }
>> 
>> let size = MemoryLayout.size
>> let sizeOfValue = MemoryLayout(42).size
> 
> And amended Alternatives with this. :)

Thanks!  Can you change the init signature with Pyry’s improvement: `init(_: 
@autoclosure () -> T) {}`?

> 
> - E
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 11:04 AM, Pyry Jahkola  wrote:
> 
>> Matthew Johnson wrote:
>> 
>> Going with MemoryLayout *does not* mean we would have to give up the value 
>> functions if we don’t want to:
>> 
>> struct MemoryLayout {
>> init(t: T) { /* throw away the value */ }
>> // …
>> }
>> 
>> let sizeOfValue = MemoryLayout(42).size
> 
> You could also use @autoclosure here to avoid evaluating whatever expression 
> there is:
> 
> struct MemoryLayout {
> init(_: @autoclosure () -> T) {}
> // ...
> }

Brilliant!  Why didn’t I think of that? :-)

> 
> — Pyry
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

Both good points. I could live with your solution.

On Thu, Jun 2, 2016 at 10:48 AM Matthew Johnson 
wrote:

> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu  wrote:
>
> Well, as I understand it, it's not actually possible to write your own
> type(of:), so we're going from a "magic" property to a "magic" function at
> least for now.
>
>
> No, but you *can* write `func foo(_ t: T)` which accepts any value (you
> *cannot* write a property that is available for all properties - that would
> require the ability to write `extension Any`.  This is the distinction I am
> making.  Of course the implementation is compiler magic no matter how we
> express it syntactically.  But we can make it *appear* just like it might
> if the implementation *wasn’t* compiler magic.  That makes it fit into the
> language better IMO and was the biggest motivator for changing
> `dynamicType`.
>
>
> I'm most alarmed that one implication of the MemoryLayout proposal is loss
> of the `ofValue` family of functions. These functions don't fit with the
> design: imagine, what is `MemoryLayout.size(ofValue: Float(42))`?
> But the response seems to be that these functions don't seem necessary at
> all and should be removed. "I don't see a use for it" is an insufficient
> justification for a feature removal. Looking to other languages, C# has
> sizeof as a static property but tellingly offers the equivalent of
> sizeofValue (well, strideofValue) as a function in a different module.
> Essentially every other C-family language that exposes pointers to the user
> offers both of and ofValue equivalents. The question is, how does a user
> with existing code using sizeofValue() migrate to Swift 3? I do not see a
> viable answer with the MemoryLayout design.
>
>
> Going with MemoryLayout *does not* mean we would have to give up the value
> functions if we don’t want to:
>
> struct MemoryLayout {
> init() {}
> init(t: T) { /* throw away the value */ }
>
> // we could omit the static properties and require
> // writing MemoryLayout() if we don’t like the duplication
> static let size: Int
> static let spacing: Int
> static let alignment: Int
>
> let size: Int
> let spacing: Int
> let alignment: Int
> }
>
> let size = MemoryLayout.size
> let sizeOfValue = MemoryLayout(42).size
>
>
> On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson 
> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith 
>> wrote:
>>
>>> I really like this idea. This IMO is lower level functionality than
>>> `type(of:)` (née dynamicType), so I think it makes sense for it to be
>>> grouped under its own domain, the MemoryLayout type.
>>>
>>> Plus MemoryLayout can be extended with new convenience methods.
>>>
>>> I’m fine with those old methods being removed, but I never use them so!
>>> Is it the same as calling type(of:) then using that with MemoryLayout? I
>>> imagine they could be fixit’d easily, and that they compile down to the
>>> same underlying code.
>>>
>>
>> I'm actually souring to the idea. It goes in the diametrically opposite
>> direction from dynamicType. There, something was changed from being
>> property-like to being function-like. Here, Dave's proposal would take
>> something that's a function and turn it into a property. Hmm.
>>
>>
>> That's not a fair comparison though.  With dynamicType we removed a
>> "magic" property visible on all types, which isn't something you can write
>> and turned it into a function (which is obviously something you can write).
>>
>>
>> Dave's MemoryLayout creates a new type to bundle together related items
>> which makes their semantic relationship more clear.  It also receives the
>> type via a generic argument rather than a function argument and makes the
>> properties static.  That is more representative of what is actually
>> happening and could help to prevent confusion.
>>
>> If we really need an 'ofValue' option that infers T from a value the
>> properties on MemoryLayout could also be made available as instance
>> properties and it could have an initializer that accepts an instance to T
>> and throws the value away.  However, I'm not at all convinced this is
>> necessary.
>>
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> 2. Dave A. and others expressed the opinion that these should probably
>>> not be global functions; his preference was for:
>>>
>>> ```
>>> MemoryLayout.size // currently sizeof()
>>> MemoryLayout.spacing // currently strideof()
>>> MemoryLayout.alignment // currently alignof()
>>> ```
>>>
>>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and
>>> alignofValue() are better off removed altogether. I don't know if people
>>> are going to be happy about this idea.
>>>
>>>
>>>
>> 

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu  wrote:
> 
> Well, as I understand it, it's not actually possible to write your own 
> type(of:), so we're going from a "magic" property to a "magic" function at 
> least for now.

No, but you *can* write `func foo(_ t: T)` which accepts any value (you 
*cannot* write a property that is available for all properties - that would 
require the ability to write `extension Any`.  This is the distinction I am 
making.  Of course the implementation is compiler magic no matter how we 
express it syntactically.  But we can make it *appear* just like it might if 
the implementation *wasn’t* compiler magic.  That makes it fit into the 
language better IMO and was the biggest motivator for changing `dynamicType`.

> 
> I'm most alarmed that one implication of the MemoryLayout proposal is loss of 
> the `ofValue` family of functions. These functions don't fit with the design: 
> imagine, what is `MemoryLayout.size(ofValue: Float(42))`? But the 
> response seems to be that these functions don't seem necessary at all and 
> should be removed. "I don't see a use for it" is an insufficient 
> justification for a feature removal. Looking to other languages, C# has 
> sizeof as a static property but tellingly offers the equivalent of 
> sizeofValue (well, strideofValue) as a function in a different module. 
> Essentially every other C-family language that exposes pointers to the user 
> offers both of and ofValue equivalents. The question is, how does a user with 
> existing code using sizeofValue() migrate to Swift 3? I do not see a viable 
> answer with the MemoryLayout design.

Going with MemoryLayout *does not* mean we would have to give up the value 
functions if we don’t want to:

struct MemoryLayout {
init() {}
init(t: T) { /* throw away the value */ }

// we could omit the static properties and require 
// writing MemoryLayout() if we don’t like the duplication
static let size: Int
static let spacing: Int
static let alignment: Int

let size: Int
let spacing: Int
let alignment: Int
}

let size = MemoryLayout.size
let sizeOfValue = MemoryLayout(42).size

> 
> On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson  > wrote:
> 
> 
> Sent from my iPad
> 
> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith > > wrote:
>> I really like this idea. This IMO is lower level functionality than 
>> `type(of:)` (née dynamicType), so I think it makes sense for it to be 
>> grouped under its own domain, the MemoryLayout type.
>> 
>> Plus MemoryLayout can be extended with new convenience methods.
>> 
>> I’m fine with those old methods being removed, but I never use them so! Is 
>> it the same as calling type(of:) then using that with MemoryLayout? I 
>> imagine they could be fixit’d easily, and that they compile down to the same 
>> underlying code.
>> 
>> I'm actually souring to the idea. It goes in the diametrically opposite 
>> direction from dynamicType. There, something was changed from being 
>> property-like to being function-like. Here, Dave's proposal would take 
>> something that's a function and turn it into a property. Hmm.
> 
> That's not a fair comparison though.  With dynamicType we removed a "magic" 
> property visible on all types, which isn't something you can write and turned 
> it into a function (which is obviously something you can write).  
> 
> Dave's MemoryLayout creates a new type to bundle together related items which 
> makes their semantic relationship more clear.  It also receives the type via 
> a generic argument rather than a function argument and makes the properties 
> static.  That is more representative of what is actually happening and could 
> help to prevent confusion.  
> 
> If we really need an 'ofValue' option that infers T from a value the 
> properties on MemoryLayout could also be made available as instance 
> properties and it could have an initializer that accepts an instance to T and 
> throws the value away.  However, I'm not at all convinced this is necessary.
> 
>>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> 2. Dave A. and others expressed the opinion that these should probably not 
>>> be global functions; his preference was for:
>>> 
>>> ```
>>> MemoryLayout.size // currently sizeof()
>>> MemoryLayout.spacing // currently strideof()
>>> MemoryLayout.alignment // currently alignof()
>>> ```
>>> 
>>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>>> are better off removed altogether. I don't know if people are going to be 
>>> happy about this idea.
>> 
>> 
> 
>> ___
>> 

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 10:01 AM, Charlie Monroe  wrote:
> 
>> Isn’t this a short-term concern?  I thought that requirement was going away.
> 
> AFAIK there are still concerns about ambiguity - [Int] - is it an array with 
> one element (Int.self), or is it [Int].self?

IIRC Joe Groff was going to work on sorting out the remaining issues but the 
plan is to move ahead eventually.

> 
>> 
>>> For this reason, this proposal prefers using no-label calls for types 
>>> (otherwise they would have been ofType) and labeled calls for values:
>>> 
>>> print(sizeof(Int)) // works
>>> print(sizeof(Int.self)) // works
>>> 
>>> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
>>> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
>>> 
>>> 
>>> // Works
>>> print(withoutLabel(Int))
>>> 
>>> // Works
>>> print(withLabel(label: Int.self))
>>> 
>>> // Does not work
>>> // error: cannot create a single-element tuple with an element label
>>> // print(withLabel(label: Int)) 
>>> 
>>> 
>>> So with this in mind:
>>> 
>>> /// Returns the contiguous memory footprint of `T`.
>>> ///
>>> /// Does not include any dynamically-allocated or "remote" storage.
>>> /// In particular, `size(X.self)`, when `X` is a class type, is the
>>> /// same regardless of how many stored properties `X` has.
>>> public func size(_: T.Type) -> Int
>>> 
>>> /// Returns the contiguous memory footprint of  `T`.
>>> ///
>>> /// Does not include any dynamically-allocated or "remote" storage.
>>> /// In particular, `size(of: a)`, when `a` is a class instance, is the
>>> /// same regardless of how many stored properties `a` has.
>>> public func size(of: T) -> Int
>>> 
>>> /// Returns the least possible interval between distinct instances of
>>> /// `T` in memory.  The result is always positive.
>>> public func spacing(_: T.Type) -> Int
>>> 
>>> /// Returns the least possible interval between distinct instances of
>>> /// `T` in memory.  The result is always positive.
>>> public func spacing(of: T) -> Int
>>> 
>>> /// Returns the minimum memory alignment of `T`.
>>> public func alignment(_: T.Type) -> Int
>>> 
>>> /// Returns the minimum memory alignment of `T`.
>>> public func alignment(of: T) -> Int
>>> -- 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu  wrote:
> 
> That proposal was returned for revision; as far as user ergonomics in Swift 
> 3, .self is going to be a consideration. Best to find a solution that reads 
> nicely regardless of the situation with .self removal.

From the core team decision:

"The core team would definitely like to circle back to this proposal after 
Swift 3 is out the door."

I think we should consider the best long-term design.  If that happens to be 
dropping labels great, but if not, maybe we don’t want to do that just because 
it will look better in Swift 3 at the cost of a better design when “.self” is 
not required.

Dave’s MemoryLayout approach avoids the question of labels entirely.  This is 
another subtle nudge in that direction IMO.

> 
> On Thu, Jun 2, 2016 at 9:57 AM Matthew Johnson  > wrote:
>> On Jun 2, 2016, at 9:43 AM, Erica Sadun > > wrote:
>> 
>> Supporting Dave A, type-based calls are much more likely to be used than 
>> instance calls, unlike with dynamicType/type(of:)
>> 
>> Term stdlib search   gist search Google site:github +swift
>> sizeof   157 169 4880
>> sizeofValue  4   34  584
>> alignof  44  11  334
>> alignofValue 5   5   154
>> strideof 347 19  347
>> strideofValue4   5   163
>> Type-based calls like sizeof() are poor candidates for parameter labels. 
>> While it's acceptable to write sizeof(Int), but one must write size(of: 
>> Int.self) (with the trailing self) when the function has a label.
> 
> Isn’t this a short-term concern?  I thought that requirement was going away.
> 
>> For this reason, this proposal prefers using no-label calls for types 
>> (otherwise they would have been ofType) and labeled calls for values:
>> 
>> print(sizeof(Int)) // works
>> print(sizeof(Int.self)) // works
>> 
>> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
>> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
>> 
>> 
>> // Works
>> print(withoutLabel(Int))
>> 
>> // Works
>> print(withLabel(label: Int.self))
>> 
>> // Does not work
>> // error: cannot create a single-element tuple with an element label
>> // print(withLabel(label: Int)) 
>> 
>> 
>> So with this in mind:
>> 
>> /// Returns the contiguous memory footprint of `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(X.self)`, when `X` is a class type, is the
>> /// same regardless of how many stored properties `X` has.
>> public func size(_: T.Type) -> Int
>> 
>> /// Returns the contiguous memory footprint of  `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(of: a)`, when `a` is a class instance, is the
>> /// same regardless of how many stored properties `a` has.
>> public func size(of: T) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(_: T.Type) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(of: T) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment(_: T.Type) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment(of: T) -> Int
>> -- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

That proposal was returned for revision; as far as user ergonomics in Swift
3, .self is going to be a consideration. Best to find a solution that reads
nicely regardless of the situation with .self removal.

On Thu, Jun 2, 2016 at 9:57 AM Matthew Johnson 
wrote:

> On Jun 2, 2016, at 9:43 AM, Erica Sadun  wrote:
>
> Supporting Dave A, type-based calls are much more likely to be used than
> instance calls, unlike with dynamicType/type(of:)
>
> Termstdlib searchgist searchGoogle site:github +swift
> sizeof 157 169 4880
> sizeofValue 4 34 584
> alignof 44 11 334
> alignofValue 5 5 154
> strideof 347 19 347
> strideofValue 4 5 163
> Type-based calls like sizeof() are poor candidates for parameter labels.
> While it's acceptable to write sizeof(Int), but one must write size(of:
> Int.self) (with the trailing self) when the function has a label.
>
>
> Isn’t this a short-term concern?  I thought that requirement was going
> away.
>
> For this reason, this proposal prefers using no-label calls for types
> (otherwise they would have been ofType) and labeled calls for values:
>
> print(sizeof(Int)) // worksprint(sizeof(Int.self)) // works
> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }func 
> withLabel(label label: T.Type) -> Int { return sizeof(T) }
>
> // Worksprint(withoutLabel(Int))
> // Worksprint(withLabel(label: Int.self))
> // Does not work// error: cannot create a single-element tuple with an 
> element label// print(withLabel(label: Int))
>
>
>
> So with this in mind:
>
> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(_: T.Type) -> Int
>
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(of: T) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(_: T.Type) -> Int
>
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(_: T.Type) -> Int
>
> /// Returns the minimum memory alignment of `T`.
> public func alignment(of: T) -> Int
>
> -- E
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Charlie Monroe via swift-evolution]

> Isn’t this a short-term concern?  I thought that requirement was going away.

AFAIK there are still concerns about ambiguity - [Int] - is it an array with 
one element (Int.self), or is it [Int].self?

> 
>> For this reason, this proposal prefers using no-label calls for types 
>> (otherwise they would have been ofType) and labeled calls for values:
>> 
>> print(sizeof(Int)) // works
>> print(sizeof(Int.self)) // works
>> 
>> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
>> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
>> 
>> 
>> // Works
>> print(withoutLabel(Int))
>> 
>> // Works
>> print(withLabel(label: Int.self))
>> 
>> // Does not work
>> // error: cannot create a single-element tuple with an element label
>> // print(withLabel(label: Int)) 
>> 
>> 
>> So with this in mind:
>> 
>> /// Returns the contiguous memory footprint of `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(X.self)`, when `X` is a class type, is the
>> /// same regardless of how many stored properties `X` has.
>> public func size(_: T.Type) -> Int
>> 
>> /// Returns the contiguous memory footprint of  `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(of: a)`, when `a` is a class instance, is the
>> /// same regardless of how many stored properties `a` has.
>> public func size(of: T) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(_: T.Type) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(of: T) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment(_: T.Type) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment(of: T) -> Int
>> -- 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 9:43 AM, Erica Sadun  wrote:
> 
> Supporting Dave A, type-based calls are much more likely to be used than 
> instance calls, unlike with dynamicType/type(of:)
> 
> Term  stdlib search   gist search Google site:github +swift
> sizeof157 169 4880
> sizeofValue   4   34  584
> alignof   44  11  334
> alignofValue  5   5   154
> strideof  347 19  347
> strideofValue 4   5   163
> Type-based calls like sizeof() are poor candidates for parameter labels. 
> While it's acceptable to write sizeof(Int), but one must write size(of: 
> Int.self) (with the trailing self) when the function has a label.

Isn’t this a short-term concern?  I thought that requirement was going away.

> For this reason, this proposal prefers using no-label calls for types 
> (otherwise they would have been ofType) and labeled calls for values:
> 
> print(sizeof(Int)) // works
> print(sizeof(Int.self)) // works
> 
> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
> 
> 
> // Works
> print(withoutLabel(Int))
> 
> // Works
> print(withLabel(label: Int.self))
> 
> // Does not work
> // error: cannot create a single-element tuple with an element label
> // print(withLabel(label: Int)) 
> 
> 
> So with this in mind:
> 
> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(_: T.Type) -> Int
> 
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(of: T) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(_: T.Type) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func alignment(_: T.Type) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func alignment(of: T) -> Int
> -- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

Supporting Dave A, type-based calls are much more likely to be used than 
instance calls, unlike with dynamicType/type(of:)

Termstdlib search   gist search Google site:github +swift
sizeof  157 169 4880
sizeofValue 4   34  584
alignof 44  11  334
alignofValue5   5   154
strideof347 19  347
strideofValue   4   5   163
Type-based calls like sizeof() are poor candidates for parameter labels. While 
it's acceptable to write sizeof(Int), but one must write size(of: Int.self) 
(with the trailing self) when the function has a label. For this reason, this 
proposal prefers using no-label calls for types (otherwise they would have been 
ofType) and labeled calls for values:

print(sizeof(Int)) // works
print(sizeof(Int.self)) // works

func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
func withLabel(label label: T.Type) -> Int { return sizeof(T) }


// Works
print(withoutLabel(Int))

// Works
print(withLabel(label: Int.self))

// Does not work
// error: cannot create a single-element tuple with an element label
// print(withLabel(label: Int)) 


So with this in mind:

/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(X.self)`, when `X` is a class type, is the
/// same regardless of how many stored properties `X` has.
public func size(_: T.Type) -> Int

/// Returns the contiguous memory footprint of  `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: a)`, when `a` is a class instance, is the
/// same regardless of how many stored properties `a` has.
public func size(of: T) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(_: T.Type) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(of: T) -> Int

/// Returns the minimum memory alignment of `T`.
public func alignment(_: T.Type) -> Int

/// Returns the minimum memory alignment of `T`.
public func alignment(of: T) -> Int
-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Jun 2, 2016, at 6:26 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> /// Returns the contiguous memory footprint of `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(of: X.self)`, when `X` is a class type, is the
>> /// same regardless of how many stored properties `X` has.
>> public func size(of: T.Type) -> Int
>> 
>> /// Returns the contiguous memory footprint of  `T`.
>> ///
>> /// Does not include any dynamically-allocated or "remote" storage.
>> /// In particular, `size(of: a)`, when `a` is a class instance, is the
>> /// same regardless of how many stored properties `a` has.
>> public func size(ofValue: T) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(of: T.Type) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing(ofValue: T) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func align(of: T.Type) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func align(ofValue: T) -> Int
> 
> If `type(of:)` takes an instance, then I think `size(of:)`, `spacing(of:)` 
> and `align(of:)` need to do the same, with `size(ofType:)`, 
> `spacing(ofType:)`, and `align(ofType:)` handling the type side of things.

+1 if we stick with the function direction.  But I'm not convinced this is the 
best direction.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

>> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  wrote:
>> I really like this idea. This IMO is lower level functionality than 
>> `type(of:)` (née dynamicType), so I think it makes sense for it to be 
>> grouped under its own domain, the MemoryLayout type.
>> 
>> Plus MemoryLayout can be extended with new convenience methods.
>> 
>> I’m fine with those old methods being removed, but I never use them so! Is 
>> it the same as calling type(of:) then using that with MemoryLayout? I 
>> imagine they could be fixit’d easily, and that they compile down to the same 
>> underlying code.
> 
> I'm actually souring to the idea. It goes in the diametrically opposite 
> direction from dynamicType. There, something was changed from being 
> property-like to being function-like. Here, Dave's proposal would take 
> something that's a function and turn it into a property. Hmm.

That's not a fair comparison though.  With dynamicType we removed a "magic" 
property visible on all types, which isn't something you can write and turned 
it into a function (which is obviously something you can write).  

Dave's MemoryLayout creates a new type to bundle together related items which 
makes their semantic relationship more clear.  It also receives the type via a 
generic argument rather than a function argument and makes the properties 
static.  That is more representative of what is actually happening and could 
help to prevent confusion.  

If we really need an 'ofValue' option that infers T from a value the properties 
on MemoryLayout could also be made available as instance properties and it 
could have an initializer that accepts an instance to T and throws the value 
away.  However, I'm not at all convinced this is necessary.

>>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> 2. Dave A. and others expressed the opinion that these should probably not 
>>> be global functions; his preference was for:
>>> 
>>> ```
>>> MemoryLayout.size // currently sizeof()
>>> MemoryLayout.spacing // currently strideof()
>>> MemoryLayout.alignment // currently alignof()
>>> ```
>>> 
>>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>>> are better off removed altogether. I don't know if people are going to be 
>>> happy about this idea.
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 2, 2016, at 12:05 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu  wrote:
>>> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>> 
>>> Upon accepting SE-0098, the core team renamed the proposed stdlib function 
>>> from dynamicType() to type(of:).  They write, "The core team recognizes 
>>> that this means that we should probably resyntax the existing 
>>> sizeof/strideof functions, but that should be a follow-on discussion."
>>> 
>>> Follow on discussion started. Have at it.
>> 
>> See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830
> 
> To summarize the previous discussion:
> 
> 1. Per Joe Groff, although sizeof() and friends are treated as terms-of-art, 
> these names were lifted straight from C and do not correspond to anything 
> named "sizeof" in LLVM.
> 
> 2. There are issues with using a name such as stride(of:), because 
> stride(...) already means something else in the stdlib; moreover, size(of:) 
> isn't the best name for something that doesn't do what its C namesake does; 
> therefore, larger changes to the naming were suggested.
> 
> 2. Dave A. and others expressed the opinion that these should probably not be 
> global functions; his preference was for:
> 
> ```
> MemoryLayout.size // currently sizeof()
> MemoryLayout.spacing // currently strideof()
> MemoryLayout.alignment // currently alignof()
> ```

Thanks for the summary.  I missed the original thread.  

I think I like this approach despite its verbosity.  Will give it a little bit 
more thought...

> 
> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
> are better off removed altogether. I don't know if people are going to be 
> happy about this idea.
> 
> * * *
> 
> If we take inspiration from type(of:), then it's actually sizeofValue(), 
> etc., that should be renamed size(of:), etc. Also, a fun tidbit is that 
> what's currently called sizeof(), etc.--the ones that take types rather than 
> values--are actually not very good candidates for having parameter labels, 
> because it's OK to write `sizeof(Int)`, but one must currently write 
> `size(of: Int.self)` when the function has a label.
> 
> 
> 
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Brent Royal-Gordon via swift-evolution]

> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(of: T.Type) -> Int
> 
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(ofValue: T) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T.Type) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(ofValue: T) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func align(of: T.Type) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func align(ofValue: T) -> Int

If `type(of:)` takes an instance, then I think `size(of:)`, `spacing(of:)` and 
`align(of:)` need to do the same, with `size(ofType:)`, `spacing(ofType:)`, and 
`align(ofType:)` handling the type side of things.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

Yeah I realise who Dave is :)

Ok, that’s good to know about your uses. An extra benefit that MemoryLayout has 
is a developer who is familiar with sizeof() from other languages (I only know 
of C), if it was called the same thing in Swift they might just go ahead and 
use it and add their own alignment tricks. Whereas a MemoryLayout type ties of 
all this functionality together in the one place, where they can discover that 
`stride`/`spacing` might serve them better.

Patrick

> On 2 Jun 2016, at 4:23 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:37 AM, Patrick Smith  > wrote:
> Yes but, if they weren’t functions now, what would be the best design?
> 
> Dave's suggestions then were made in the context of a language that had 
> `.dynamicType`. The question today is how best to align these functions with 
> `type(of:)`. If we were to ignore this context, I'm not sure on what basis we 
> could judge whether a property or function is 'best' for these facilities.
>  
> How many Swift developers will be using this functionality? Less than 1%? I 
> trust Dave’s judgement because he is in that small group.
> 
> I would caution against this assumption. I'm not a particularly advanced 
> developer by any stretch of the imagination, and I've been using `strideof()` 
> plenty of times while doing some math with Accelerate.framework and Metal 
> buffers. That said, Dave's in a very small group indeed, the group that wrote 
> these functions to start with.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Thu, Jun 2, 2016 at 12:37 AM, Patrick Smith  wrote:

> Yes but, if they weren’t functions now, what would be the best design?
>

Dave's suggestions then were made in the context of a language that had
`.dynamicType`. The question today is how best to align these functions
with `type(of:)`. If we were to ignore this context, I'm not sure on what
basis we could judge whether a property or function is 'best' for these
facilities.


> How many Swift developers will be using this functionality? Less than 1%?
> I trust Dave’s judgement because he is in that small group.
>

I would caution against this assumption. I'm not a particularly advanced
developer by any stretch of the imagination, and I've been using
`strideof()` plenty of times while doing some math with
Accelerate.framework and Metal buffers. That said, Dave's in a very small
group indeed, the group that wrote these functions to start with.

> On 2 Jun 2016, at 3:27 PM, Xiaodi Wu  wrote:
>
> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  wrote:
>
>> I really like this idea. This IMO is lower level functionality than
>> `type(of:)` (née dynamicType), so I think it makes sense for it to be
>> grouped under its own domain, the MemoryLayout type.
>>
>> Plus MemoryLayout can be extended with new convenience methods.
>>
>> I’m fine with those old methods being removed, but I never use them so!
>> Is it the same as calling type(of:) then using that with MemoryLayout? I
>> imagine they could be fixit’d easily, and that they compile down to the
>> same underlying code.
>>
>
> I'm actually souring to the idea. It goes in the diametrically opposite
> direction from dynamicType. There, something was changed from being
> property-like to being function-like. Here, Dave's proposal would take
> something that's a function and turn it into a property. Hmm.
>
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 2. Dave A. and others expressed the opinion that these should probably
>> not be global functions; his preference was for:
>>
>> ```
>> MemoryLayout.size // currently sizeof()
>> MemoryLayout.spacing // currently strideof()
>> MemoryLayout.alignment // currently alignof()
>> ```
>>
>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and
>> alignofValue() are better off removed altogether. I don't know if people
>> are going to be happy about this idea.
>>
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

Yes but, if they weren’t functions now, what would be the best design?

How many Swift developers will be using this functionality? Less than 1%? I 
trust Dave’s judgement because he is in that small group.

> On 2 Jun 2016, at 3:27 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  > wrote:
> I really like this idea. This IMO is lower level functionality than 
> `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped 
> under its own domain, the MemoryLayout type.
> 
> Plus MemoryLayout can be extended with new convenience methods.
> 
> I’m fine with those old methods being removed, but I never use them so! Is it 
> the same as calling type(of:) then using that with MemoryLayout? I imagine 
> they could be fixit’d easily, and that they compile down to the same 
> underlying code.
> 
> I'm actually souring to the idea. It goes in the diametrically opposite 
> direction from dynamicType. There, something was changed from being 
> property-like to being function-like. Here, Dave's proposal would take 
> something that's a function and turn it into a property. Hmm.
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 2. Dave A. and others expressed the opinion that these should probably not 
>> be global functions; his preference was for:
>> 
>> ```
>> MemoryLayout.size // currently sizeof()
>> MemoryLayout.spacing // currently strideof()
>> MemoryLayout.alignment // currently alignof()
>> ```
>> 
>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>> are better off removed altogether. I don't know if people are going to be 
>> happy about this idea.
> 
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  wrote:

> I really like this idea. This IMO is lower level functionality than
> `type(of:)` (née dynamicType), so I think it makes sense for it to be
> grouped under its own domain, the MemoryLayout type.
>
> Plus MemoryLayout can be extended with new convenience methods.
>
> I’m fine with those old methods being removed, but I never use them so! Is
> it the same as calling type(of:) then using that with MemoryLayout? I
> imagine they could be fixit’d easily, and that they compile down to the
> same underlying code.
>

I'm actually souring to the idea. It goes in the diametrically opposite
direction from dynamicType. There, something was changed from being
property-like to being function-like. Here, Dave's proposal would take
something that's a function and turn it into a property. Hmm.

> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 2. Dave A. and others expressed the opinion that these should probably not
> be global functions; his preference was for:
>
> ```
> MemoryLayout.size // currently sizeof()
> MemoryLayout.spacing // currently strideof()
> MemoryLayout.alignment // currently alignof()
> ```
>
> 3. Dave A. proposed that sizeofValue(), strideofValue(), and
> alignofValue() are better off removed altogether. I don't know if people
> are going to be happy about this idea.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

Using MemoryLayout is a much bigger change than the simple name changes being 
pitched here. I'm not ruling it out, but it may be deferred or additive as the 
3.0 timeline allows and the core team decides.

For now, my suggested design (strongly based on Wux's feedback and the previous 
thread discussion) is:

/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: X.self)`, when `X` is a class type, is the
/// same regardless of how many stored properties `X` has.
public func size(of: T.Type) -> Int

/// Returns the contiguous memory footprint of  `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: a)`, when `a` is a class instance, is the
/// same regardless of how many stored properties `a` has.
public func size(ofValue: T) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(of: T.Type) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(ofValue: T) -> Int

/// Returns the minimum memory alignment of `T`.
public func align(of: T.Type) -> Int

/// Returns the minimum memory alignment of `T`.
public func align(ofValue: T) -> Int


> On Jun 1, 2016, at 11:24 PM, Patrick Smith  wrote:
> 
> I really like this idea. This IMO is lower level functionality than 
> `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped 
> under its own domain, the MemoryLayout type.
> 
> Plus MemoryLayout can be extended with new convenience methods.
> 
> I’m fine with those old methods being removed, but I never use them so! Is it 
> the same as calling type(of:) then using that with MemoryLayout? I imagine 
> they could be fixit’d easily, and that they compile down to the same 
> underlying code.
> 
> Patrick
> 
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 2. Dave A. and others expressed the opinion that these should probably not 
>> be global functions; his preference was for:
>> 
>> ```
>> MemoryLayout.size // currently sizeof()
>> MemoryLayout.spacing // currently strideof()
>> MemoryLayout.alignment // currently alignof()
>> ```
>> 
>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>> are better off removed altogether. I don't know if people are going to be 
>> happy about this idea.
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

I really like this idea. This IMO is lower level functionality than `type(of:)` 
(née dynamicType), so I think it makes sense for it to be grouped under its own 
domain, the MemoryLayout type.

Plus MemoryLayout can be extended with new convenience methods.

I’m fine with those old methods being removed, but I never use them so! Is it 
the same as calling type(of:) then using that with MemoryLayout? I imagine they 
could be fixit’d easily, and that they compile down to the same underlying code.

Patrick

> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 2. Dave A. and others expressed the opinion that these should probably not be 
> global functions; his preference was for:
> 
> ```
> MemoryLayout.size // currently sizeof()
> MemoryLayout.spacing // currently strideof()
> MemoryLayout.alignment // currently alignof()
> ```
> 
> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
> are better off removed altogether. I don't know if people are going to be 
> happy about this idea.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 1, 2016, at 11:10 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch  > wrote:
> If it's worth continuing the discussion in this thread, I rather like the 
> MemoryLayout.size idea. For discoverability, we might want to have 
> @availability(*, unavailable, message: "use MemoryLayout.size, etc.") 
> public init(){}.
> 
> It's a nice syntax, but I'm not fully comfortable with the suggestion that 
> sizeofValue(), etc. should go.  Also, I wonder about the static vs. dynamic 
> type issue here (despite having started the last thread, I still haven't sat 
> down to think it through).
> 

Updated with all the feedback so far. Will keep an eye on this.

-- E

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch 
wrote:

> If it's worth continuing the discussion in this thread, I rather like the
> MemoryLayout.size idea. For discoverability, we might want to have
> @availability(*, unavailable, message: "use MemoryLayout.size, etc.")
> public init(){}.
>

It's a nice syntax, but I'm not fully comfortable with the suggestion that
sizeofValue(), etc. should go.  Also, I wonder about the static vs. dynamic
type issue here (despite having started the last thread, I still haven't
sat down to think it through).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu  wrote:

> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Upon accepting SE-0098, the core team renamed the proposed stdlib
>> function from dynamicType() to type(of:).  They write, "The core team
>> recognizes that this means that we should probably resyntax the existing
>> sizeof/strideof functions, but that should be a follow-on discussion."
>>
>> Follow on discussion started. Have at it.
>>
>
> See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830
>
>

To summarize the previous discussion:

1. Per Joe Groff, although sizeof() and friends are treated as
terms-of-art, these names were lifted straight from C and do not correspond
to anything named "sizeof" in LLVM.

2. There are issues with using a name such as stride(of:), because
stride(...) already means something else in the stdlib; moreover, size(of:)
isn't the best name for something that doesn't do what its C namesake does;
therefore, larger changes to the naming were suggested.

2. Dave A. and others expressed the opinion that these should probably not
be global functions; his preference was for:

```
MemoryLayout.size // currently sizeof()
MemoryLayout.spacing // currently strideof()
MemoryLayout.alignment // currently alignof()
```

3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue()
are better off removed altogether. I don't know if people are going to be
happy about this idea.

* * *

If we take inspiration from type(of:), then it's actually sizeofValue(),
etc., that should be renamed size(of:), etc. Also, a fun tidbit is that
what's currently called sizeof(), etc.--the ones that take types rather
than values--are actually not very good candidates for having parameter
labels, because it's OK to write `sizeof(Int)`, but one must currently
write `size(of: Int.self)` when the function has a label.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

> On Jun 1, 2016, at 10:55 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution 
> > wrote:
> Upon accepting SE-0098, the core team renamed the proposed stdlib function 
> from dynamicType() to type(of:).  They write, "The core team recognizes that 
> this means that we should probably resyntax the existing sizeof/strideof 
> functions, but that should be a follow-on discussion."
> 
> Follow on discussion started. Have at it.
> 
> See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830 
> 
>  


And added alignof/alignofValue plus the original discussion thread

https://github.com/apple/swift-evolution/pull/350/files

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Jacob Bandes-Storch via swift-evolution]

If it's worth continuing the discussion in this thread, I rather like the
MemoryLayout.size idea. For discoverability, we might want to have
@availability(*, unavailable, message: "use MemoryLayout.size, etc.")
public init(){}.

Jacob

On Wed, Jun 1, 2016 at 9:55 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Upon accepting SE-0098, the core team renamed the proposed stdlib
>> function from dynamicType() to type(of:).  They write, "The core team
>> recognizes that this means that we should probably resyntax the existing
>> sizeof/strideof functions, but that should be a follow-on discussion."
>>
>> Follow on discussion started. Have at it.
>>
>
> See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830
>
>
> ___
> 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] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu via swift-evolution]

On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Upon accepting SE-0098, the core team renamed the proposed stdlib function
> from dynamicType() to type(of:).  They write, "The core team recognizes
> that this means that we should probably resyntax the existing
> sizeof/strideof functions, but that should be a follow-on discussion."
>
> Follow on discussion started. Have at it.
>

See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Erica Sadun via swift-evolution]

Upon accepting SE-0098, the core team renamed the proposed stdlib function from 
dynamicType() to type(of:).  They write, "The core team recognizes that this 
means that we should probably resyntax the existing sizeof/strideof functions, 
but that should be a follow-on discussion."

Follow on discussion started. Have at it.

-- E


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