[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library
dabrahams at apple.com
Fri Jan 29 15:14:00 CST 2016
on Fri Jan 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
> The "too specific" I'm railing against is that naming guidance should not depend on implementation details to
> the point it creates Hungarian Swiftisms.
I understand the overall concern, but I don't think these guidelines do
that. Whether something has side effects is hardly an implementation
> -- E
>> On Jan 29, 2016, at 1:20 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> on Fri Jan 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
>>>>> For example, for "HasNoun", I'd go with something more like
>>>>> NounContainingType or NounSupplier.
>>>>> Non-Abrahams Dave writes: "I like -Type for protocols that can only be
>>>>> used a generic constraint, and -able/-ible for protocols that can be
>>>>> “concrete” types.
>>>>> And Canonical Dave replies: "But that's not how they're used. I'd
>>>>> have to rename Equatable and Comparable to follow that convention."
>>> This is the big bit though and you didn't respond here, although it's
>>> mostly that I'm agreeing with you but what do you think about just
>>> cutting out things that get too specific? (I say the same more or less
>>> in the longer review email)
>> I don't think that's going to fly. One of the main purposes of these
>> API guidelines is to remove the overhead of having to figure out how to
>> name things, at least as much as possible. Programmers and designers
>> have enough to think about. Teams that accept strong and specific
>> coding guidelines can spend more time effectively applying their domain
>> expertise and less time bike-shedding trivial details.
More information about the swift-evolution