<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 11:01 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="HOEnZb"><div class="h5"><br class="">> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">><br class="">>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">>><br class="">>><br class="">>> I've updated my pull request with a much more conservative set of<br class="">>> changes that preserves/restores label-free-ness for all “term of art”<br class="">>> functional methods such as filter and reduce.<br class="">>><br class="">>><span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift/pull/2981" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift/pull/2981</a><br class="">>><br class="">>> My current thoughts are that many of the `by:` labels are awkward and<br class="">>> not adding much. Perhaps they all ought to be omitted.<br class="">><br class="">><br class="">> I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants<br class="">> to have so many extra labels when a very simple phrase is understandable on its own<br class="">> (e.g. max, min, sort, sorted).<br class="">><br class="">> Is it possible under the Swift umbrella to do the same for split since it has the rarely used<br class="">> maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`<br class="">> and `split(atWhitespace)`.<br class="">><br class="">> Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?<br class="">> If the former, I have opinions (new lines, new lines and whitespace)<br class="">><br class="">> The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?<br class="">> If so, no worries. If not, helpful ping.<br class="">><br class="">> Future Extensions:<br class="">><br class="">> * reduce(_:, combine:) // way simpler<br class="">><br class="">> * "The argument against changing other names to be more consistent with API guidelines<br class="">> is weakened. "<br class="">><br class="">> I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where<br class="">> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers<br class="">> a substitutable alias for fp aficionados.<br class="">> This approach is not anything I've ever seen previously in a programming language but<br class="">> its something that jumps out as a way to satisfy two distinct audiences of users<br class="">> that would have limited impact but a decided advantage.<br class=""><br class=""></div></div>Aliasing methods is pretty common in Ruby. The advantage is that you can select the alias that reads best at a specific call site. The disadvantage is that everyone has to learn more than one name for the same thing.<br class=""><br class="">If we’re going to allow aliases I think it should be in support of clarity at specific call sites. I think the hurdle for this is pretty high and I’m not sure we would find the benefits to outweigh the drawbacks, but it is a discussion we could have. I would want to see concrete examples (which could be drawn from Ruby code).<br class=""><br class="">I don’t think we should do this just to support term-of-art aliases where we believe we have a different name that fits Swift better. This creates “dialects” which I believe is a stated anti-goal of Swift.<br class=""><br class="">It may turn out that existing terms of art provide enhanced clarity in some contexts and more Swifty names in others, in which case the alias may make sense. But it if we add them it should be done on the grounds of clarity and be accompanied by guidelines regarding which name to choose.<br class=""><br class="">But my hunch is that this introduces more complexity than value.<br class=""></blockquote><div class=""><br class=""></div><div class="">Agreed. I'd have to be convinced that having aliases provide overwhelming wins at the call site that could not be achieved through renaming. Although aliasing could be very neat in certain circumstances, I fear that admitting such a facility to the language is an "out" that would discourage exploration of the most appropriate method names and consensus-building in favor of "you'll have yours and I'll have mine," which would be fatal for building a coherent set of APIs.</div></div></div></div></div></blockquote><div><br class=""></div><div>My experience with Ruby has been primarily writing scripts for my own use. If we’re going to consider aliases it would be great to hear about how this has impacted larger teams and the broader Ruby community. I’m not sure whether it is viewed as a net win or a source of confusion. I don’t think the situation is quite as dire as you fear, but it is a very valid concern.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="HOEnZb"><div class="h5"><br class="">><br class="">> That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with<br class="">> names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.<br class="">><br class="">> -- E<br class="">><br class="">><br class="">><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>