on Tue Jun 21 2016, Erica Sadun <[email protected]> wrote: >> On Jun 21, 2016, at 2:36 PM, Dave Abrahams <[email protected]> wrote: >> >> >> on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com >> <http://erica-at-ericasadun.com/>> wrote: >> > >>>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution >>>> <[email protected]> wrote: >>>> This could be enabled by having sizeof and friends formally take an >>>> Any.Type instead of <T> T.Type. (This might need some tweaking of >>>> the underlying builtins to be able to open existential metatypes, >>>> but it seems implementable.) >>> >>> While I'm not a huge fan of Dave A's generic struct approach (for >>> reasons detailed in the proposal), >> >> Some of the examples used to justify avoiding that approach look >> wrong or overly complicated to me. Am I missing something? >> >> let errnoSize = MemoryLayout.init(t: errno).size >> >> _class_getInstancePositiveExtentSize(bufferClass) == >> MemoryLayout<_HeapObject.self>.size >> >> wouldn't that be: >> >> let errnoSize = MemoryLayout(errno).size >> >> _class_getInstancePositiveExtentSize(bufferClass) == >> MemoryLayout<_HeapObject>.size >> >> ? >> >> Once you fix those issues, I don't find my proposal to hurt >> readability at all. One has to put those examples into their actual >> contexts rather than packing them all next to one another, to evaluate >> it fairly. >> >> Finally, I still object to doubling the API surface area just so you can >> pass values instead of types to these functions. Having three global >> functions is acceptable, but six is too many, and arguably, having a >> single type would be better. > > * I sourced my examples from the stdlib. That one's from ManagedBuffer.swift. > Only qualification was that I was looking for examples of sizeof.
I understand that, but I don't see how it's relevant. My point was that these don't appear in code stacked one on top of another like that. > * In regard to offering both of and ofValue, I agree: I'd rather offer > half the surface area, especially since Joe says the main issue is > technically avoidable. > > * I don't like having to scan past the MemoryLayout and the type in question > to > get to the member name that defines what property is requested. You have to > read it back > to front. I find that to be a human factors limitation that makes it > less desirable to use. The “type in question” is very much relevant, just as in `customers.count`, `customers` is relevant. If I didn't think it would produce semantic confusion, these would be static members e.g. `Array.memoryAlignment`, and you'd have to “scan past” `Array`. It's a perfectly natural way to express a property of a type. > * At the same time, what I do like about the struct is that it's > extensible without introducing standalone functions (and shrinks the > number of functions that exist in the stdlib), and that the properties > express intrinsic characteristics of the memory layout of a given > type. The functions are measure-y. The properties are > characteristic-y. It even directly supports the -Value variants without expanding the global API surface area, per MemoryLayout(errno).size however, I don't think this is a good idea because of the potential for confusion in cases like this: MemoryLayout(Int.self).size -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
