www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shouldn't safety be the default.

reply Hors <q q.com> writes:
Optional safety is really outdated, I think some people can't see 
how important is safety almost everywhere (both for system and 
general purpose). Safe by default allows you to catch bugs 
without possibly wrecking your entire system (or systems' of 
users of your app).
Some people are defending "Just don't make mistake" but we are 
all human and make mistakes, even experienced progammers can 
easily make mistakes, it's normal. So I think  safe should be 
default in dlang.

Advantages:
Not being scared to code - unsafe languages makes you scared to 
code (I experienced this the hard way) you usually never use the 
language's power at %100, because if you make mistake it can 
easily get you in trouble.
In  safe code, making mistakes and learning from them is easier.

Less security vulnerabilities - Mistakes throw helpful exception 
and halts program instead of causing security issues.

Also some myths about  safe:
"It's slow and uses a lot memory" - It is true that safe can be 
slower than unsafe and use more memory, but performance is not 
the only thing a language can offer. I am asking, did you ever 
hit %100 CPU usage or ran out of memory, yet still needed more 
performance or storage (ram), if it's the case I recommend you to 
first optimize code before switching to unsafe.

"It's protects agaisnt all security vulnerabilities" - It is true 
 safe can prevent some security issues, but not all of them, 
remember to never trust user input.
Dec 25 2023
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 26, 2023 12:05:48 AM MST Hors via Digitalmars-d wrote:

 Optional safety is really outdated, I think some people can't see
 how important is safety almost everywhere (both for system and
 general purpose). Safe by default allows you to catch bugs
 without possibly wrecking your entire system (or systems' of
 users of your app).


As I understand it, the main reason that we've never switched to  safe by
default (aside from concerns over how to do that without breaking everyone's
code) is that code that is extern(C), extern(C++), etc. needs to be treated
as  system by default. So, if we switched to  safe by default for extern(D),
that would then be inconsistent with all of the other linkage types (on top
of whatever extra complications in the compiler that would come with having
different defaults for different linkages).

So, from what I understand, you really don't need to convince Walter or
Atila that  safe by default would be good for D code. Rather, you'd need to
convince them that the inconsistencies that that would cause in the language
would be worth it - particularly when folks who want  safe can slap it on
their code with very little effort.

- Jonathan M Davis
Dec 26 2023
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

 Optional safety is really outdated...


Yes, safety should be the default. Unfortunately, making it so 
would be a big breaking change. We're going to look into doing it 
once we get going with editions.
Dec 26 2023
parent IGotD- <nise nise.com> writes:
On Tuesday, 26 December 2023 at 08:10:51 UTC, Mike Parker wrote:

 Yes, safety should be the default. Unfortunately, making it so 
 would be a big breaking change. We're going to look into doing 
 it once we get going with editions.


Instead of trying to pry safe by default in current D, D should 
be revised totally from the ground up and design the language to 
be safe by default from the very beginning. We're talking about 
D3 or a fork here.

D is starting to show its age and it wasn't designed for "safe" 
as we know it today. Even if implemented in D, there would be 
holes in the design where unsafe can sneak in.
Dec 26 2023
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
https://dlang.org/spec/function.html#safe-functions


-No casting from a pointer type to any type with pointers other 
than void*.
-No casting from any non-pointer type to a pointer type.
-No pointer arithmetic (including pointer indexing).
-Cannot access __gshared variables.
-No inline assembler.

I hope this never becomes the default
Dec 26 2023
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 26 December 2023 at 11:32:15 UTC, ryuukk_ wrote:

 https://dlang.org/spec/function.html#safe-functions


 -No casting from a pointer type to any type with pointers other 
 than void*.
 -No casting from any non-pointer type to a pointer type.
 -No pointer arithmetic (including pointer indexing).
 -Cannot access __gshared variables.
 -No inline assembler.

 I hope this never becomes the default


I very much hope it does. It is a lot more economical.

9 out of 10 projects only need the features you mentioned 
sparingly. It is less effort to mark those place ` trusted` than 
the situation we are in now, where you need to sprinkle ` safe` 
almost everywhere.

