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

[Erica Sadun]

> On Jun 29, 2016, at 9:37 AM, 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:
>> 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.

Don't forget QuickHelp and module interfaces, which automatically list attributes along with the declaration.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/ef15be0d/attachment.html>