Let&#39;s not go through more churn with `pointee`. It&#39;s already just been changed from `memory`.<br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 22, 2016 at 21:02 Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><div><blockquote type="cite"><br><div><div><br>Hi All,<br><br>A couple of weeks ago we started to notice that we had some poorly-named<br>closure parameters and argument labels in the standard library, so we<br>did a complete audit of the standard library&#39;s APIs and came up with a<br>preliminary proposal for changes, which we applied in a branch and you<br>can review in <a href="https://github.com/apple/swift/pull/2981" target="_blank">https://github.com/apple/swift/pull/2981</a>.  Let&#39;s please<br>carry on further discussion here rather than in the pull request, though.<br></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div><div><div><b>-  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)</b></div><div><b> -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)</b></div><div><b> -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both `true`, then</b></div><div><b> -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)</b></div><div><b> +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)</b></div><div><b> +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)</b></div><div><b> +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both `true`, then</b></div><div><b> +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)</b></div></div><div><br></div><div>I like this change!</div><div><br></div><div><b>-    func forEach&lt;S: SequenceType&gt;(_ body: (S.Iterator.Element) -&gt; ())</b></div></div><div><div><b>+    func forEach&lt;S: SequenceType&gt;(invoke body: (S.Iterator.Element) -&gt; ())</b></div></div><div><br></div><div>Adding an external label makes sense here. This is a procedural call and</div><div>using it within the parens should have a &quot;code ripple&quot;.</div><div><br></div><div>That said, would prefer `do` or `perform` over `invoke` or `invoking` as in</div><div>`runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. This also applies</div><div>where there&#39;s a `body` label instead of an empty external label.</div><div><br></div><div><b>-public func withInvalidOrderings(_ body: ((Int, Int) -&gt; Bool) -&gt; Void) {</b></div><div><div><b>+public func withInvalidOrderings(invoke body: ((Int, Int) -&gt; Bool) -&gt; Void) {</b></div><div><b><br></b></div><div>For any with/external label pair, I&#39;d prefer `with-do` or `with-perform` </div><div>over `with-invoke`.</div></div><div><b><br></b></div><div><b>-  return IteratorSequence(it).reduce(initial, combine: f)</b></div><div><div><b>+  return IteratorSequence(it).reduce(initial, accumulatingBy: f)</b></div></div><div><br></div><div>For `reduce`, I&#39;d prefer `applying:` or `byApplying:`</div><div><br></div><div>Similarly in `starts(with:comparingBy:)`, I&#39;d prefer byComparing`,</div><div>min/max, byOrdering</div><div><br></div><div><div><b>-      ).encode(encoding, output: output)</b></div><div><b>+      ).encode(encoding, sendingOutputTo: processCodeUnit)</b></div></div><div><br></div><div>How about `exportingTo`?</div><div><br></div><div><br></div><div><div><b>-  tempwords.sort(isOrderedBefore: &lt;)</b></div><div><b>+  tempwords.sort(orderingBy: &lt;)</b></div></div><div><br></div><div>With `sort` and `sorted`, I&#39;d prefer `by:`</div><div><br></div><div><div><b>-  if !expected.elementsEqual(actual, isEquivalent: sameValue) {</b></div><div><b>+  if !expected.elementsEqual(actual, comparingBy: sameValue) {</b></div></div><div><br></div><div>I&#39;m torn on this one. I don&#39;t like but I don&#39;t have a good solution.</div><div><br></div><div><div><div><b>-  /// for which `predicate(x) == true`.</b></div><div><b>+  /// for which `isIncluded(x) == true`.</b></div></div><div><div><div><b>-      _base: base.makeIterator(), whereElementsSatisfy: _include)</b></div><div><b>+      _base: base.makeIterator(), suchThat: _include)</b></div></div></div><div><b><br></b></div><div>How about simply `include` for both? I get the `is` desire but it&#39;s being tossed away</div><div>in a lot of other places in this diff. and `suchThat` feels out of place.</div></div><div><br></div><div><div><div><b>-      || u16.contains({ $0 &gt; 127 || _isspace_clocale($0) }) {</b></div><div><b>+    || u16.contains(elementWhere: { $0 &gt; 127 || _isspace_clocale($0) }) {</b></div></div><div><br></div><div>I assume the challenge here is differentiating contains(element) from contains(closure).</div><div>This feels predicate-y, which is why I put it near the predicates. But I think something</div></div><div>like `containsElement(where:)` works better.</div><div><br></div><div><b> -    let result = try base._withUnsafeMutableBufferPointerIfSupported(body)</b></div><div><div><div><b>+    let result = try base._withUnsafeMutableBufferPointerIfSupported(invoke: body)</b></div></div><div><br></div><div>I hate &quot;ifSupported&quot; but that&#39;s another discussion (withSupportedUnsafeMutableBufferPointer,</div><div>withAvailableUnsafeMutableBufferPointer, it&#39;s all lipstick)</div><div><br></div><div>This is procedural, so `do` or `perform` rather than `invoke`</div></div><div><br></div><div><div><b>-      for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {</b></div><div><b>+      for test in removeFirstTests.filter(</b></div><div><b>+        suchThat: { $0.numberToRemove == 1 }</b></div></div><div><br></div><div>The difference between `filter` and `forEach` is that `forEach` is explicitly </div><div>procedural while `filter` is functional.  I do not like functional chainable</div><div>calls being modified to use explicit external labels in this way. </div><div><br></div><div>I&#39;d prefer no label here.</div><div><br></div><div><div><i>public func split(</i></div><div><i>      maxSplits: Int = Int.max,</i></div><div><i>      omittingEmptySubsequences: Bool = true,</i></div><div><b>-    isSeparator: @noescape (Base.Iterator.Element) throws -&gt; Bool</b></div><div><b>+    separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws -&gt; Bool</b></div></div><div><br></div><div>I&#39;m torn on this one. It&#39;s not the worst ever but something more like where/at/when</div><div>makes more sense to me than &quot;separatedWhere/separatedAt/separatedWhen&quot;.</div><div><br></div><div><div><div><b>+      count: __manager._headerPointer.pointee.count)</b></div></div></div><div><br></div><div>For the sake of Zippy the Pinhead, surely there has to be something better than `pointee`.</div><div>Like...`reference`?</div><div><br></div><div><div><br></div></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>