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

[Dave Abrahams]

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Regarding the issue of existential metatypes with sizeof:
>> 
>> Pyry Jahkola points out one instance where the memorySize(type(of:
>
>> …)) workaround won't work. When the value is an existential, it's
>> illegal to ask for the size of its dynamic type: the result can't be
>> retrieved at compile time:
>> 
>> let i = 123
>> let c: CustomStringConvertible = i
>> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
>> 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.

-- 
Dave