Another way to look at is that the features you mentioned are 
almost always used exclusively in low level code that best sits 
behind an abstraction. If trusted is the default you need to mark 
anything using it ` safe`, but if safe is the default you only 
need to mark a few reusable low level pieces of code ` trusted`.
Dec 26 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
wrote:


 I very much hope it does. It is a lot more economical.

 9 out of 10 projects only need the features you mentioned 
 sparingly. It is less effort to mark those place ` trusted` 
 than the situation we are in now, where you need to sprinkle 
 ` safe` almost everywhere.

 Another way to look at is that the features you mentioned are 
 almost always used exclusively in low level code that best sits 
 behind an abstraction. If trusted is the default you need to 
 mark anything using it ` safe`, but if safe is the default you 
 only need to mark a few reusable low level pieces of code 
 ` trusted`.


The earlier proposal would have killed D. I no longer recall the 
details but it would have been miserable to interoperate with C 
code under that proposal. And without C interoperability, D is 
dead.

All that's needed is a compiler switch rather than breaking 
everyone's code. Or an easy way to shut it off. Neither of those 
were on the table.
Dec 26 2023
next sibling parent reply Hors <q q.com> writes:
On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
 wrote:


 I very much hope it does. It is a lot more economical.

 9 out of 10 projects only need the features you mentioned 
 sparingly. It is less effort to mark those place ` trusted` 
 than the situation we are in now, where you need to sprinkle 
 ` safe` almost everywhere.

 Another way to look at is that the features you mentioned are 
 almost always used exclusively in low level code that best 
 sits behind an abstraction. If trusted is the default you need 
 to mark anything using it ` safe`, but if safe is the default 
 you only need to mark a few reusable low level pieces of code 
 ` trusted`.


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.


Makes sense, instead of a breaking change. We can use another 
file extension for Safe DLang *.safeD, or [insert your idea 
here]. That file extension is just D but  safe is default, then 
it's no longer a breaking change as normal *.d codes still work.
Dec 26 2023
parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Tuesday, 26 December 2023 at 13:18:43 UTC, Hors wrote:

 On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.


 Makes sense, instead of a breaking change. We can use another 
 file extension for Safe DLang *.safeD, or [insert your idea 
 here]. That file extension is just D but  safe is default, then 
 it's no longer a breaking change as normal *.d codes still work.


An elephant in the room is the -dip1000 switch. Should or 
shouldn't it be enabled for the new *.safeD files? Here's an 
interesting old topic, where a beginner tried to explore the 
safety offered by D language: 
https://forum.dlang.org/thread/duwrxnkjaafnzpfgnted forum.dlang.org
Dec 27 2023
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
 wrote:


 [...]


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.



C interop must be explicitly marked as unsafe.
Dec 26 2023
next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

 On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
 wrote:


 [...]


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.



 that C interop must be explicitly marked as unsafe.


Aside from the massive amounts of money those languages had to 

working with C, and Rust was explicitly written for someone 
wanting safe at all costs.

D's primary selling point for many is interoperability with C and 
otherwise writing unsafe code. Not only would this break almost 
all of my existing code for no benefit, it would break any 
package I want to work with that uses unsafe code (anything on 
code.dlang.org that does anything with a pointer), so then I'm 
having to maintain my own fork of those packages. All the 
documentation and tutorials with even one line of unsafe code are 
suddenly broken.

If D had been safe by default, this would not have been a big 
issue, even for those of us that don't care about safe by 
default. But to force this on us *entirely because you don't want 
to add a -safe switch to the compiler* is completely 
unreasonable. (The compiler switch was off the table, but the way 
you tested out the earlier DIP was by *using a compiler switch*.)
Dec 26 2023
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 26 December 2023 at 15:35:55 UTC, Lance Bachmeier 
wrote:

 On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

 On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan 
 Koppe wrote:


 [...]


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.



 that C interop must be explicitly marked as unsafe.


 Aside from the massive amounts of money those languages had to 

 working with C, and Rust was explicitly written for someone 
 wanting safe at all costs.


Cgo has been part of Go since the early days, Swift has been 
designed with interoperability with Objective-C (a C superset), 
and C++ has been supported in .NET since version 1.0 (yet another 
C superset).


 D's primary selling point for many is interoperability with C 
 and otherwise writing unsafe code. Not only would this break 
 almost all of my existing code for no benefit, it would break 
 any package I want to work with that uses unsafe code (anything 
 on code.dlang.org that does anything with a pointer), so then 
 I'm having to maintain my own fork of those packages. All the 
 documentation and tutorials with even one line of unsafe code 
 are suddenly broken.


