> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu <xiaodi...@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 <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: >> On Jun 2, 2016, at 9:43 AM, Erica Sadun <er...@ericasadun.com >> <mailto:er...@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
