<div dir="ltr">On Wed, Jun 29, 2016 at 11:19 AM, Sean Heber <span dir="ltr"><<a href="mailto:sean@fifthace.com" target="_blank">sean@fifthace.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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.<br>
<br>
</span>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).<br>
<br>
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)<br></blockquote><div><br></div><div>I disagree with your interpretation of "Swifty" here. I understand the supreme aim for Swift naming to be clarity, especially at the call site. In some places, that would require Obj-C/Cocoa-like verbosity; in others it calls for terseness. In some places, it should read more "fluently", in others not as much (e.g. arguments inside `init()` omit the classic preposition "with"). So I would disagree that we should make concessions to "fluency" but rather to clarity. And as for clarity, two names for the same thing are, ipso facto, less clear than one, which is why I argue that the wins would have to be "overwhelming".</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>I was more writing in relation to the topics discussed here--i.e. stdlib and corelibs naming--and not so much in relation to user code. Within an API, I'd argue there should very much be only one "language", especially given that any particular program may ultimately use many frameworks, since one "language" from each framework could already be a lot to handle.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>See, here I would be precisely against that use for aliasing. For your own code and as an extension, maybe. But as I argue above, definitely not for stdlib and definitely not at the point of declaration.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
l8r<br>
<span class="HOEnZb"><font color="#888888">Sean<br>
<br>
</font></span></blockquote></div><br></div></div>