www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - -preview=safer for D

reply Walter Bright <newshound2 digitalmars.com> writes:
Now that this has been merged into master, what are your reactions?
Dec 14 2024
next sibling parent reply Daniel N <no public.email> writes:
On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright 
wrote:

 Now that this has been merged into master, what are your 
 reactions?


Brilliant, I seldom used  safe, so this is just what I needed.
Dec 14 2024
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 14 December 2024 at 09:44:05 UTC, Daniel N wrote:

 On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright 
 wrote:

 Now that this has been merged into master, what are your 
 reactions?


 Brilliant, I seldom used  safe, so this is just what I needed.


BTW: Is it intended that this code

    import std.stdio;

     safe:

    void allocate (ref int [] a)
    {
       int [16] b;
       writeln (b);
       a = b;
    }

    void main ()
    {
       int [] c;
       allocate (c);
       writeln (c);
    }

not only requires the " safe" but also the -dip1000 switch
in order to reject compilation:

    u.d(9): Error: address of variable `b` assigned to `a` with 
longer lifetime

Why does the compiler make it so difficult to enable this 
diagnostics?
Dec 14 2024
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/12/2024 11:46 PM, kdevel wrote:

 Why does the compiler make it so difficult to enable this diagnostics?


We went down the enabling of it path, but it broke too much code and too 
few people understood it.

As a design DIP1000 is not expressing enough for it to not catch things 
that it shouldn't and what it does express makes it easily misunderstood.

There has been a hard line drawn for PhobosV3, it will not use it in its 
current form. Quite some dislike for it exists within the community.
Dec 14 2024
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, December 14, 2024 1:46:35 AM MST Walter Bright via Digitalmars-d
wrote:

 Now that this has been merged into master, what are your reactions?


Honestly, the more I think about it, the less I see the point in it, but I
also don't see it as a problem so long as it never becomes the default.

If I want a function to be  safe, I'll mark it with  safe, and I'll get all
of the appropriate checks. The fact that I didn't mark a function with  safe
means that I either want it to be  system and was relying on the current
default - or more likely that I didn't care about  safety at all with that
piece of code (which often happens with stuff like scripts or other small
programs).

I assume that the point behind the flag is to provide a tool to track down
places where there would be issues when  safe becomes the default so that
they can be fixed now, but if I actually want to do that, I can just start
putting  safe on my functions, and there's no need for a compiler flag.

So, from what I can see, the only real use case for -preview=safer is if I
want to check a bunch of code for  safe without taking the time to actually
mark it with  safe under the assumption that when  safe becomes the default,
those explicit attributes will be unnecessary. And maybe that's worth having
the flag for (and you already implemented it regardless), but in my case, if
I actually care about a particular piece of code being checked for  safe,
I'm just going to take the time to mark it with  safe, and then I also get
the benefit of being able to call that function from  safe code, which the
flag doesn't help with.

So, I don't necessarily see any problem with the flag, but I also don't see
much benefit in using it.

On the other hand, if your plan is to ever make -preview=safer the default,
then I think that that's a serious problem, because it's forcing almost all
of the  safe checks without actually making  safe the default. So, all of
the code that fails the flag will break, and you'll _still_ have to go and
mark all of the functions with  safe if you want to actually call them from
 safe code. So, it's forcing almost all of the checks on everything that
isn't explicitly  system (just missing the one about calling  system
functions) without actually providing the full benefits. From what I can
see, simply turning on  safe by default would make more sense than turning
on -preview=safer as the default.

So, I have no problem with the flag as a linting tool to prepare for  safe
by default, but I very much hope that it's not your intention to ever make
the flag the default. And I would expect that in most cases, anyone who
actually cares about  safe enough to use the flag would be using  safe
explicitly anyway, but I can certaintly believe that some folks will want to
use the flag to check for potential issues with  safe by default without
actually taking the time to mark anything with  safe to then get the full
benefits of  safe now.

- Jonathan M Davis
Dec 14 2024
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2024 2:20 AM, Jonathan M Davis wrote:

 if I actually want to do that, I can just start
 putting  safe on my functions, and there's no need for a compiler flag.


