How can we make it easier to experiment with the compiler?

[Mathias LANG]

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:
```D
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...