> 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
