July 07
On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz wrote:
> On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:
>> To say something "doesn't have safety tuned on by default" vs "something is unsafe" communicates two different meanings.
>
> Is a car that has airbags deactivated by default before each drive safe?

Is a car that has seatbelts unhooked by default safe? Is a car that can active the engine without annotating which seats are being sat in safe?
July 07

On Saturday, 6 July 2024 at 23:14:00 UTC, Lance Bachmeier wrote:

>

Typing @safe: is not a big deal.

Typing @safe: is also incorrect. You will cause your templates to fail to compile.

-Steve

July 06
On 7/6/2024 4:39 PM, Sebastian Nibisz wrote:
> But you have to remember to enable it. Inexperienced programmer usually won't do this and will build unsafe code unconsciously.

@safe should be the default. But that breaks existing code. So we do the best we can.

July 07
On Sunday, 7 July 2024 at 00:48:49 UTC, monkyyy wrote:
> On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz
>> Is a car that has airbags deactivated by default before each drive safe?
>
> Is a car that has seatbelts unhooked by default safe? Is a car that can active the engine without annotating which seats are being sat in safe?

Cars warn when you don't wear your seat belt. The newest cars won't let you drive.
July 08
On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz wrote:
> On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:
>> To say something "doesn't have safety tuned on by default" vs "something is unsafe" communicates two different meanings.
>
> Is a car that has airbags deactivated by default before each drive safe?

This is not a good comparison. You could have come up with anything else unrelated besides this to still make it seem like you have a point.

D has array bounds check and many others turned on by default. Current D chose to give Dev more freedom and the tools to turn on strict checks when that's desired...as long as you're okay with the cons.

If rusts way of shoveling their strict ownership model in your throat was the overall best, many other system programming language after it would be doing same.
July 08
On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz wrote:
> On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:
>> On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:
>>> Seriously? Any language is safe in this case, you just need to write safe code.
>>
>> Enabling the checks is quite different from writing code with no bugs in it.
>
> But you have to remember to enable it. Inexperienced programmer usually won't do this and will build unsafe code unconsciously.

I've heard this argument about the "inexperienced programmer" many times. Folks assume inexperienced programmers are writing some kernel code or deploying to some mission critical system. I see an inexperienced programmer writing any such code anytime soon. They could care less about these things you're talking about and they'd be using the GC (not that GC is a beginner target feature). Many of the traditional languages suggested to beginners such as C, C++, Python, JavaScript, PHP don't work like rust.

I'm not arguing writing memory unsafe code should be encouraged, I'm saying in reality, it's not a problem for the beginner. You can still write bugs causing vulnerabilities in any language.

Have you considered the cons of dealing with @safe code?
July 08

On Monday, 8 July 2024 at 07:23:44 UTC, aberba wrote:

>

On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz wrote:

>

On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

>

On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

>

Seriously? Any language is safe in this case, you just need to write safe code.

Enabling the checks is quite different from writing code with no bugs in it.

But you have to remember to enable it. Inexperienced programmer usually won't do this and will build unsafe code unconsciously.

I've heard this argument about the "inexperienced programmer" many times. Folks assume inexperienced programmers are writing some kernel code or deploying to some mission critical system. I see an inexperienced programmer writing any such code anytime soon. They could care less about these things you're talking about and they'd be using the GC (not that GC is a beginner target feature). Many of the traditional languages suggested to beginners such as C, C++, Python, JavaScript, PHP don't work like rust.

I'm not arguing writing memory unsafe code should be encouraged, I'm saying in reality, it's not a problem for the beginner. You can still write bugs causing vulnerabilities in any language.

Have you considered the cons of dealing with @safe code?

I generally agree.

If any Company MUST write memory-safe code then there should be rules/standards to follow whether starting a new programming project, to having code reviews and deployment, or other variations.

For example, code reviews should be completed by senior/lead programmers, especially if there has been commits from junor-level programmers... though it should be reviewed REGARDLESS of who and their level of experience.

I do not see Dlang being any different in comparison to other, memory-safe languages. Even if the Company was using Rust, there should still be rules and guidelines to follow! Just because a language is safe by default does not mean un-safe code cannot creep in!

I personally am not bothered if a language is or isn't memory-safe by default. However, the reality is memory-safe by default will get a big green tick beside it when it comes to research papers... and they are the only ones that will get copied-pasted into media/blog articles moving forward.

Rust is all the buzz at the moment and, no doubt, will be the top talking point for these sites whether the writer has any programming knowledge or not.

I guess if Dlang: -

  • goes memory-safe by default, will break existing code.
  • continues as is, will not get recognition for those articles.

For every new DMD release, should there be a SafeDMD alongside it, forcing @safe by default? Would this satisfy both points?

July 08

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.

July 08

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. Not breaking existing code is far from sufficient for those writing unsafe code. Inference is useless because there's nothing to infer, @trusted loses its meaning, there's needless boilerplate all over the place, and it's more complex for new users of the language. There's no 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.

July 08

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.
I don't see any need to help people continue to write unsafe code.
If at all, it is enough that it will be still possible to write unsafe code. Its not required to make that easy. Why can't those people be bothered with giving -unsafe as compile parameter? (Or even something more sofisticated)

IT SHOULD ALWAYS BE MORE COMPLICATED TO SHOOT YOUR FOOT THAN AVOIDING IT