on Thu Jun 02 2016, Matthew Johnson <[email protected]> wrote:
> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu <[email protected]> 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 <[email protected]> > wrote: > > On Jun 2, 2016, at 9:43 AM, Erica Sadun <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