We've pushed that for years, but it doesn't work. It doesn't work because of
the 
transitive nature of  safe - you can't do it piecemeal, it has to be done all
at 
once.

Safer is enabling the checks, but not transitively.
Dec 14 2024
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, December 14, 2024 2:21:55 PM MST Walter Bright via Digitalmars-d
wrote:

 On 12/14/2024 2:20 AM, Jonathan M Davis wrote:

 if I actually want to do that, I can just start
 putting  safe on my functions, and there's no need for a compiler flag.


 We've pushed that for years, but it doesn't work. It doesn't work because of
the
 transitive nature of  safe - you can't do it piecemeal, it has to be done all
at
 once.

 Safer is enabling the checks, but not transitively.


In general, it works just fine if you start from the bottom, since  system
code can call  safe code. You do have some issues with recursion, of course,
particularly when there are several functions involved, but it can be done.
And of course classes have more issues with all of this in general due to
how attributes interact with polymorphism. However, it's starting at the top
of the call stack where it's a disaster, basically requiring  trusted
everywhere as you move down the stack, whereas coming up from the bottom, it
generally is quite possible to make changes in a piecemeal fashion, since
it has no effect on what's up the stack if the stuff below it shifts from
 system to  safe or  trusted.

The bigger problem is really that there isn't enough incentive to actually
bother to mark functions  safe. Anyone who actually cared enough about  safe
for a project to want to go to the effort would have been using  safe
explicitly in the first place, and while  safe definitely finds problems, if
you're not doing a bunch of low level stuff, it often doesn't help much in
practice, so plenty of folks don't bother. And for many of those folks,
 safe by default would be fine so long as the third-party code that they're
calling is  safe, since they wouldn't have to use explicit attributes any
more than they do now when ignoring  safe, and if they're not actually doing
anything  system, then they wouldn't be doing anything for the compiler to
complain about (either with  safe by default or with the flag).

In any case, I'm not against the flag existing as a helper towards moving
code towards  safe by default. I just don't see enough value in it to bother
using it myself, and I'm very much against the idea of ever making it the
default, because without the transitivity, you don't get the actual
guarantees, and you still get most of the pain.

If the flag is the default, then code in general may become more
memory-safe, because folks would then be forced to either mark their code
with  trusted or  system to shut the compiler up, or they'd fix the things
that the flag pointed out. However, it does nothing to solve the problem of
making code in general  safe or to make it easier to transition a code base
to being  safe everywhere. To get the actual guarantees from  safe, the
functions themselves need to also be  safe (that is, they need to be
attributed as  safe by the type system), and that means either going to the
effort of manually marking all of those functions with  safe (or putting
 safe: at the top of the module if it has no templates), or it means having
 safe by default. If you're manually marking functions as  safe, then the
flag isn't helping you, and if we have  safe by default, then the flag isn't
necessary (at best, it would help find issues prior to  safe becoming the
default so that fewer changes need to be made at that point).


From what I can see, having  safe by default is going to make it easier to


transition a code base to being  safe, whereas the flag will not. That's
because with  safe by default, a lot of code will just magically become
 safe and work, because it's not actually doing anything  system, and in
many cases, the functions that it's calling will then magically become  safe
as well. The code that is then doing something  system will need to be
fixed, but that's true of the flag as well. So, both having the flag be the
default and having  safe be the default require fixing functions which
aren't explicitly marked with an attribute and which are doing something
that isn't memory-safe, but with the flag, you then still have to go to all
of the same effort that you'd have to go to now to explicitly mark functions
with  safe or  trusted to be able to have your functions actually be  safe,
whereas with  safe by default, a lot of functions gets made  safe for you.

As such, if we're going to change the default, I would strongly argue that
we just make  safe the default and not the flag.  safe by default provides
more benefit with less pain - at least if the ultimately goel is to have
 safe functions - because then the compiler is actually helping you mark all
of your functions as  safe rather than just complaining about the places
where your code is doing stuff that is  system.

- Jonathan M Davis
Dec 14 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2024 4:04 PM, Jonathan M Davis wrote:

 As such, if we're going to change the default, I would strongly argue that
 we just make  safe the default and not the flag.


Oh, we've tried that. It does not work. Here's the problem:

DMD has an essentially recursive nature. Every function is transitively 
reachable by every other function. Not 100% true, but true enough.

Enough of the code also does unsafe things like use C strings to make it just 
plain frustrating to try and make  safe any significant portion of it.
Dec 14 2024
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 14 December 2024 at 10:20:34 UTC, Jonathan M Davis 
wrote:

 If I want a function to be  safe, I'll mark it with  safe, and 
 I'll get all of the appropriate checks.


It's not always trivial. For example, I have an array copy 
function, it takes two arrays and calls memmove on them. It's, 
like, 80% safe, but it's not obvious what it would take to make 
it safer.
Dec 16 2024
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, December 16, 2024 2:47:27 AM MST Kagamin via Digitalmars-d wrote:

 On Saturday, 14 December 2024 at 10:20:34 UTC, Jonathan M Davis
 wrote:

 If I want a function to be  safe, I'll mark it with  safe, and
 I'll get all of the appropriate checks.


 It's not always trivial. For example, I have an array copy
 function, it takes two arrays and calls memmove on them. It's,
 like, 80% safe, but it's not obvious what it would take to make
 it safer.


Whether we're talking about  safe or -preview=safer, they're both going to
flag  system operations, requiring that a function that has  system
operations be either  system or  trusted. The difference is that if you have
a function that can be marked with  safe, and you mark it with  safe, you
have a function that can be called from other  safe functions, whereas with
-preview=safer, all you've done is track down instances where your code is
doing  system operations (and you're then forced to explicitly mark the
function as  system if it can't be  trusted). You still have to mark the
function  safe or  trusted to be able to call it from  safe code.

As for how to make  system code be  safe, the only way to do that is to use
 trusted. The question then is where exactly  trusted should be used, and
that's obviously going to depend on the code in question. In principle, when
you mark a function as  trusted, you're promising that it's 100% memory-safe
in spite of the fact that it's doing something that's  system (though that
obviously relies on the assumption that there are no compiler bugs which
impact memory-safety and that all of the  trusted code that's being called
is actually memory-safe).

If you have a function that's doing something with its arguments which are
 system, and whether you can guarantee that it's actually  safe depends on
the arguments that are given such that you can't guarantee that the code is
memory-safe based solely based on what the function itself is doing, then
that generally means that the function should be marked as  system, and it
should then be documented what the requirements for the arguments are in
order for what the function is doing to be memory-safe. Then the caller
would make sure that it was passing in valid arguments and be marked
 trusted.

One example of something like this would be a function like free. For free
to be considered memory-safe, you have to pass it the correct arguments
(otherwise, you can get issues like double-frees). So, free has to be
 system, and it's the caller's responsibility to make sure that it's passing
valid arguments to free. And if it does that, then it can be marked
 trusted.

As to whether your particular function can be marked  trusted, I don't know,
but it sounds like it probably can't be. If you can't be sure that the
function is actually memory-safe, then that generally means that it's either
doing something wrong that needs to be fixed, or that its memory safety
depends on its arguments, in which case, the  trusted needs to be further up
the call stack. But it's the kind of thing which really depends on what
exactly the code is doing. In principle, to be able to mark a function as
 trusted, it has to present an  safe API, since it's supposed to be
impossible for an  safe function to doing anything that isn't memory-safe.

Either way, if you screw up and put  trusted in the wrong place, at least
you know where to look when something happens which involves memory-safety
having been violated, since only  trusted code can cause  safe code to do
something that isn't memory-safe.

You might want to check out this blog post by Paul Backus:

https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html

- Jonathan M Davis
Dec 16 2024
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/24 09:46, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


Here's what I tried. (`&x` is just a placeholder for any unsafe 
operation, I am aware it would be fine for this to compile here, as it 
would with DIP1000.)


```d
import std;

void foo() system{}

void bar(){
     foo(); // ok
}

void baz(){
     int x;
     // auto y=&x; // error, good
}

void qux(){
     foo(); // ok
     int x;
     // auto y=&x; // error, good
}

auto bongo(){
     int x;
     auto y=&x; // ok, bad
}

void flarp()(){
     int x;
     auto y=&x; // ok, bad
}

void main(){
     writeln("hi"); // ok
}
```

