On 1/10/2024 7:56 AM, GrimMaple wrote:
> I am not "believing" that, I am __seeing__ that. See those for example
> https://github.com/dlang/dmd/pull/10460 -- Reverts commit without even notifying the person who did that commit

Scroll down and look at the last entry.

On 1/10/2024 8:15 AM, Nick Treleaven wrote:
> If you mean @live, that's under a preview switch. If you mean importC, that's a compiler feature, not part of the D language.

Interestingly, I have begun adopting an O/B style in my own coding. It has a lot of merit, even for GC code, as it makes code more understandable.

I well know that O/B isn't a solution for every problem, which is why Rust has an "unsafe" mode. I also have no intention of breaking everyone's code by introducing OB. That's why it's restricted to @live functions.

On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
> On Tue, Jan 09, 2024 at 02:02:36PM +0000, BlueBeach via Digitalmars-d wrote:
>> [...]
>
> See: http://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_01.html
>
> [...]
I agree wholeheartedly!!!

On 1/11/24 18:40, a11e99z wrote:
> what should be done with D?
> 
> 1) /for any future path of D/
> drop DMD entirely and develop only LDC.

DMD is much easier to build so as things are it is worth keeping even if only for the sake of compiler development.

> ...
> - minus: to slow code generation.

It's a big one.

> well, Zig decides to generate LLVM-binary-IR w/o LLVM framework/tools. and need to optimize compiler itself not generated code.
> ...

That seems potentially interesting, though an additional step to transform the generated LLVM IR into machine code is certainly more expensive than outputting machine code directly. I am sure the Zig developers must be aware of this and are planning to do their own native backends for common architectures as well?

Though I hear that LDC spends a lot of time on IR validation to detect bugs by default and that disabling it using --disable-verify can increase LDC build speeds significantly.

On 1/10/24 11:40, Paolo Invernizzi wrote:
> 
> Let's come back to pragmatism:
> - everyone thinks DIP1038e is far better than DIP1027
> - you are not convinced, but hey, we are human being, maybe you are wrong.
> 
> What's the solution? Simple, recognise that! You grown a really talented group of people, so trust them! We are talking about a "language" feature, we have Timon onboard, with a raised thumb on that, trust his judgement!

To be clear, in order of importance:

- I do not want DIP1027 in the language, it solves the wrong problem.
- I think DIP1036e is cool and solves the right problem.

Whether DIP1036e should be merged as-is is or should be separated out into different features that allow to solve the same problem is another question, at the moment I am mostly arguing that DIP1027 is inadequate.

Walter implementing the previously rejected DIP1027 instead of engaging with Adam's new proposal that addressed DIP1027's shortcomings I think was not a great move, but I understand it is more fun to implement your own idea than to try to understand someone else's.