[swift-evolution] Take 2: Stdlib closure argument labels and parameter names
Dave Abrahams
dabrahams at apple.com
Wed Jun 29 13:21:09 CDT 2016
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 <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.
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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
More information about the swift-evolution
mailing list