On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution < [email protected]> 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. > > 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. > > 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. > 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. > > > > 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
