On Monday, 26 August 2024 at 21:53:25 UTC, H. S. Teoh wrote:
> It feels like D is trying too hard to be what it isn't. The original design with GC was clean, ergonomic, and productive. This is the core of D that still constitutes the major reason why I'm still using it.  Then the @nogc crowd showed up, and we bent over backwards to please them. As a result, the language was bent out of shape with attribute soup and half-solutions to the wrong problems that did little to improve the experience of existing D users, while still failing to please the GC objectioners.

The goal of DIP1000 is to make pointers to stack memory @safe, not really about making non-GC heap allocation safe (though it may help with that and is a consideration). Strong support for memory-safe stack allocation absolutely is what D needs, because its aims are to produce efficient code which is not bug-prone. There can be debate on how what kinds of interface can be @safe, but the core of DIP1000 is doing what it should.

On Tue, Aug 27, 2024 at 05:50:11PM +0000, Nick Treleaven via Digitalmars-d wrote:
> On Monday, 26 August 2024 at 21:53:25 UTC, H. S. Teoh wrote:
> > It feels like D is trying too hard to be what it isn't. The original design with GC was clean, ergonomic, and productive. This is the core of D that still constitutes the major reason why I'm still using it.  Then the @nogc crowd showed up, and we bent over backwards to please them. As a result, the language was bent out of shape with attribute soup and half-solutions to the wrong problems that did little to improve the experience of existing D users, while still failing to please the GC objectioners.
> 
> The goal of DIP1000 is to make pointers to stack memory @safe, not really about making non-GC heap allocation safe (though it may help with that and is a consideration). Strong support for memory-safe stack allocation absolutely is what D needs, because its aims are to produce efficient code which is not bug-prone. There can be debate on how what kinds of interface can be @safe, but the core of DIP1000 is doing what it should.

This analysis could have been done in compiler, transparently to the user.  The user should not have to care about this.  The fact that it resulted in attribute soup that almost nobody fully understands, indicates that something is wrong with its design.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

On 01/09/2024 8:45 AM, Adam Wilson wrote:
> On Wednesday, 28 August 2024 at 15:28:47 UTC, Nick Treleaven wrote:
>> On Tuesday, 27 August 2024 at 18:35:06 UTC, H. S. Teoh wrote:
>>> This analysis could have been done in compiler, transparently to the user.
>>
>> No - it would slow down the compiler if inference was done everywhere. It could also cause link errors because attributes are part of the mangled symbol name.
> 
> Even though I know it's going to cause Atila to have a seizure, I'm going to say it anyways. We need to stop caring about compiler speed so much. If adding an entire second to the compile time can save a company from a multi-billion dollar lawsuit, the company is going to to tell you to shut-up and eat the extra second.
> 
> Compile time is a feature, but it is not, and cannot be, the most important feature.
> 
> Sorry Atila, but it had to be said. :)

To follow up on this: specialized use cases like compiler as a daemon should not dictate how normal compilation should work.

If you need to turn off memory safety analysis (that can be handled by JIT using read barriers for example) to make stuff like compiler as a daemon work fast then that is ok.

This is not an either/or situation. You can have both.

>
> This analysis could have been done in compiler, transparently to the user.  The user should not have to care about this.  The fact that it resulted in attribute soup that almost nobody fully understands, indicates that something is wrong with its design.

I hope the powers that be on this project pay careful attention to this comment because I believe "attribute soup" is absolutely right.

In my opinion, D's strength is that it is a big *incremental* improvement over C/C++. It is not a revolutionary language like Rust. Section 20.24 of the Language Reference reads to me like an effort to somehow, desperately, contort this language into something it is not. I'm sorry, but this thing reads like a part of the US tax code or the legalese you need to agree to that appears when installing commercial software. (Any of you ever read that stuff carefully? No? I haven't either.) The mind-boggling complexity of that section is a clear indication that you are on the wrong track. I have not read DIP1000, but I get the clear impression from reading this and other threads that it is more of the same.

It is not difficult to write memory-safe code in D. I've done it. You just need to know where the bunkers are, the traps, and avoid them. A good, clear document explaining this would be a great start. I'm sure there are things that could be done in the compiler and/or dscanner that would help to warn people that they are doing something legal but dangerous.

But it makes no sense to me to try to turn D into Rust, because you don't have the luxury of starting with a blank sheet of paper as the Rust project did. D's multiple memory-management methods, some inherited from C, make it inherently memory-unsafe, so trying to provide memory-safety guarantees is very difficult and will almost certainly make a mess of the language. Section 20.24 says to me that a start has been made on that mess.

I think the D project should focus on increasing the distance between D and C/C++ and forget about competing with Rust. Those who want guaranteed memory-safety are likely to just use Rust. I would also note that Zig has gotten a lot of attention despite not having been released yet and Zig is not a memory-safe language.

On Sunday, 1 September 2024 at 20:42:14 UTC, Donald Charles Allen wrote:
> But it makes no sense to me to try to turn D into Rust, because you don't have the luxury of starting with a blank sheet of paper as the Rust project did. D's multiple memory-management methods, some inherited from C, make it inherently memory-unsafe, so trying to provide memory-safety guarantees is very difficult and will almost certainly make a mess of the language. Section 20.24 says to me that a start has been made on that mess.

Safe Rust is too restrictive about mutability.
DIP1000 is about extending the amount of code that can be @safe. DIP1000 removes restrictions.

> I think the D project should focus on increasing the distance between D and C/C++ and forget about competing with Rust. Those who want guaranteed memory-safety are likely to just use Rust.

D supports GC, so heap allocation does not have to restrict safe operations. DIP1000 shows you can often use safe pointers to stack memory without Rust's mutability restrictions.

On Monday, 2 September 2024 at 09:48:44 UTC, Nick Treleaven wrote:
> Safe Rust is too restrictive about mutability.
> DIP1000 is about extending the amount of code that can be @safe. DIP1000 removes restrictions.

I think the question is not in the technical ability or inability to achieve something, but more in the intense from the community to do that and write code in that way.

It seems D community doesn't want to do these things, and Rust community wants. And it is fine.

So the question is only to achieve some kind of recognition from authorities, so they will consider D as a "safe language" (nobody really knows what is it and at which level of safety they can mark this kind of label to the language - I think current language selection was kinda random).

Just to make D available for hypothetical developers with government contracts (does DLF ever got any requests on that? really...)

On Monday, 2 September 2024 at 10:07:30 UTC, Sergey wrote:
> So the question is only to achieve some kind of recognition from authorities, so they will consider D as a "safe language" (nobody really knows what is it and at which level of safety they can mark this kind of label to the language - I think current language selection was kinda random).

Can you give an example of a memory-safety violation allowed in @safe that there is no plan to fix? There are violations in bugzilla, but I think we have solutions for each of them, that can be implemented. For a few, that will require breaking existing code, but we can do that with editions.