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

[Dave Abrahams]

on Thu Jun 02 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

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

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 <matthew at anandabits.com> wrote:
>
>  On Jun 2, 2016, at 9:43 AM, Erica Sadun <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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave