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
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
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
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
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
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
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
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
prev sibling parent 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
prev 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
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