TL;Must read

https://www.scala-lang.org/blog/2025/03/24/evolving-scala.html

By Martin Odersky

Safety and convenience mentioned.
Many points look similar to D actually - too similar I would say..
Maybe they are just common for niche non-mainstream and complicated languages

On Monday, 24 March 2025 at 17:14:00 UTC, Sergey wrote:

This is where the two languages are very different:

D's unwillingness to break anything is killing the language. Not even Walter can push changes through. As came up in the YouTube video discussion, you can't compile .h files because a few people aren't willing to change their build process to add another flag. Scala won't have that problem.

On Monday, 24 March 2025 at 18:27:04 UTC, Lance Bachmeier wrote:

Maybe change the implementation of "import" to first try a variation of the literal name, but with '.' encoded by some other, otherwise illegal character (e.g. '/').

Then one could use something like:

module foo.bar;

import std.stdio;
import some-c-header/h; // Interpreted as the file "some-c-header.h"

The other alternative would be to extend the grammar such that the Import clause of the import declaration (spec section 5.2) allows a quoted module name (i.e. ModuleFullyQualified name term preceded and followed by a literal dounle quote character).

The latter then being interpreted as a literal file path in which to look. Additionally only allow if for a limited set of literal extensions (initially '.c' and '.h').

Hence that would allow something like:

module foo.bar;

import std.stdio;
import "some-c-header.h" // Interpreted as the file "some-c-header.h"
import "somedir/somefile.c"

As to how difficult that would be to implement in the compiler, I've no idea.

If I understand the current grammar, then that is currently illegal, and so the change would not be backward incompatible.

On Monday, 24 March 2025 at 18:27:04 UTC, Lance Bachmeier wrote:

I thought the issue was that the change by itself would break code. Some people had proposed a switch that could control the priority of how the .h files would be imported, but the idea of a switch kind of got dropped, never agreed on and never implemented.

On Tuesday, 25 March 2025 at 11:54:45 UTC, jmh530 wrote:

From reading history, it seemed that the original form broke stuff in e.g. GCC because there were auto generated .h files being imported in preference to .d files.

Then Iain proposed a two pass approach, and apparently Walter didn't like it for performance reasons. Then the idea of fixing this died a death. There was also mention of allowing the functionality under a different syntax, but it seemed to peter out, or possibly be ignored,

Personally, the performance argument carries no weight for me - it is about functionality.

It just struck me that the different grammar approach, using something which would not compile now, and so would not break backward compatibility should be the obvious way forward.

However that (for some reason) was not pursued, and so in effect the whole ImportC while being a very good idea, has ended up (IMHO) with a half baked implementation, to the point of not being practical except in toy demonstrations.

On Tuesday, 25 March 2025 at 20:55:30 UTC, Derek Fawcus wrote:

I would say that it's like 99% there. But sometimes you need 100% before people will sit up and take notice.

On Wednesday, 26 March 2025 at 12:24:49 UTC, jmh530 wrote:

In terms of the technology, I'd agree - but that is not why I view it as half baked.

If this* from over 2 years ago was the last serious attempt to add the missing piece, then it rather looks to me as if there are governance/management issues in the project. Digging in to the history of how ImportC came about, and its road to get as far as it has only reinforces that impression. Which all seems rather sad.

* https://github.com/dlang/dmd/pull/14864