How is that selling point going on since Andrei's book has been 
published, in terms of D market share versus all newcomers?


 If D had been safe by default, this would not have been a big 
 issue, even for those of us that don't care about safe by 
 default. But to force this on us *entirely because you don't 
 want to add a -safe switch to the compiler* is completely 
 unreasonable. (The compiler switch was off the table, but the 
 way you tested out the earlier DIP was by *using a compiler 
 switch*.)


On which forum post am I advocating against -safe switch?
Dec 26 2023
parent bachmeier <no spam.net> writes:
On Tuesday, 26 December 2023 at 19:32:56 UTC, Paulo Pinto wrote:


 If D had been safe by default, this would not have been a big 
 issue, even for those of us that don't care about safe by 
 default. But to force this on us *entirely because you don't 
 want to add a -safe switch to the compiler* is completely 
 unreasonable. (The compiler switch was off the table, but the 
 way you tested out the earlier DIP was by *using a compiler 
 switch*.)


 On which forum post am I advocating against -safe switch?


Not you, but that was the safe by default proposal. It can be 
done at no cost, but it's hard for improvements that come without 
cost to get traction around here.

Similar to the LTS discussions. All they needed to do was label 
some of the releases they were making as "not LTS" and they'd 
have solved a major problem at no cost. More than six months have 
passed and there are occasional discussions of "editions" that 
will solve the same problem. Maybe before 2030.
Dec 28 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

 On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
 wrote:


 [...]


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.



 that C interop must be explicitly marked as unsafe.


Microsoft sells tooling and services, they have an army of 
"evangelists" to corrupt, i mean to lobby companies / governments 
all around the world, these people are driven by an economical 
motive to vendor lock you

Same for Apple/Swift, and same for Google/Go

Rust is similar, as it consist of a conglomerate of them all

I don't use D because i want corporate-credibility, i use it 
because it gets the job done faster than anything else (is it 
even still the case btw?)
Dec 26 2023
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 26 December 2023 at 17:27:46 UTC, ryuukk_ wrote:

 On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

 On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

 On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan 
 Koppe wrote:


 [...]


 The earlier proposal would have killed D. I no longer recall 
 the details but it would have been miserable to interoperate 
 with C code under that proposal. And without C 
 interoperability, D is dead.

 All that's needed is a compiler switch rather than breaking 
 everyone's code. Or an easy way to shut it off. Neither of 
 those were on the table.



 that C interop must be explicitly marked as unsafe.


 Microsoft sells tooling and services, they have an army of 
 "evangelists" to corrupt, i mean to lobby companies / 
 governments all around the world, these people are driven by an 
 economical motive to vendor lock you

 Same for Apple/Swift, and same for Google/Go

 Rust is similar, as it consist of a conglomerate of them all

 I don't use D because i want corporate-credibility, i use it 
 because it gets the job done faster than anything else (is it 
 even still the case btw?)


Hardly, unfortunately, unless there are libraries available, 
which is increasingly harder as many aren't updated to keep up 
with D vlatest.

Which makes this safety discussion a moot point, too late to 
change it, even with the languages that prove otherwise, those 
libraries wouldn't be updated to safety by default.
Dec 26 2023
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe 
wrote:

 On Tuesday, 26 December 2023 at 11:32:15 UTC, ryuukk_ wrote:

 https://dlang.org/spec/function.html#safe-functions


 -No casting from a pointer type to any type with pointers 
 other than void*.
 -No casting from any non-pointer type to a pointer type.
 -No pointer arithmetic (including pointer indexing).
 -Cannot access __gshared variables.
 -No inline assembler.

 I hope this never becomes the default


 I very much hope it does. It is a lot more economical.

 9 out of 10 projects only need the features you mentioned 
 sparingly. It is less effort to mark those place ` trusted` 
 than the situation we are in now, where you need to sprinkle 
 ` safe` almost everywhere.

 Another way to look at is that the features you mentioned are 
 almost always used exclusively in low level code that best sits 
 behind an abstraction. If trusted is the default you need to 
 mark anything using it ` safe`, but if safe is the default you 
 only need to mark a few reusable low level pieces of code 
 ` trusted`.



