If you could make any changes to D, what would they look like?

[Dukc]

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:
> Just for giggles, without pesky things like breaking changes; 
> rational thinking, logical reasoning behind the changes, etc.
>
> What interesting changes would you make to the language, and 
> what could they possibly look like?

Forgetting "rational thinking, logical reasoning behind the 
changes" - how? Isn't it all rational reasoning in programming 
language design - if we leave it out, what's left? I don't know 
what you meant, so rest of my reply just ignores that part.

The answer is, probably not too much after all. If I really want 
to change something, I can write a DIP. So far I've written only 
one.

Now of course, if I could forget about breaking changes, I could 
propose things I wouldn't otherwise. And I think you meant I 
could do the changes without bothering with the DIPs, so I would 
have more power than I do. But still - I think the DIP process 
keeps me honest on what I really am ready to bother on, so I 
don't think I would change that much stuff even if I could just 
write a spec piece and have it automatically accepted.

Now, were I a full-time BDFL so that I would spend all day on the 
question, some changes I might do:

- Revise `@safe` by default DIP so that `@safe` foreign language 
declarations would deprecated but not immediately removed. One 
more review and then accept it unless a major flaw is found.

- Write a DIP: short integer types auto-promoted to `int`/`uint` 
are implicitly convertible back to original type within the same 
expression. I've been toying with the idea.

- Accept Dennis's unit type DIP when it hits the the formal 
assessment.

- Accept `preview=shortenedMethods` DIP when it hits the the 
formal assessment.

- Write a DIP for `preview=in` and accept it unless a major flaw 
is found (yet I haven't wrote one IRL).

- Phobos should strive to be more decoupled from the compiler and 
runtime. Using internal DRuntime features should not be allowed, 
and the compiler should be able to compile older Phobos releases 
(Haven't tested if this is the case TBH).

- There's a dead letter in the spec that says that `(x) @trusted 
=> {/*...*/}` pattern is allowed only if the lambda is safe 
regardless of the value of the argument and the surrounding 
context. I'd remove that rule.

- Move the ImportC section from the spec to the DMD manual.

- Declaration against the `version(Something) /*...*/ else static 
assert(0, "not supported");` pattern in Phobos and DRuntime. Just 
compile what is implemented and leave other stuff out, instead of 
failing compilation.

- Avoid adding anything major into language without a DIP. I 
would allow myself to write it if no-one volunteers to champion 
the DIP.

Well, It turns out I didn't shake the question of backwards 
compatibility after all. I guess it's because I want to consider 
it - backwards compatibility is part of my D dream.