[swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Erica Sadun]

> On Jun 21, 2016, at 2:36 PM, Dave Abrahams <dabrahams at apple.com> 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 <swift-evolution at swift.org> 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.

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

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

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160621/c89c5d9e/attachment.html>