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

Janosch Hildebrand jnosh at jnosh.com
Mon Feb 1 15:26:46 CST 2016

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)`.

* What is the rationale for moving `unsafeUnwrap` into Optional but not `unsafeAddressOf` into AnyObject? 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...

* 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 :-)

* Typo: 
> +  public func take() -> Memory // Should be Pointee

- Janosch

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

More information about the swift-evolution mailing list