[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 3:02 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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.
>
> I think
>
> Array<Int>.memoryAlignment 
>
> is quite different to scan than
>
> MemoryLayout(Array<Int>).alignment
>
> (And I obviously like the former a lot more if it wouldn't produce
> semantic confusion -- I assume you mean in the compiler and not
> the reader of the code). 

No, I mean to the reader of the code.  The former might easily be
interpreted as the memory alignment of the elements in the array, for
example.  And the effect is much worse with the counterpart to sizeof.

> That said, I think
>
> memoryAlignment(Array<Int>.self)
>
> reads better than
>
> MemoryLayout(Array<Int>).alignment
>
> You don't have to brainparse(TM by Cognition Inc) two other things 
> before arriving at alignment.  The MemoryLayout feels more prominent
> than it should. The alignment feels less prominent than it should.
>
> I recognize we disagree on this, 

We don't, actually.  I agree that by themselves the APIs you are
proposing look better.

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”).  I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

So, my argument is really about the overall shape of the standard
library and its effect on ordinary users more than the look/feel of
these particular APIs.

> and we're unlikely to convince each other on-list, which is why I
> tried hard to make sure that your alternative was properly presented
> in the proposal. If I have made any errors in expressing your design,
> its intent, and rationale, please let me know and I will edit the
> proposal to fix.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture.  These APIs are not like “map,”
“filter,” and “Dictionary.”  They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

-- 
Dave