On Thursday, 27 May 2021 at 06:08:53 UTC, Ola Fosheim Grostad wrote:
> If that is it, then we might as well close the thread and conclude that dmd is a hobby project.
Which is fair enough. Just don't pretend it aspires to be more than that, because that takes reorganization and restructuring.
Don't forget about the many contributors that have invested thousands of hours to understand and improve the code base :)
While I disagree with many of Walter's arguments here, a refactoring has a lower barrier of entry than a bugfix, and is more prone to be subjective.
It isn't always subjective, as, just like a bug fix, a refactoring can come with a test case. For example, if someone writes a tool that uses DMD as a library, it will be a solid ground to push a change that could otherwise be perceived as subjective. We had work done on trying to make DMD work as a library before, and all we ended up with was a massive amount of duplication. But when such refactoring are driven by use case (e.g. VisualD's usage of DMD), they are easy to justify and accept.
Now to talk about what can be done to improve the DMD codebase, it's fairly obvious: ELIMINATE ALL CASTS. But not by replacing cast(XXX)e with e.isXXX(), but by actually using proper encapsulation.
What I mean is that instead of switching on types, like this:
if (auto tf = t.isTypeFunction())
(cast(FunctionDeclaration)t.sym).something();
else if (auto td = t.isTypeDelegate())
(cast(FunctionDeclaration)(cast(TypeFunction)t).sym).something();
else
// Something else
We should switch on capabilities. We currently "suffer" from abstraction: almost everything is a Type, Dsymbol, Expression, etc... but then when we do semantic we have to cast or isXXX it all over the place. Functions that are only supposed to accept CallExp or BinExp end up accepting an Expression because somewhere, a field that should be CallExp or BinExp is stored as an Expression, or because we don't have the proper return type on a function, etc...
There are simple areas where one can start, for example making all aggregate have the most specialized type possible: TypeDelegate.nextOf() should return a TypeFunction, not a Type. FunctionDeclaration.type() should be a property that gives you a TypeFunction, not a Type, etc...
Permalink
Reply
