+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@swift.org> wrote: > > >> On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrah...@apple.com >> <mailto:dabrah...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