So I don't know, it's mixed for me. I do like the idea of linting 
functions with a not necessarily safe interface using the ordinary 
safety checks by default.

OTOH it is not so great that inferring a return type or using a template 
will disable the checks. I cannot even opt in: there is no explicit way 
to say: neither ` safe` nor inferred ` system`. I either have to go 
` safe`, which may not be an option if the function interface is not 
memory safe, and even if the function interface is memory safe, I will 
have to opt into transitivity of ` safe` at that point, which is already 
the existing tradeoff without `-preview=safer`.

I will probably use the flag, but I have projects where a lot of my code 
or, more importantly, code in its dependencies, is templated and/or 
infers return types. `-preview=safer` will just not do all that much there.
Dec 14 2024
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/24 16:12, Timon Gehr wrote:

 On 12/14/24 09:46, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


 
 ...
 
 I will probably use the flag, but I have projects where a lot of my code 
 or, more importantly, code in its dependencies, is templated and/or 
 infers return types. `-preview=safer` will just not do all that much there.


Furthermore, with `-preview=safer`, there are now those combinations (MS 
= memory safe interface):

             | MS       | guaranteed MS | maybe not MS
------------+----------+---------------+-----------------------
checks      | ???      |  safe         | default safety
no checks   |  trusted | cannot exist  |  system


So another thing that is a bit non-orthogonal is that there is no way to 
have non-transitive safety checks enabled in a function whose memory 
safety cannot be established using compiler guarantees. I.e. you cannot 
have both ` trusted` and default safety checks.
Dec 14 2024
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Safer offers no guarantees of memory safety. I view it as a tool to:

1. provide some lint-like flagging of suspicious constructs

2. help educate new D users to safer practices

3. make it easier to transition to using  safe

You are an expert, and I doubt it will be of much value to you as you are 
already an expert in what is safe and what isn't.

Memory safety, as I predicted a few years back, is now a critical feature of a 
programming language, and whatever practical way we can move D in that
direction 
we must do.
Dec 14 2024
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/24 22:36, Walter Bright wrote:

 Safer offers no guarantees of memory safety.


I am aware what it does and why.


 I view it as a tool to:
 
 1. provide some lint-like flagging of suspicious constructs
 
 2. help educate new D users to safer practices
 
 3. make it easier to transition to using  safe
 
 You are an expert, and I doubt it will be of much value to you as you 
 are already an expert in what is safe and what isn't.
 ...


Well, I sometimes use dependencies. Flagging some of the more shady 
things they do can be useful, and I end up forking most of them anyway. 
Sometimes I contribute to code bases that also have other people working 
on them. These goals often enough align with mine even if I am 
personally already an expert.


 Memory safety, as I predicted a few years back, is now a critical 
 feature of a programming language, and whatever practical way we can 
 move D in that direction we must do.


I agree and I am on board with the goals and also the general direction. 
I noted two weaknesses of this specific proposal that limit its ability 
to address the three goals you noted above. The more important one is 
that it does not apply at all to large categories of code such as templates.
Dec 14 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2024 1:52 PM, Timon Gehr wrote:

 The more important one is that it does not apply at 
 all to large categories of code such as templates.


Right. It does not apply to functions that get their attributes inferred. That 
includes template functions, functions that return `auto`, etc.

I haven't figured out a way to apply safer to them while still inferring
attributes.
Dec 14 2024
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 14 December 2024 at 21:36:17 UTC, Walter Bright 
wrote:

 Safer offers no guarantees of memory safety. I view it as a 
 tool to:

 1. provide some lint-like flagging of suspicious constructs

 2. help educate new D users to safer practices

 3. make it easier to transition to using  safe


If these are the goals, maybe it would make more sense for failed 
checks to result in warnings rather than errors.

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.
Dec 14 2024
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 14 2024
next sibling parent reply claptrap <clap trap.com> writes:
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.
Dec 15 2024
parent reply matheus <matheus gmail.com> writes:
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.
Dec 15 2024
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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.
Dec 15 2024
parent matheus <matheus gmail.com> writes:
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.
Dec 16 2024
prev sibling parent reply Lance Bachmeier <no spam.net> writes:
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.
Dec 16 2024
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 17/12/2024 3:10 AM, Lance Bachmeier wrote:

 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.


