[swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Chris Lattner]

On Jan 3, 2016, at 3:43 PM, Tino Heth <2th at gmx.de> wrote:
>>> Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity — but as it is now, we should hold transparency in high esteem and not start faking democracy.
>> 
>> I’m confused, what are you saying?  No decision has been made here, I’m not aware of any “secrecy” issue.
> Sorry, it could be that my words don't express exactly what I wanted to say.

No problem at all, I just wanted to clarify your meaning and intention, thanks!

> For me (I guess for others as well :) the decision process is a black box, but I expect the proposals have impact on it — so proposers have some responsibility.
> Loïc and I already had a short conversation, and I have no accusations against him, but rather wanted to criticize a tool that can be instrumentalized easily:
> There has been a poll about which keyword to choose as replacement, and that made his proposal the target for my word of warning…
> 
> I guess most of us agree that surveys have to be taken with a grain of salt, and I think their use should be discouraged for most situations.
> Polls itself can be manipulated in many ways (bias of the author, fake votes…), and there are no rules how to handle the result (an author could cite a survey that supports his standpoint, but he might as well ignore a result he doesn't like).
> 
> Of course, the core team is not bound to the result of any vote, but bad decisions aren't my main concern:
> I don't know how this community will evolve, but I guess there will be natural controversy in the future, there will be temptation to support opinions with unfair methods — and there will be people suspecting or accusing others of using such methods…
> 
> All those bad things are most likely unavoidable, but clear rules could help keeping them at bay.

There is no simple answer here.  Core team members are humans and have different things that impact and motivate them.  We intentionally want Swift to have a common “center of gravity” and be an “opinionated” language, rather than fall to the “design by committee” approach that leads to a watered-down design.  This means that decisions are really all shades of gray and cannot be specified or predicted by algorithm.  We aim to be as transparent as possible, and explain the rationale for decisions when they come out.

That said, I and many other people on the team are highly motivated and effected by clear descriptions of problems being solved, and why current approaches are wrong.  Particularly moving are things written by people who are clearly familiar with Swift as it stands, and who speak to why a change will make Swift better.   Someone saying “I saw thing X in language Y, so we should transplant it to Swift” - with no further justification - is not very motivating, because Swift is much different than any other language Y, and so the tradeoffs that make it compelling in Y may not translate over to make it compelling in Swift.

> So, I hope my language has been better this time, and that Swift grows up to be a healthy open source project with a great community! (and to make sure I don't get things wrong again: It is already quite healthy and great ;-) 

Me too.  We are definitely all new to this and learning as we go along.  I’m sure that we’ll all make mistakes, but we aim to learn from them and adapt & change when we do.  Please have patience as this inevitably happens, it is because we’re just humans, and all jointly trying to make Swift as great as we can!

-Chris