July 09 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Brian Callahan | 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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to bachmeier | 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: >
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.
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
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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
Posted in reply to monkyyy | 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 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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Nick Treleaven | 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 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 | |||
July 09 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to monkyyy | 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 Any 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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
Posted in reply to aberba | 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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Lance Bachmeier | 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: ~Brian | |||
July 10 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to bachmeier | 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 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to ryuukk_ | On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote: >AI devs picked C, not rust Not sure about that actually. Hugging Face has a lot of Rust repos. | |||
July 10 Re: D not considered memory safe | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Sergey | 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. Hugging Face has a lot of Rust repos. Except them, there is nothing Besides, calling a tokenizer "tokenierz".. they play the SEO game with the VCs, the steam remains C | |||
Permalink
Reply
