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

[Sean Heber]

I wasn’t aware of this being a thing in Ruby - interesting! Perhaps it is not so untested territory after all. :) Would be interesting to see if whatever prompted your hatred of it there is due to how it works in Ruby vs. the idea itself or not, though. Not sure how one would go about determining that, though. Or if that’d even be a useful result.

l8r
Sean


> On Jun 29, 2016, at 12:14 PM, David Hart <david at hartbit.com> wrote:
> 
> I have experience using aliases in Ruby and they are one of the aspects of the language I hated with a passion. They can be very confusing, and increase the difficulty of learning the APIs and QuickHelp is not always there to help. To me, they sound like a convenience for the code writer but a nuisance of the reader. And Swift has always tried to improve its readability over its writability.
> 
> On 29 Jun 2016, at 18:19, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> 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.
>> 
>> It would probably be quite difficult to prove (although that doesn’t mean it isn’t worth trying) that aliases would be an overwhelming win because everyone has different tolerances for impedance mismatches. In many ways, it is that difference of tolerance that is the issue here (and in a few other threads).
>> 
>> I personally have no desire to fragment things more than necessary, but I also really want code to read fluently. These goals seem to be at odds and, I speculate, they are at odds in ways that are impossible to solve with a single solution. Human languages have a lot of redundancy and variety for a reason, and we’ve taken the stance that Swift should read with a kind of “flow” that we usually only associate with human languages. This means that there are likely going to have to be concessions made to Swift that one might not ordinarily see in a programming language. (IMO)
>> 
>> The argument that aliases would be “fatal” for building coherent API doesn’t seem to tell the whole story to me. After all, every program ultimately has it’s own “language” of sorts that is built up from the building blocks of the standard library and other included frameworks. There’s a unique mix of the usage of certain words, constructs, names in each program that is a reflection of the programmers who have built the program and each one reads differently no matter how hard we might try to have only “one true way” to express a thing.
>> 
>> To me, one of the nicer aspects of having aliases encoded in the API as function attributes is that, in the case of the standard libraries, they would be decided and bikeshedded by the usual suspects and then effectively locked into place. There’s still control on the extent of use of this feature. You cannot add an alias by way of an extension in your own code, for example, and I think that’s a fine tradeoff. It would be surgically used and, mostly, only by the core team/standard lib API designers and by those who wish to experiment. I don’t know if that’s a big win or not. To me, this feels like mostly untested territory.
>> 
>> l8r
>> Sean
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>