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

[Patrick Smith]

+1 to MemoryLayout, as I do like how it is namespaced under one type, which allows straight forward looking up of documentation. Writers from C or other sizeof() languages will able to see all available methods, allowing them to be educated to say not go for size but interval/spacing as the better choice.

Patrick

> On 22 Jun 2016, at 10:26 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> 
>> 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.
> 
> See? That, I totally get.
> 
>> 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
> 
> Would you like me to edit it and flip the proposal then? Put the MemoryLayout in as primary,
> mine as secondary, and add in text to explain that the motivation is less usability than serving
> an unsafe API with minimal surface area?
> 
> -- E
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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