Thing is, we have had multiple versions being maintained up till now.

Iain has been doing an absolutely wonderful job essentially creating an LTS frontend and we didn't bother ship a LTS version of dmd.

We discussed this last night on Discord, and I made this very point. If he says we can do it, then we can do it. He has the experience for it.

On Tuesday, 17 May 2022 at 05:37:20 UTC, StarCanopy wrote:
>
> Then fund it, or if you have insufficient monetary resources to effect anything substantial, assist in organizing a group to sponsor libraries written in D. That is, if you truly want to achieve your goals.
>
> P.S. While I often apply @safe at module-level, the GC and bounds-checking already accomplish a lot by themselves in my experience.

I think advancing my goals towards safer programming practices, can best be achieved by encouraging programmers to 'opt out' of safe, rather than 'opt in' to safe.

Until @safe is default in D (if ever), this can be accomplished right now, by everyone making the first line in every module they create, to be -> @safe:

Now. They have to make a conscious decision to 'opt out' of @safe. And now, they become responsible for the consequences.

At the moment, since @safe is not default, D is responsible for the consequences ;-)

On 18/05/2022 12:41 AM, Siarhei Siamashka wrote:
> On Tuesday, 17 May 2022 at 07:06:47 UTC, rikki cattermole wrote:
>> Iain has been doing an absolutely wonderful job essentially creating an LTS frontend and we didn't bother ship a LTS version of dmd.
> 
> Do you mean that the 2.076 frontend from GDC 9/10/11 can be essentially treated as a D language "edition 2017"? I actually like the idea, even though I can see a few challenges that can make everything a bit complicated.

Could have been yes. I wouldn't suggest that we do it now though.

On Thursday, 5 May 2022 at 23:06:26 UTC, Walter Bright wrote:
>
> Surely you can see that there must have been SOME difference there, even if it was just perception.

I grant you that D packaged the concept neatly, so there is a practical difference.

>
> It was D that changed that perception. Suddenly, native languages started implementing CTFE.

Looks like I'm not getting my well-deserved beer. ((

On 5/16/2022 11:26 PM, Siarhei Siamashka wrote:
> Walter is very much hyped about ImportC. But his solution needs to be objectively compared to the other existing solutions, rather than pretending that it's a unique groundbreaking innovation which will finally make D language popular.

It's conceptually equivalent to C++ being able to #include C files. I was in the business when C++ came out, and am pretty certain this was crucial to C++'s early adoption success. ImportC cannot be as as good as that (preprocessor issues), but it's closer than any of the other solutions I've seen.

For another language doing the same thing, see Kotlin, which can seamlessly interact with Java, and this has been crucial to Kotlin's adoption.

How is ImportC unique? No other solution I've seen is as simple as:

    import mycfile;

These things matter.


Feel free to compare ImportC with other existing solutions, and post your results!

Note that ImportC can inline C functions, and ImportC code can import D code and access D constructs. Who else does that? (Not even C++! Maybe Kotlin can.)

On 5/17/2022 6:41 AM, Max Samukha wrote:
> Looks like I'm not getting my well-deserved beer. ((


If you come to DConf, you'll get a beer from me regardless!