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

[Radosław Pietruszewski]

>>> 
>>>> 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 ;)

> 
>>>> * 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160202/101b5305/attachment.html>