On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:

> I am taking issue with throwing overboard even the aspiration of memory safety. You won't get D widely recognized as a safer language if its ecosystem is actively encouraged to build on careless `@trusted` slapping-on, even on functions where it is completely obvious that they have an unsafe interface.

This!

On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:
> On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:
>
>> Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety.
>
> I bet core tech (eye tracking and object detection) is C++ code :)

I honestly don't get why D after 20yrs is being dragged (by a vocal minority) to become like rust. Shouldn't they be using rust already? A lot of very important new code is still being written in C++ (irrespective of its flaws). It's not like you can't write strict safe code in D either. Devs aren't stupid, it doesn't matter if strict is turned on by default or not at this point. They know what to do. There's way too many existing code in D to be dragging our feet with rust which is still niche by the way.

On 7/26/24 10:57, aberba wrote:
> On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:
>> On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:
>>
>>> Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety.
>>
>> I bet core tech (eye tracking and object detection) is C++ code :)
> 
> I honestly don't get why D after 20yrs

`@safe` existed before Rust was even a thing. It has just gained a bit in importance.

> is being dragged (by a vocal minority) to become like rust. Shouldn't they be using rust already?

I am sure the people you are referring to, to the point they even exist, are already using Rust.

> A lot of very important new code is still being written in C++ (irrespective of its flaws). It's not like you can't write strict safe code in D either. Devs aren't stupid, it doesn't matter if strict is turned on by default or not at this point. They know what to do.

No, in practice they build vulnerable systems. Devs do not know what they are doing, otherwise they would not be doing it like that.

On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:
> On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:
>
>> I am taking issue with throwing overboard even the aspiration of memory safety. You won't get D widely recognized as a safer language if its ecosystem is actively encouraged to build on careless `@trusted` slapping-on, even on functions where it is completely obvious that they have an unsafe interface.
>
> This!

Not really big on @safe (where is the RoI???? where are the products that beat the competition by being safe), but when currently used @trusted has 2 different semantic meanings:

1 - @trusted that means "I've audited that the @system function I call are memoy-safe. do not grep this, there is nothing to see"
2 - @trusted that means "TODO, this is necessary because I've slapped @safe on top and must go on with productive things. I'll get back later! I should have marked this @system in the first place. I promise i'll get back and fix it!!1"

Walter Bright kirjoitti 25.7.2024 klo 5.12:
> On 7/14/2024 6:34 AM, Dukc wrote:
> 
> It wasn't just me. Quite a few people realized that the @trusted lambda approach did not work.
> 

I'm not denying the trusted lambda trick has it's downsides, and it's often better to just mark the whole calling function `@trusted`.

What I fail to see is why would marking the *called* function `@trusted`, when it's API is actually unsafe, be any better than the lambda trick? All the issues that make the lambda trick bad still apply, only worse.

On Friday, 26 July 2024 at 14:59:52 UTC, Guillaume Piolat wrote:
> On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:

> Not really big on @safe (where is the RoI???? where are the products that beat the competition by being safe)

https://www.adacore.com/uploads/techPapers/222559-adacore-nvidia-case-study-v5.pdf

>, but when
> currently used @trusted has 2 different semantic meanings:
>
> 1 - @trusted that means "I've audited that the @system function I call are memoy-safe. do not grep this, there is nothing to see"
> 2 - @trusted that means "TODO, this is necessary because I've slapped @safe on top and must go on with productive things. I'll get back later! I should have marked this @system in the first place. I promise i'll get back and fix it!!1"

The second one is safe washing. If we need this as an aid tool during development it should not be a mere "comment" on code, but something that the compiler can enforce: in Elm for example, that we are using as a frontend, the compiler complains if you try to build a release versione of the code and you have not removed things that should not appear in a release.

On Friday, 26 July 2024 at 14:59:52 UTC, Guillaume Piolat wrote:
> On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:
>> On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:
>>
>>> [...]
>>
>> This!
>
> Not really big on @safe (where is the RoI???? where are the products that beat the competition by being safe), but when currently used @trusted has 2 different semantic meanings:
>
> 1 - @trusted that means "I've audited that the @system function I call are memoy-safe. do not grep this, there is nothing to see"
> 2 - @trusted that means "TODO, this is necessary because I've slapped @safe on top and must go on with productive things. I'll get back later! I should have marked this @system in the first place. I promise i'll get back and fix it!!1"

This was my initial thoughts as well, almost like needing @unverified.

On Friday, 26 July 2024 at 08:57:42 UTC, aberba wrote:
> On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:
>> On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:
>>
>>> Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety.
>>
>> I bet core tech (eye tracking and object detection) is C++ code :)
>
> I honestly don't get why D after 20yrs is being dragged (by a vocal minority) to become like rust. Shouldn't they be using rust already? A lot of very important new code is still being written in C++ (irrespective of its flaws). It's not like you can't write strict safe code in D either. Devs aren't stupid, it doesn't matter if strict is turned on by default or not at this point. They know what to do. There's way too many existing code in D to be dragging our feet with rust which is still niche by the way.

I could not agree more. Trying to glue Rust-like features onto this language really feels like ill-considered imitation, not a good look for a language that has already been accused of jumping on bandwagons. It also does not make technical sense to me. I've written comparable amounts of Rust and D and for ordinary applications without real-time constraints, I much prefer D, so I don't have to become an involuntary part of Rust's complex approach to memory management. Saying equivalent things in D is so much easier easier than in Rust. But the more baroque D becomes, the harder it will be for newcomers to find the subset of the language that works for them.

On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:
> On Friday, 26 July 2024 at 08:57:42 UTC, aberba wrote:
>> [...]
>
> I could not agree more. Trying to glue Rust-like features onto this language really feels like ill-considered imitation, not a good look for a language that has already been accused of jumping on bandwagons. It also does not make technical sense to me. I've written comparable amounts of Rust and D and for ordinary applications without real-time constraints, I much prefer D, so I don't have to become an involuntary part of Rust's complex approach to memory management. Saying equivalent things in D is so much easier easier than in Rust. But the more baroque D becomes, the harder it will be for newcomers to find the subset of the language that works for them.

I'm just asking not to derail what is _already_ in the language, and to stick with the current documentation: @trusted interface MUST be safe, otherwise all the narrative about D, and core developments caring about memory safety is just impossible to bake.

On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:
> I could not agree more. Trying to glue Rust-like features onto this language really feels like ill-considered imitation,

D's @safe is much more permissive than Rust.