> try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues Orthogonality is one of

> try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues Orthogonality is one of the key design goals of go. That means a) keep the intersections of use cases of features low and b) maximize the space you can span with them. Having "contained solutions" will inevitably lead to a more complicated language (infinitely many contained problems with a contained solution each means diverging number of contained solutions) and won't span a large problem space by definition. You want to solve as many problems as possible with as little features as possible. > As for being really annoyed if there were warnings, that was exactly my point. :) Label them as something more specific (a solution to the repair problem) and make it difficult to use them for something else. You misunderstood my point. You are not making it difficult, you are simply making it annoying (to both me and my users). Warnings would have exactly zero influence on how much and for what I would use aliases in practice (thus totally failing your goal), they would just make me hate the person who proposed them (dunno. Maybe that's a plus for you? Doesn't seem like that to me). Solving many problems with one solution is not a bug, it's a feature. Interfaces do not only solve one problem. Embedding doesn't only solve one problem. A language feature that only has one specific use case is just a wart. For example: python's "pass" keyword is an incredible wart. It's only use is, to make the language unambiguous to the parser, but it doesn't actually serve any purpose. At the same time, you are putting in a keyword; no one will ever be able to use that as an identifier. The same, actually, goes for a lot of other features of python. It's pretty much the epitome of insular features: http://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...