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 <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
