on Wed Jun 29 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution >> <[email protected]> wrote: >> >> >>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> > >>> >>> I've updated my pull request with a much more conservative set of >>> changes that preserves/restores label-free-ness for all “term of art” >>> functional methods such as filter and reduce. >>> >>> https://github.com/apple/swift/pull/2981 >>> >>> My current thoughts are that many of the `by:` labels are awkward and >>> not adding much. Perhaps they all ought to be omitted. >> >> >> I'd be happy to see `by` labels go away, whether first or trailing. I'm not >> sure why Swift 3 wants >> to have so many extra labels when a very simple phrase is understandable on >> its own >> (e.g. max, min, sort, sorted). >> >> Is it possible under the Swift umbrella to do the same for split since it >> has the rarely used >> maxSplits, and omittingEmptySubsequences params? It would give you >> `split({$0 == " "})` >> and `split(atWhitespace)`. >> >> Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a >> placeholder? >> If the former, I have opinions (new lines, new lines and whitespace) >> >> The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" >> intentionally? >> If so, no worries. If not, helpful ping. >> >> Future Extensions: >> >> * reduce(_:, combine:) // way simpler >> >> * "The argument against changing other names to be more consistent with API >> guidelines >> is weakened. " >> >> I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, >> where >> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` >> offers >> a substitutable alias for fp aficionados. >> This approach is not anything I've ever seen previously in a programming >> language but >> its something that jumps out as a way to satisfy two distinct audiences of >> users >> that would have limited impact but a decided advantage. > > 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. Yeah, I'd rather not do that. > 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). > > 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. +1 > 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. > > But my hunch is that this introduces more complexity than value. > >> >> That said, I don't like `mapping` and `flattened`. If they're going to be >> Swiftized, go with >> names that aren't standing in the "term of art" rubble: transform, squeeze, >> whatever. >> >> -- E >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