I understand, you got a point, it makes the ecosystem better, so 
i'm probably wrong here

But i personally don't use any of these attribute in my code 
bases, they are pure annoyances, most of the time

Will it solve problems like these?

https://github.com/dlang/dub/issues/2600

https://forum.dlang.org/thread/mjmufdnrcexliatzgkwh forum.dlang.org


I'd rather see time spent working on getting features that help 
people's code compile faster (dub doubled their compile time by 
starting to use std.sumtype) instead of making more of them no 
longer compile because they do not comply with dmd  christmas 
tree decoration edition

Let's put it that way, if most of my code consist of low level 
bits, why should i mark everything  unsafe? I view unsafe as a 
feature, not as a bug

I hope it'll be toggleable with a compiler flag
Dec 26 2023
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

 So I think  safe should be default in dlang.


So does most everybody else, including library authors who would 
be primarily affected by the potentially breaking change.

See this from the author of vibe, dated March 15, 2015: 
http://arsdnet.net/this-week-in-d/mar-15.html

Or this from the author of arsd, dated April 17, 2016:
http://arsdnet.net/this-week-in-d/2016-apr-17.html

Or this from the author of dmd, dated January 2, 2020:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md
Dec 26 2023
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

 Optional safety is really outdated, I think some people can't 
 see how important is safety almost everywhere (both for system 
 and general purpose). Safe by default allows you to catch bugs 
 without possibly wrecking your entire system (or systems' of 
 users of your app).


The correct way forward on this is to enable inference of ` safe` 
for (almost) all functions. No existing projects will break, and 
if you don't use any unsafe language features (pointer 
arithmetic, casting), your code will automatically become ` safe` 
with no intervention required.

Adam Ruppe has a good writeup of this approach on his blog: 
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_07_11.html#inferred-attributes
Dec 26 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Agreed this is the way forward.

Only way to let people who don't care about safety to continue to not do so.

Also need things like contract invalidation for callbacks.

Still no idea how we'll deal with virtual types.
Dec 26 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
 safe code is just as fast as  system code. You might be thinking about the 
switch that turns runtime array bounds checking on/off.

Yes, safety should be the default, but we don't want to break existing code.
Dec 26 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 27 December 2023 at 07:42:31 UTC, Walter Bright 
wrote:

  safe code is just as fast as  system code. You might be 
 thinking about the switch that turns runtime array bounds 
 checking on/off.

 Yes, safety should be the default, but we don't want to break 
 existing code.


My understanding is that people are suggesting a new global 
compiler switch to optionally disable safety (allow ` system` and 
` trusted` to be called from ` safe`), which would indeed allow 
compiling old abandoned libraries and use them from the new code 
during the transition period.
Dec 27 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2023 12:29 AM, Siarhei Siamashka wrote:

 My understanding is that people are suggesting a new global compiler switch to 
 optionally disable safety (allow ` system` and ` trusted` to be called from 
 ` safe`), which would indeed allow compiling old abandoned libraries and use 
 them from the new code during the transition period.


Hmm, that is an interesting idea. The implementation might be tricky, though,
as 
 safe/trusted/system are baked into the typing system at a fundamental level.
Dec 28 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
It may be easier to disable it at the parser level instead of semantic.
Dec 28 2023
prev sibling parent Leonardo <leotada523 gmail.com> writes:
On Friday, 29 December 2023 at 02:04:01 UTC, Walter Bright wrote:

 On 12/27/2023 12:29 AM, Siarhei Siamashka wrote:

 My understanding is that people are suggesting a new global 
 compiler switch to optionally disable safety (allow ` system` 
 and ` trusted` to be called from ` safe`), which would indeed 
 allow compiling old abandoned libraries and use them from the 
 new code during the transition period.


 Hmm, that is an interesting idea. The implementation might be 
 tricky, though, as  safe/trusted/system are baked into the 
 typing system at a fundamental level.


**My idea**:
Add  unsafe to act like  trusted, that can be applied on modules, 
enabling call from  safe but only if a compiler switch was 
enabled to allow use of  unsafe code. Then change default to 
 safe.
Jan 04