January 07, 2020
On Tuesday, 7 January 2020 at 10:01:29 UTC, Max Samukha wrote:
> I don't think there is such thing as "industry accepted convention" with regard to "unsafe".


It is standard terminology for program semantics going unchecked both statically and dynamically.

"unsafe" does not say that the written code is doing anything wrong. "unsafe" means that the compiler isn't doing what is expected from a proper high level language in terms of catching illegal constructs.

A language defines a set of text strings that is considered legal (valid) code. In a well specced language all legal code is safe.

Most compilers fail to catch all illegal constructs and will emit code for programs that does not belong to the defined language. A decent (safe) language will then emit runtime checks that will catch such programs at runtime and stop them (e.g. indexes out of bounds).

However, in an unsafe language, or unsafe language mode, or unsafe language constructs, the compiler and runtime will not detect and stop programs that don't belong to the defined language.

That is the meaning of "unsafe".

January 07, 2020
On Tuesday, 7 January 2020 at 10:25:36 UTC, Ola Fosheim Grøstad wrote:
> "unsafe" does not say that the written code is doing anything wrong. "unsafe" means that the compiler isn't doing what is expected from a proper high level language in terms of catching illegal constructs.

I actually like how "unsafe" sounds dangerous. It sounds like something to be avoided, and that's how unsafe should be used in a safe-aware code. You should avoid using it unless needed, and when used it should scream at you "this is dangerous". Kind of like UPPERCASE_DEFINE_MACROS in C.
January 07, 2020
On Tuesday, 7 January 2020 at 11:10:03 UTC, JN wrote:
> I actually like how "unsafe" sounds dangerous. It sounds like something to be avoided, and that's how unsafe should be used in a safe-aware code.

Exactly, like walking on a line without a safety rope, biking without a helmet, using a chainsaw without protective gear... Unsafe = higher probability for failure.

Analogy: I've never cut into my protective gear with a chain saw, but I've been close several times... You can work much faster with protective gear on as you can focus more on the work and keep the saw close (which makes the work more precise).

> You should avoid using it unless needed, and when used it should scream at you "this is dangerous". Kind of like UPPERCASE_DEFINE_MACROS in C.

An interesting point is that a language competing directly with C must be an unsafe language. A Turing complete language must emit runtime checks in order to finish static analysis in finite time (unless you put in fixed limits).

January 07, 2020
On Tuesday, 7 January 2020 at 10:22:08 UTC, Max Samukha wrote:
> On Tuesday, 7 January 2020 at 07:14:43 UTC, Paulo Pinto wrote:
>
>> The very first systems programming language that introduced the concept of unsafe blocks was ESPOL, followed by NEWP for the Burrougs B5500, in 1961.
>>
>> Other idea that they introduced, at the OS level, was that any binary containing unsafe code was tainted and required clearance from the system admin to be executable.
>>
>> 8 years before C was even an idea.
>>
>> Unsafe has a long tradition in safe systems programming languages, and D is one of very few exceptions that has chosen something else.
>
> Interesting. However, I didn't say that C# was the first to introduce the concept or name. I said that I didn't like the name when I first encountered it in C#. Also, you suggest that there is really a tradition, which is arguable.

If we count the amount of safe system programming languages that have used unsafe and the others that have used something else, unsafe leads.

D (@system), Ada (Unchecked), Oberon variants (SYSTEM pseudo-module) are the only ones that occur to me as not following up on unsafe.


January 07, 2020
On Tuesday, 7 January 2020 at 10:25:36 UTC, Ola Fosheim Grøstad wrote:

> However, in an unsafe language, or unsafe language mode, or unsafe language constructs, the compiler and runtime will not detect and stop programs that don't belong to the defined language.
>
> That is the meaning of "unsafe".

Yeah, I know about that definition of "unsafe", thank you for a lecture on basic CS. I still cannot agree that the term "unsafe" is measurably more conventional than "unchecked" or "system".
January 07, 2020
On Tuesday, 7 January 2020 at 13:32:32 UTC, Max Samukha wrote:
> I still cannot agree that the term "unsafe" is measurably more conventional than "unchecked" or "system".

"unchecked" seems reasonable, but "system" could be interpreted as access to operating system specific features rather than fully portable features.


January 07, 2020
On Tuesday, 7 January 2020 at 13:32:32 UTC, Max Samukha wrote:
> On Tuesday, 7 January 2020 at 10:25:36 UTC, Ola Fosheim Grøstad wrote:
>
>> However, in an unsafe language, or unsafe language mode, or unsafe language constructs, the compiler and runtime will not detect and stop programs that don't belong to the defined language.
>>
>> That is the meaning of "unsafe".
>
> Yeah, I know about that definition of "unsafe", thank you for a lecture on basic CS. I still cannot agree that the term "unsafe" is measurably more conventional than "unchecked" or "system".

How about "shrug" or "meh"?

IE... "it might work ok but I couldn't be arsed to check."
January 07, 2020
On Tuesday, 7 January 2020 at 13:32:32 UTC, Max Samukha wrote:
> On Tuesday, 7 January 2020 at 10:25:36 UTC, Ola Fosheim Grøstad wrote:
>
>> However, in an unsafe language, or unsafe language mode, or unsafe language constructs, the compiler and runtime will not detect and stop programs that don't belong to the defined language.
>>
>> That is the meaning of "unsafe".
>
> Yeah, I know about that definition of "unsafe", thank you for a lecture on basic CS. I still cannot agree that the term "unsafe" is measurably more conventional than "unchecked" or "system".

