On 12/14/2024 4:39 PM, Paul Backus wrote:
> That way, you can get the informational/educational value of -preview=safer without breaking your build, and you're only forced to satisfy the checks once you actually decide to transition to @safe.

Safer is turned on with a switch. You can turn it on, see what you want to address, then turn it off.

On Sunday, 15 December 2024 at 03:11:10 UTC, Walter Bright wrote:
> On 12/14/2024 4:39 PM, Paul Backus wrote:
>> That way, you can get the informational/educational value of -preview=safer without breaking your build, and you're only forced to satisfy the checks once you actually decide to transition to @safe.
>
> Safer is turned on with a switch. You can turn it on, see what you want to address, then turn it off.

I think his point is that it wont "educate people", or wont push people to do what you think it will. I mean you're assuming that if you do X it will encourage people to do Y. Like "make casts ugly and people will use them less", I don't think that works. I means there's lots of psychologic research on "nudging" people towards more desirable behaviour. But its often counterintuitive. One example I remember is when they did an experiment where they fined parents who dropped their kids of late to nursery. It made the problem worse because parents were like "I can just pay the fine". What actually worked was when they made it so that if you're late you have to go in to talk to the secretary and sign in a book for being late. What they learnt from the parents was the fine made it easier, they can just pay the fine and feel less guilt about being late. Whereas talking to the secretary was embarrassing, and **emphasised** that they were not doing what they should.

So if you really want to encourage people toward safety, maybe have the compiler *always* print a report on the memory safety issues, something like..

"42 memory issues found, uses the "-safebydefault" switch to find out more"

That will keep nudging people, and also gamify it a bit. People like having a metric they can work on.

It **may** also work on the grounds that people will want the number as low as possible if they are publishing their code. I mean if everyone will see that message when its compiled.

Oh yeah the another one I remember was that putting little plastic balls in urinals made guys significantly less likely to pee on the floor.

On Sunday, 15 December 2024 at 10:09:08 UTC, claptrap wrote:
> issues, something like..
>
> "42 memory issues found, uses the "-safebydefault" switch to find out more"
>
> That will keep nudging people, and also gamify it a bit. People like having a metric they can work on.
>
> It **may** also work on the grounds that people will want the number as low as possible if they are publishing their code. I mean if everyone will see that message when its compiled.

I understand your point, but maybe some people will see that warning as a "ticket" instead of "secretary" as you pointed.

I remember that one day I decided to takle all the warnings in the company code, until the next release new warnings started to pop-up again.

Some people are lazy and they will just write/do things to get the job done unfortunately.

But let's say you have these warnings by default, if people do something about then nice, otherwise they may even complain this is just slowing down the compiler.

I wonder how OpenD are doing since they turned this feature on in their branch.

Matheus.

On Sunday, 15 December 2024 at 03:11:10 UTC, Walter Bright wrote:
> On 12/14/2024 4:39 PM, Paul Backus wrote:
>> That way, you can get the informational/educational value of -preview=safer without breaking your build, and you're only forced to satisfy the checks once you actually decide to transition to @safe.
>
> Safer is turned on with a switch. You can turn it on, see what you want to address, then turn it off.

Yeah, but then you have to compile your entire project twice. As fast as the D compiler is, there are still plenty of projects out there that take a non-trivial amount of time to compile.

On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:
> I wonder how OpenD are doing since they turned this feature on in their branch.

The OpenD impl is different in some key ways:

* it is on by default. things hidden behind compiler switches might as well not exist; they're unlikely to be used except by hardcore enthusiasts, which is the same group of people already writing @safe everywhere.

* it does deprecations instead of errors. It alerts you, but you're still free to ignore them and carry on - important for using it with third party dependencies that don't keep up with the bleeding edge

* the error messages use "non-@system, non-@trusted" instead of "@safe" since that better indicates what the code actually says

* not all @safe checks are enabled. Ones that are redundant (the general idea is if you had to go out of your way to write the code, no point deprecating since the programmer ought to have already realized they're going off the beaten path) or are onerous (this was a subjective feeling, but I compiled about a half million lines of real world D code and where it took a bunch of time to satisfy the compiler without actually bringing my attention to any buggy code) are NOT checked by default; you still opt into them with @safe like before.

* it is possible to tighten the restrictions as time goes on and "force" - insomuch as a deprecation message is a forcing mechanism - programmers to get more and more strict. Among possible (but untaken and unsure if it is even worth taking) future directions are to enable the scope escape checks / taking address of local var again, or prohibiting the call of explicitly @system functions from unannotated functions too.


Details here (and yes, note the date on this is March):
https://dpldocs.info/this-week-in-d/Blog.Posted_2024_03_25.html

There's been a few small changes since this was written, but safer-by-default has mostly been successful as-is - it found a few actual bugs in real world code without being impossible to adopt in practice, so the feature has had a net positive effect on memory safety - and we've moved on to other things to focus on in OpenD land including but not limited to full extern(Objective-C) support (which is in an upstream ldc beta now too), Webassembly support built into druntime (along with a work-in-progress bare metal support in druntime itself!), and more.

On Sunday, 15 December 2024 at 03:11:10 UTC, Walter Bright wrote:
> On 12/14/2024 4:39 PM, Paul Backus wrote:
>> That way, you can get the informational/educational value of -preview=safer without breaking your build, and you're only forced to satisfy the checks once you actually decide to transition to @safe.
>
> Safer is turned on with a switch. You can turn it on, see what you want to address, then turn it off.

Hey Walter, I would love to try this, but it seems the latest DMD version still doesn't support it? When do you plan to release it (or is there a way to tell the install.sh script to get a "nightly" with this?)?

On 12/15/2024 10:20 AM, Renato Athaydes wrote:
> Hey Walter, I would love to try this, but it seems the latest DMD version still doesn't support it? When do you plan to release it (or is there a way to tell the install.sh script to get a "nightly" with this?)?

Hopefully in January.

On Sunday, 15 December 2024 at 14:12:12 UTC, Adam D Ruppe wrote:
> On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:
>> I wonder how OpenD are doing since they turned this feature on in their branch.
>
> The OpenD impl is different in some key ways:
>
> ...

Awesome and thanks for the insights.

Matheus.

On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:

> Some people are lazy and they will just write/do things to get the job done unfortunately.

"Lazy" and "unfortunately" are not accurate. Memory safety comes with a non-trivial cost, and in many cases, no benefit.