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

Charlie Monroe charlie at charliemonroe.net
Fri Jun 24 09:26:33 CDT 2016


> On Jun 24, 2016, at 4:11 PM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Vladimir.S via swift-evolution <swift-evolution at ...> writes:
> 
>> Do you mean *sorted*(by:) ? Or I'm missing something in naming rules?
> 
> IIRC, sort is mutating and sorted is nonmutating (copying) version.
> Also, I forgot `initial` parameter in `reduce`.
> 
>>> Data flow is an area where code becomes the less understandable when
>>> more visual clutter is added. In my opinion,
>>> 
>>> array.filter(isEven).map(square).reduce(sum)
>>> 
>>> reads better than
>>> 
>>> array.filter(suchThatTrue: isEven).map(applyingTransformation:
>>> square).reduce(accumulatingResultBy: sum)
>>> 
>>> What do you think?
>> 
>> +100. I even want to brought the term-of-art argument here. IMO These 
>> functions are expected to be called without any parameter names.
> 
> That would probably be a good scenario, but core team needs to release 
> their grip on strictly following new naming conventions.

I know it might not exactly by the naming conventions, but have you considered

filter(predicate:) // Though it might get confused with (NS)Predicate?
map(transform:)
reduce(accumulator:)

All of this may be extended to follow the convetions:

filter(usingPredicate:)
map(usingTransform:)
reduce(usingAccumulator:) // or applyingAccumulator?

But I agree the label-less argument here reads best.



> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list