Neither is this fully accurate.

Memory safety when it properly models memory movement, does offer 
benefits in terms of optimization. Both logical bugs, and memory safety 
related issues can be caught.

Full program security analysis is incredibly expensive and I honestly 
don't think D will ever have it. You basically need a proof assistant at 
that point and you have to ditch the separate compilation model.

But there is a certain amount we can do, without going into a multi-pass 
DFA, whilst still being separate compilation. That can catch logic bugs 
and provide optimizations without being crazy on the unnecessary errors.

The question therefore, is how to tune it, and that is not an easy 
question to answer (still working on that one!).

A lot of this is bread and butter topics of backend engineers from the 
80's. It is being reapplied to the frontend these days, rather than 
being a whole new area of research.
Dec 16 2024
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 16 December 2024 at 14:24:53 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 17/12/2024 3:10 AM, Lance Bachmeier wrote:

 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.


 Neither is this fully accurate.

 Memory safety when it properly models memory movement, does 
 offer benefits in terms of optimization. Both logical bugs, and 
 memory safety related issues can be caught.


But that's only a benefit if the optimization matters. For most 
of what I do, it doesn't. If you use the GC for your D code but 
interact with C libraries, you have the PITA of the compiler 
saying something's not memory safe, but 100% of the time spent 
getting it to compile is memory safety theater.
Dec 16 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/16/2024 9:16 AM, Lance Bachmeier wrote:

 But that's only a benefit if the optimization matters. For most of what I do,
it 
 doesn't. If you use the GC for your D code but interact with C libraries, you 
 have the PITA of the compiler saying something's not memory safe, but 100% of 
 the time spent getting it to compile is memory safety theater.


Whenever I review C code, I look for strncpy calls. It's nearly always buggy. 
Using the GC with it won't help.

In my revisions of old code to use safe practices, it has resulted in more 
understandable code. The only slowdown was the use of array bounds checking 
(using the GC won't help with that, either).
Dec 16 2024
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
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.
Dec 15 2024
prev sibling parent reply Renato Athaydes <renato athaydes.com> writes:
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?)?
Dec 15 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 15 2024
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/24 09:46, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


Another thing is that the error messages are bad: it says "cannot do X 
in ` safe` function `f`", even if `f` is not a ` safe` function.
Dec 14 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2024 7:48 AM, Timon Gehr wrote:

 Another thing is that the error messages are bad: it says "cannot do X in 
 ` safe` function `f`", even if `f` is not a ` safe` function.


Good point.
Dec 14 2024
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright 
wrote:

 Now that this has been merged into master, what are your 
 reactions?


I agree with Jonathan M Davis that the behavior of this flag 
should never be made the default.

As I said in my response to the initial proposal [1], it has all 
of the costs of  safe-by-default (breaks lots of existing code) 
without any of the benefits (reducing attribute spam and 
ecosystem fragmentation). It does nothing to help D programmers 
who are already using  safe, and creates a new source of 
annoyance for people who are currently happy with  system as the 
default.

The easiest way to satisfy the compiler when -preview=safer is 
enabled is to mark all the functions it flags as explicitly 
 system. Because of this, I think it's unlikely that 
-preview=safer will achieve its stated goal of "mov[ing] such 
code to  safe" [2].

[1] 
https://forum.dlang.org/post/dkbrgvjcqsdpuvaeckty forum.dlang.org
[2] 
https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md#rationale
Dec 14 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
I did reply to Jonathan on that.

I put safer under a flag for the time being, in the future it should become an 
edition.
Dec 14 2024
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/12/2024 9:46 PM, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


My general view is that it could be used for migrating people to 
`` safe`` by default. Would require a couple of editions to do this.

If we are not planning how to do this, I can understand the negative 
reactions to it.

If we are wrong about it having migratory benefits, we can always 
disable it and no modules in a edition would break. So I'm not seeing a 
down side to trying it.

