[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library

[Dave Abrahams]

on Tue Feb 02 2016, Radosław Pietruszewski <swift-evolution at swift.org> wrote:

>>>> 
>>>>> I'm generally in favor of the proposed changes. I'll just note some
>>>>> minor points and disagreements:
>>>>> 
>>>>> * Like I mentioned in my SE-0023 review, I would be OK with keeping
>
>>>>> the "Type" suffix for protocols but have no strong preference.
>>>>> 
>>>>> * I'm in favor of keeping `precondition()`. `require()` might be
>>>>> easier to grasp at first but personally I really came to like
>>>>> `precondition()`.
>>>>> It fells both precise and I prefer the passive `precondition()` to the
>>>>> active `require()` for this case. To me it fits the primary meaning
>>>>> better; stating an API contract. The fact that the condition is
>>>>> actively checked is secondary to that.
>>>>> 
>>>>> * I also agree with Radosław in that I prefer `removeAll(keepCapacity:
>>>>> Bool)` to `removeAll(keepingCapacity: Bool)`.
>>>> 
>>>> Why?
>>>> 
>>>> I had a hard time justifying "keeping" to myself for a while, but
>>>> eventually I realized that this pattern is less ambiguous, at least in
>>>> general, since many verbs are also nouns.  Okay, "keeps" haven't been
>>>> considered high-tech construction elements since the middle ages, but
>>>> it's easy to understand how you'd be interested in the capacity of a
>>>> keep.
>>> 
>>> Why not, though? adding `-ing`s in this context has all of the
>>> problems -ed/-ing has with method names, 
>> 
>> Which problems, sorry?
>
> A bit of extra spelling gymnastics… Maybe I’m the only one bothered by
> this, but I’d just prefer a shorter/simpler name in absence of a
> compelling reason to do otherwise. (You did make an argument for why
> in a later post, fwiw. I’m not super compelled by it, but also don’t
> feel so strongly against the `ing` to argue further ;) )
>
>> 
>>> and none of the necessity of conveying mutability information.
>>> 
>>> What’s wrong with “keepCapacity” as a parameter name?
>> 
>> It can be interpreted as denoting the capacity of the keep.
>
> Wow, that… would have never crossed my mind ;)

It's a terribly anachronistic example, but it's not hard to think of
others that aren't so terrible.

>> 
>>>>> * What is the rationale for moving `unsafeUnwrap` into Optional but
>>>>> not `unsafeAddressOf` into AnyObject? 
>>>> 
>>>> Language limitation: AnyObject can't be modified or extended.
>>>> 
>>>>> I can certainly see the safety argument against moving it but I don't
>>>>> see how that would apply to `unsafeAddressOf` but not `unsafeUnwrap`?
>>>>> 
>>>>> * `EnumeratedSequence` and `Repeated` feel weird to me. They make
>>>>> sense given the API guidelines and the previous `EnumerateSequence`
>>>>> and `Repeat` were a bit clunky as well but these somehow feel a bit
>>>>> worse... That might be wholly subjective though and I don't really
>>>>> have a good suggestion. The only thing that came to mind was
>>>>> `EnumerationSequence` and `Repetition` but I'm not overly fond of
>>>>> those either especially not to the point of deviating from the norm...
>>>> 
>>>> Yes, they're a little clunky.  No, I don't have any better ideas either
>>>> :-)
>>>> 
>>>>> * This is not a disagreement but I'd be interested in hearing the
>>>>> reasons for replacing Generator(Type) with Iterator(Protocol) if
>>>>> someone finds the time. I can speculate of course but it's probably
>>>>> easier for someone to give me a short summary :-)
>>>> 
>>>> I think these messages give all the details:
>>>> 
>>>> http://news.gmane.org/find-root.php?message_id=m2h9i4gffx.fsf%40eno.apple.com
>>>> http://article.gmane.org/gmane.comp.lang.swift.evolution/5344
>>>> 
>>>>> * Typo: 
>>>>>> +  public func take() -> Memory // Should be Pointee
>>>> 
>>>> Nice, thanks.
>>>> 
>>>> -- 
>>>> -Dave
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave