July 09

On Tuesday, 9 July 2024 at 11:54:31 UTC, Brian Callahan wrote:

>

On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

>

Whereas safe by default is already available with a switch.

What is the switch for that?

Walter added -preview=safedefault when he started working on this. I haven't paid attention to it, so I don't know if it's still there, but there was such a switch: https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md#description

July 09

On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

>

On Monday, 8 July 2024 at 10:30:56 UTC, Nick Treleaven wrote:

>

On Monday, 8 July 2024 at 08:48:56 UTC, Martyn wrote:

>
  • goes memory-safe by default, will break existing code.

The idea is that the next edition is @safe by default. Existing code will not be broken.

We have very few details on what this will look like for someone that doesn't want it.

@system:

>

Not breaking existing code is far from sufficient for those writing unsafe code. Inference is useless because there's nothing to infer,

@system would be inferred for functions that use unsafe features.

>

@trusted loses its meaning,

@trusted continues to mean safe interface, unsafe implementation.

>

there's needless boilerplate all over the place, and

@system:

>

it's more complex for new users of the language. There's no

Users get an error instead of accidentally corrupting memory. That's a massive win for new users, assuming they use newer editions.

>

evidence that any of this has been given consideration, and all apparently because adding -safe to the compilation command is too much of a burden for those wanting the additional checks.

That wouldn't be reliable and wouldn't allow safe/unsafe code to interact. We need the code to state what its default is.

July 09

On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

>

A dull knife is the dangerous one, safety features just get in the way and you'll get people learning actively awful patterns in an attempt to force the tool to work

Any pattern to subvert safe involves the @trusted attribute (except for compiler bugs, which editions help to fix). @trusted is an obvious flag in code review that memory-safety may be violated. Grepping for @trusted is an easy way to narrow down places where memory-safety is violated.

Arguing that @trusted can be abused is a tiny problem compared to the far harder to detect abuse in @system by default code.

July 09

On Tuesday, 9 July 2024 at 15:58:17 UTC, Nick Treleaven wrote:

>

On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

>

A dull knife is the dangerous one, safety features just get in the way and you'll get people learning actively awful patterns in an attempt to force the tool to work

Any pattern to subvert safe involves the @trusted attribute (except for compiler bugs, which editions help to fix).

>

Any

nah; trusted helps make a pressure release valve which will prevent the truly pathological situations of say rust or enterprise grade fizzbuzz but.....

The way I will subvert the safety features will be entirely unpredictable, we wont know till im forced to learn what safe actually does, if Im writting @trusted: at the top of files next to my import std allyalls will be lucky; if its more like how I made an "appendable alias seq", well theres only like 3 poeple who understood those mere 80 lines of code

July 09

On Tuesday, 9 July 2024 at 16:18:27 UTC, monkyyy wrote:

>

On Tuesday, 9 July 2024 at 15:58:17 UTC, Nick Treleaven wrote:

>

On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

>

A dull knife is the dangerous one, safety features just get in the way and you'll get people learning actively awful patterns in an attempt to force the tool to work

Any pattern to subvert safe involves the @trusted attribute (except for compiler bugs, which editions help to fix).

>

Any
.
like how I made an "appendable alias seq", well theres only like 3 poeple who understood those mere 80 lines of code

I feel the same about the abuse of templates in a lot of D code. Suddenly no one wants to touch, maintain or contribute.

Now the cognitive load will be more with @safe on top.

July 09

On Tuesday, 9 July 2024 at 21:13:19 UTC, aberba wrote:

> >

like how I made an "appendable alias seq", well theres only like 3 poeple who understood those mere 80 lines of code

I feel the same about the abuse of templates in a lot of D code. Suddenly no one wants to touch, maintain or contribute.

Now the cognitive load will be more with @safe on top.

I love template, Im here for templates

function coloring and appending erroneous "nah you you must do busy work" errors is actively irritating; death to any lanaguge with opinionated white space, unused imports, safety begging, unreachable statement type errors

July 09

On Tuesday, 9 July 2024 at 14:25:06 UTC, Lance Bachmeier wrote:

>

On Tuesday, 9 July 2024 at 11:54:31 UTC, Brian Callahan wrote:

>

On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

>

Whereas safe by default is already available with a switch.

What is the switch for that?

Walter added -preview=safedefault when he started working on this. I haven't paid attention to it, so I don't know if it's still there, but there was such a switch: https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md#description

Sadly with DMD v2.109.0:
Error: preview -preview=safedefault is invalid

~Brian

July 10

On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

>

On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

>

On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

>

We have very few details on what this will look like for someone that doesn't want it. Not breaking existing code is far from sufficient for those writing unsafe code.

Sorry, but having unsafe code is burden enough.

This is not helpful. If the biggest selling point is working with legacy C code, unsafe code needs to be a core part of the language, and it needs to be as easy as possible. (As in, as easy as it is right now.)

>

I don't see any need to help people continue to write unsafe code.

D will quickly die without unsafe code. I would certainly have no reason to continue using it. Rust has the small market for "safe by default" code. D can not and will not compete with Rust on this - the battle is over and all parties have moved on.

>

If at all, it is enough that it will be still possible to write unsafe code. Its not required to make that easy.

We can already do it. There's no "make that easy" to do.

>

Why can't those people be bothered with giving -unsafe as compile parameter?

Proposed and rejected. Whereas safe by default is already available with a switch.

+1

AI devs picked C, not rust

July 10

On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:

>

AI devs picked C, not rust

Not sure about that actually.
Many things already started implementing in Rust...
One of the most popular tokenizers (state of the art .. blah blah blah)
https://github.com/huggingface/tokenizers

Hugging Face has a lot of Rust repos.
Of course some old stuff like CUDA and libtorch are still C++.. but they've started many years ago

July 10

On Wednesday, 10 July 2024 at 18:42:21 UTC, Sergey wrote:

>

On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:

>

AI devs picked C, not rust

Not sure about that actually.
Many things already started implementing in Rust...
One of the most popular tokenizers (state of the art .. blah blah blah)
https://github.com/huggingface/tokenizers

Hugging Face has a lot of Rust repos.
Of course some old stuff like CUDA and libtorch are still C++.. but they've started many years ago

Except them, there is nothing

Besides, calling a tokenizer "tokenierz".. they play the SEO game with the VCs, the steam remains C