https://issues.dlang.org/show_bug.cgi?id=14301
--- Comment #10 from Ketmar Dark <[email protected]> --- (In reply to Martin Nowak from comment #9) > It's also highly > debatable to remove the aliases and by this time a lot of people rely on > them. this is the root of the problem, yes. this is exactly why c++ is crap: "we can't change our old decisions and fix broken things, 'cause there are alot of people who are using those things!" this is one of the reasons why D is so little used after many years of developement. D has alot of great features, and some broken features. that broken features *can* be fixed, there is no committee that has to accept new stadard. and there are not so much vital D code. some of that features aren't even in specs. yet instead of fixing that features here and now there is a continuous process of augmenting that features with various workarounds. yes, those fixes will break some code. but refusing to fix 'em will leave features broken forever, as there are more and more code that rely on broken things. i'm using Kenji's patch for a long time now, and it works perfectly. yes, there are some broken code in various D projects, and that code is *really* broken, it works by accident (due to flaws in module system). most project authors happily accepts patches that adds missing imports, and code becomes better and with better "import locality". yes, fixing that code requires some effort. but migrating from one version of compiler to another version is not seamless too, so i can't see this as a real blocker. it should be done once, and it will solve a wide range of import bugs for future versions. Kenji's work is complex, but it fixes imports once and forever. more than that, is makes D better and easier to use. i believe that D is still in position where D developers can think more about future users than about not breaking the code that will breaks anyway after two compiler releases. --
