on Thu Jun 02 2016, John McCall <[email protected]> wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop <[email protected]> wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > <[email protected]> > 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<Int>.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 > [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
