on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> 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).
Well, it's simple: the labels aren't extra because x.sort(y) sounds like
x is sorting y.
> Is it possible under the Swift umbrella to do the same for split since
> it has the rarely used maxSplits, and omittingEmptySubsequences
> params?
? AFAICT a decision about dropping the label has nothing to do with
those other parameters
> It would give you `split({$0 == " "})` and `split(atWhitespace)`.
It wouldn't, because your predicate that identifies whitespace is not
going to be called, “atWhitespace”
> Speaking of isAllWhitespace, would this be a prebuilt enumeration or
> is it a placeholder?
It's not an enumeration; we're talking about closure parameters,
remember? It's a hypothetical predicate:
func isAllWhitespace(_: String) -> Bool
> If the former, I have opinions (new lines, new lines and whitespace)
>
> The managed buffer, are you "makingValueWith" instead of
> "makingHeaderWith" intentionally?
Yes, because the change from “Value” to “Header” is a separate proposal
that you have kindly written up for me.
> 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.
>
> 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.
Separate discussion, but thanks for the input. Let's handle that stuff
in a separate review. I should probably strip it out of the pull
request text.
--
Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