If we are indeed wrong, the fact that it doesn't have an attribute (yes 
it could be in ``core.attribute``!) would negate any benefit it has of 
helping people to transition since it will not be selective.
Dec 14 2024
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 15/12/2024 2:59 PM, Richard (Rikki) Andrew Cattermole wrote:

 If we are indeed wrong, the fact that it doesn't have an attribute (yes 
 it could be in ``core.attribute``!) would negate any benefit it has of 
 helping people to transition since it will not be selective.


I would also like to point out that this feature has a very similar 
behavior as another attribute that a bunch of us have been wanting for 
ages: `` localnogc``.

It seems like if we want to solve this properly it is merely a matter of 
introducing `` local(Identifier)`` for turning on non-transitive 
versions of attributes.
Dec 14 2024
prev sibling next sibling parent reply Elias (0xEAB) <desisma heidel.beer> writes:
On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright 
wrote:

 Now that this has been merged into master, what are your 
 reactions?


“Oh no, they’ve summoned Voldemort’s nameless siblings.”
Dec 26 2024
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2024 3:20 PM, Elias (0xEAB) wrote:

 On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


 
 “Oh no, they’ve summoned Voldemort’s nameless siblings.”


Pass auf!
Dec 26 2024
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright 
wrote:

 Now that this has been merged into master, what are your 
 reactions?


I posted this same question in the announcement thread, but I'm 
curious how we're going to make this work with dependencies.

I can't enable `-preview=safer` only on my own code. It applies 
transitively to everything that's being imported.

It would be useful to be able to limit this flag to specific 
packages. So that I can enable it for only the code I'm in 
control over. But that could complicate the compiler, I 
understand.

Right now this feature is pretty much dead in the water for me if 
I can't compile my own code with the feature on because some 
dependency is not `-preview=safer` compatible.
Jan 03
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 03/01/2025 11:19 PM, Andrej Mitrovic wrote:

 On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright wrote:

 Now that this has been merged into master, what are your reactions?


 
 I posted this same question in the announcement thread, but I'm curious 
 how we're going to make this work with dependencies.
 
 I can't enable `-preview=safer` only on my own code. It applies 
 transitively to everything that's being imported.
 
 It would be useful to be able to limit this flag to specific packages. 
 So that I can enable it for only the code I'm in control over. But that 
 could complicate the compiler, I understand.
 
 Right now this feature is pretty much dead in the water for me if I 
 can't compile my own code with the feature on because some dependency is 
 not `-preview=safer` compatible.


This is solvable using a prefix switch. Of course build managers will 
need to support this style of dflags.

Both editions and external import switch require the refactoring work to 
make this work, and both I intend to do this month.

https://github.com/dlang/dmd/pull/20623

However, given that this isn't meant to remain a switch, I am 
unconvinced that it requires this treatment. Perhaps it warrants 
discussion though.
Jan 03
parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 3 January 2025 at 15:43:01 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 03/01/2025 11:19 PM, Andrej Mitrovic wrote:
 However, given that this isn't meant to remain a switch, I am 
 unconvinced that it requires this treatment. Perhaps it 
 warrants discussion though.


Does D has an instrument to check how many people were using this 
switch?
To be able to analyze how useful was this feature
Jan 03
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/01/2025 6:40 AM, Sergey wrote:

 On Friday, 3 January 2025 at 15:43:01 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 03/01/2025 11:19 PM, Andrej Mitrovic wrote:
 However, given that this isn't meant to remain a switch, I am 
 unconvinced that it requires this treatment. Perhaps it warrants 
 discussion though.


 
 Does D has an instrument to check how many people were using this switch?
 To be able to analyze how useful was this feature


Not that I know of, anyway it's too new.
Jan 03
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2025 2:19 AM, Andrej Mitrovic wrote:

 I can't enable `-preview=safer` only on my own code. It applies transitively
to 
 everything that's being imported.


True. But you can still turn it on, fix the issues in your own code, and then 
turn it off. That's not as useful as it could be, but it still has value.

(It's always a tug of war between applying only to the modules on the command 
line or all the ones that are imported.)
Jan 06