extern(System) @safe void foo()
{
}

I think system is over used as it is. And unsafe makes more sense than unchecked. Putting a ladder on a table is unsafe, it doesn't mean something bad is going to happen if you do. It just has more potential relatively to putting it on the ground.


January 07, 2020
On Friday, 3 January 2020 at 11:06:32 UTC, Walter Bright wrote:
>
> Modules can be labeled as @system by beginning them with:
>
>    @system:
>

As mentioned countless times already, this has a widely different effect.

>> First, because '@safe', and attributes by extension, is currently not a practical tool, and even not usable in some cases.
>
> Issues not in bugzilla do not get fixed. Please add issues that make it not practical or usable to bugzilla and mark them with the `safe` keyword.

https://issues.dlang.org/show_bug.cgi?id=17953
This affects object.Throwable.toString. I'm not asking for that specific syntax, but we do need a way to say "delegate attributes in, delegate attributes out".

>> It is currently painful to mix differently-attributed code if you are not going full template (e.g. classes, delegates). I've worked for two companies using D, and none of them used @safe, and were more on the low-level side of things.
>
> It is true that using @safe successfully will often entail some level of refactoring to separate the safe code from unsafe code. It is perfectly fine if you choose to not use @safe.

Except that I do not control all the code I write. Some libraries will use `@safe` everywhere, some won't. And mixing them becomes a nightmare. For example, I'd be very happy to live without `@safe`, but I use Vibe.d, which forces `@safe` on me because some people wanted to be able to use `@safe` in the first place. This is the kind of ecosystem split people keep talking about.

>> In fact, @safe wouldn't even have prevented most of the bug we had,
>
> Most is not all, and the bugs it does uncover tend to be the ugly ones. I recently spent 3 days trying to track down a memory corruption bug in DMD. These are not happy hours for me. Detecting problems at compile time is infinitely cheaper.

In terms of cost/benefit ratio, it does not cross the mark for me.
I also recently spent 3 days debugging a memory corruption issue, happening because of a stack overflow, something `@safe` can't prevent. So here's another anecdotal evidence for your anecdotal evidence.

> It's also the future. It's clear where languages are going. Unsafe languages are going on the ash heap of history. We can either get in front of this sea change, or get run over by it.

If I wanted to be using Rust, I would be using Rust.


> The simplest way to be compatible with the switch is to simply label things that don't compile as @system. Or just put @system: at the beginning.
>
> As for DMD, I intend to take advantage of this feature as soon as it is accepted. Keep in mind that DMD was originally a "C with Classes" program, with no notion of @safe (or const, pure, nothrow, or nogc).

And I invite you to try it already (you don't need it to be merged to start fixing `@safe`ty issues) to see the effect. Note that DMD is not a library and has almost no dependency, which makes fixing issues much simpler.

>> Side note, using this flag to compile Phobos would most likely result in link failures, like it did with DIP1000.
>
> We fixed the link failures with DIP1000.

Because `scope` is ignored for mangling. `@safe` cannot be ignored, so the same solution cannot be used.

>> Third, we start to have a few DIPs piling up in the -preview section. DIP25, DIP1000, DIP1008. Some libraries use it, some don't, and adding more features there will only balkanize the language more.
>
> All programming languages improve or die.

I don't disagree with improving the language, I disagree with the way of doing it. If `@safe` was hassle-free we wouldn't be having this conversation, but it's not, and making it the default just switch the hassle to someone else.


> > actually finish what we started.
>
> All issues need to go into bugzilla. Issues not in bugzilla do not get fixed.

There's a trove of issues in bugzilla to pick from. But put in simpler terms: Where is `@safe` reference counting ?


>> TL;DR: Disruptive change that requires every D user to put some work to support it (possibly many months worth of work), yet no evidence that a single large-scale project have been experimented with while writing this DIP.
>
> Nobody will try it, either, unless and until it is actually put into the compiler.

And then, nobody will try it unless druntime / Phobos is compiled with it. But then we're back to the point where it's not really opt-in because of link failures. I'll add more of that on the PR itself.
January 07, 2020
On 1/7/2020 10:38 AM, Mathias Lang wrote:
> Except that I do not control all the code I write. Some libraries will use `@safe` everywhere, some won't. And mixing them becomes a nightmare. For example, I'd be very happy to live without `@safe`, but I use Vibe.d, which forces `@safe` on me because some people wanted to be able to use `@safe` in the first place. This is the kind of ecosystem split people keep talking about.

Defaulting to @safe will ironically mitigate these types of issues.

I understand this will cause some disruption. I don't know of any way to avoid it. The best we've come up with is -preview/-revert switches.

The worst you'll have to do is manually add @system to individual functions.


> If I wanted to be using Rust, I would be using Rust.

I don't want to use Rust, either.


> But put in simpler terms: Where is `@safe` reference counting ?

There have been a number of DIPs which help in that direction.


> And then, nobody will try it unless druntime / Phobos is compiled with it. But then we're back to the point where it's not really opt-in because of link failures. I'll add more of that on the PR itself.

For Phobos to work with and without the -preview switch, it'll likely need specific @system/@trusted/@safe annotations on all non-inferred functions. It's mostly done already anyway, this will just help us finish the job.