How can we make it easier to experiment with the compiler

[sighoya]

On Tuesday, 25 May 2021 at 16:00:32 UTC, Alexandru Ermicioi wrote:
> On Tuesday, 25 May 2021 at 08:32:46 UTC, sighoya wrote:
>> You can't encode the full semantic into one function name with 
>> parameter names without to over blow these names.
> In this case, it might be good to have a documentation comment, 
> otherwise behavior should be known from the function name and 
> args.

Agree.


> Having such comments inside function body, means you've failed 
> to make the code easy to read and understand. Instead of such 
> inline comments, consider extracting that piece into a function 
> with right name.

It's a trade-off. Over modularization can also be a mispattern as 
it significantly reduces locality.
The other point is how to deal with dynamic context which may 
solved with templates, what a hack.
Anyhow, you don't always code very high level, sometimes a bit 
more low level or indirect, then it's good to have some thread to 
follow.

> Adding such comments should be the last option in your decision 
> on what to do with that piece of code.

Naming is more important, definitely. But succinct comments for 
small sections aren't that bad and are sometimes better than to 
modularize it with a function:

```D
void firstAddToThenUpdateStructureThenFinalize...
```

Giving a shorter and a more non-functional name to this function 
would be ok but is sometimes too general to understand it in your 
context.
Splitting this function in smaller parts may work to name these 
operations shorter, but the point is the context, it's not always 
clear even with correct semantic naming which is mostly not 
possible without to be too general.

It's like commit messages, I like to commit first with the 
technical detail:

```
Update ClassA:
```

Then in the next lines I add some points describing newly added 
semantics which is too much to compact it into one single line.

If you could add context otherwise, this would be pretty good, 
for instance Swift parameter labels are a first step into the 
right direction:

send(message:"Hello World",from:"Earth",to:"Mars")


> Note that most probably next dev, if he changed that piece of 
> code, will most probably just forget updating that comment, 
> meaning that it will tell a lie instead of truth.

Yes, but I can argue with the same for modularization, if someone 
changes the body without to rename the function failed the same 
way.