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

[Matthew Johnson]

> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu <xiaodi.wu at gmail.com> 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 <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> On Jun 2, 2016, at 9:43 AM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> 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<T>(thetype: T.Type) -> Int { return sizeof(T) }
>> func withLabel<T>(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>(_: 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<T>(of: T) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing<T>(_: T.Type) -> Int
>> 
>> /// Returns the least possible interval between distinct instances of
>> /// `T` in memory.  The result is always positive.
>> public func spacing<T>(of: T) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment<T>(_: T.Type) -> Int
>> 
>> /// Returns the minimum memory alignment of `T`.
>> public func alignment<T>(of: T) -> Int
>> -- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/72c38296/attachment.html>