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

[Dave Abrahams]

on Tue Jun 21 2016, Erica Sadun <swift-evolution at swift.org> wrote:

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

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