[swift-evolution] Take 2: Stdlib closure argument labels and parameter names

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> 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
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/9510f1a5/attachment.html>