[Issue 14301] [2.067-rc1] Private symbols of module conflicts with public from another

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Mar 18 19:15:08 PDT 2015


https://issues.dlang.org/show_bug.cgi?id=14301

--- Comment #10 from Ketmar Dark <ketmar at ketmar.no-ip.org> ---
(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.

--


More information about the Digitalmars-d-bugs mailing list