January 03, 2020
On 1/2/20 4:47 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
> 
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md 
> 
> 
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
> 
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
> 
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
> 
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> 
> *Please stay on topic!*
> 
> Thanks in advance to all who participate.

Add to rationale:

The vast majority of non-template code written is @safe, but not marked as such. This means many projects cannot enable safe because their dependencies were not marked that way. This will correct that for all those dependencies.

e.g.: I made most of diet-ng safe so I could enable runtime diet templates (see PR here: https://github.com/rejectedsoftware/diet-ng/pull/70). Many of my changes were to enable @safe at runtime (most things were not marked safe because CTFE doesn't require @safe, and most of diet is using CTFE).

For the safety changes, most of what I did was simply to slap @safe: at the top, or inside types which were not templates. The one exception was object.opEquals, which I had to write a trusted wrapper for.

But in any case, it's a good rationale. I write non-template code ALL the time that is safe, but don't think to mark it. Same can be said about pure and nothrow.

-Steve
January 03, 2020
On Friday, 3 January 2020 at 13:43:27 UTC, Manu wrote:
> 'system' is a weird name for 'unsafe'. ...
> We have exactly one opportunity to correct this, and this is it.

I was going to give this a +1, but upon further reflection, I think @system is more correct.

The code that would be marked @unsafe is only "potentially unsafe". In most cases, the code that would be marked as @unsafe is bug-free and perfectly safe to execute.

@system is intended as a warning that this code requires careful consideration before making changes. It is a "here be dragons" type warning, not an indication that there are problems in this piece of code. There could be a better name than @system, but I don't think @unsafe is a better choice because it implies there "is" a problem with the code rather than just saying "be cautious".

Dennis Cote

January 03, 2020
On Friday, 3 January 2020 at 10:37:15 UTC, Walter Bright wrote:
> I don't really understand what the problem is.

That a lot of working code will no longer compile without wasting a lot of time fixing it, including having to make changes to code you didn't write but are calling.

> Making code @safe by default will not cause code to regress into bugginess.

But it won't compile, even though it does *exactly* what it's supposed to do. I don't think this is a complicated point. And the fact that all the documentation and forum posts currently on the internet will be broken. And the fact that this makes it harder for people to learn the language.

> What it will do is necessitate labeling code with @system that were always @system already.

I'll send you my code and hopefully you can make all the necessary changes in a timely manner. Frankly, I'm shocked that you all of a sudden think major breaking changes in the language are no big deal.

What really has me puzzled is that this is a change with such a limited benefit. D already has @safe. If you want to make safe by default an option, add a -safe flag to the compiler and the problem is solved with no code breakage and no confusion, and you can appeal to the tiny sliver of programmers Rust was created for and that will never be interested in D anyway. Breaking changes can be good, but careful thought needs to be used to minimize the cost of those changes.
January 03, 2020
On Friday, 3 January 2020 at 19:03:46 UTC, Dennis Cote wrote:
> The code that would be marked @unsafe is only "potentially unsafe". In most cases, the code that would be marked as @unsafe is bug-free and perfectly safe to execute.


"unsafe" is the defacto terminology for code that isn't type checked, i.e. verified. "safe" means that it is verified: type-safety, memory-safety etc.

An unsafe type system is a type system that can be broken if you make an effort to break it.  It is still unsafe if nobody ever wrote any code that broke it.

Type safety is about providing mechanical guarantees that cannot be broken no matter what code you write.


> but I don't think @unsafe is a better choice because it implies there "is" a problem with the code rather than just saying "be cautious".

It tells the compiler that the code is intended to not be type checked for memory safety, so it intentionally unsafe (e.g. unchecked).

Code is not safe until it has been mechanically verified.

This is standard usage of the term safe and unsafe.

January 03, 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

I'm still against:
- it break everything for everyone, so we'll lose working packages on code.dlang.org who happen to have no maintainer but have worked for years
- it doesn't seem like Community input is wanted in any way, it's all "there is no choice"
- ...but doing it just move the default. It's not an enabler for "safe reference counting" or things like that, since it's just a default.
- benefits are overstated since D has always had a lot less memory corruption than C++ (thanks to slices, GC, bounds-checks, and default initialization!). And C++ has less corruption than C thanks to encapsulation. CVE are often due to C which has the maximum number of corruptions.

If one's software is an attack vector, then people that care could use the @safe subset instead of making the life of every beginner worse.


January 03, 2020
On Friday, 3 January 2020 at 20:59:45 UTC, Guillaume Piolat wrote:
> I'm still against:
> - it break everything for everyone, so we'll lose working packages on code.dlang.org who happen to have no maintainer but have worked for years

This is technical problem with solutions like this one:
https://forum.dlang.org/post/vcubtfjpwzbsleayexwy@forum.dlang.org

> - ...but doing it just move the default. It's not an enabler for "safe reference counting" or things like that, since it's just a default.
> - benefits are overstated

Defaults are enormously important though. Putting aside the
rate of bugs, when you *do* have one in front of you, defaults
matter more than anything else in terms of how readily you can
find the problem. When @safe is the default, if you have a
memory error, you can grep your code base for the nonsafe bits
and catalogue them and start there.

Another result: people will try something, get an error, and
then ask: "should I mark this @trusted so I can do what I
wanted, or use a safer construct and not have to do that?" Just
the question is helpful, but it's also likely that there will
be a greater incidence of people going with the safer construct
and then avoiding problems altogether.

Another result: instead of the status quo of "mark something
@safe -> get explosion of errors because so much code is
@system unnecessarily -> realize what a chore it would be to
make @trusted interfaces to this code -> remove @safe", you're
more likely to not have problems at all because the code you
call is already @safe because that's the default.

Another result: just by having the compiler option and a
deprecation cycle started, people will start actually reporting
problems with @safe, like they are in this thread right now,
instead of running into those problems and grumbling "eh I
guess this is half baked, I'll just not use it".

January 03, 2020
On Friday, 3 January 2020 at 21:24:03 UTC, mipri wrote:
> Another result: instead of the status quo of "mark something
> @safe -> get explosion of errors because so much code is
> @system unnecessarily -> realize what a chore it would be to
> make @trusted interfaces to this code -> remove @safe", you're
> more likely to not have problems at all because the code you
> call is already @safe because that's the default.

Which is another way to say you will loose productivity all the time, before you know if that software has any business being good in the first place.
Companies write lots of small tools, many of which can (and should) be pretty crappy! Else it's just bad focus.
Like I said on Rust context: if you write a hello world, no one cares who owns the string "hello world".


> Another result: just by having the compiler option and a
> deprecation cycle started, people will start actually reporting
> problems with @safe, like they are in this thread right now,
> instead of running into those problems and grumbling "eh I
> guess this is half baked, I'll just not use it".

A less charitable view on this is that people don't use @safe because it brings them too little value.
"let's make this attribute mandatory because the opt-in version isn't successful" is not really Community input.


January 03, 2020
On Friday, 3 January 2020 at 21:53:29 UTC, Guillaume Piolat wrote:
> On Friday, 3 January 2020 at 21:24:03 UTC, mipri wrote:
>> Another result: instead of the status quo of "mark something
>> @safe -> get explosion of errors because so much code is
>> @system unnecessarily -> realize what a chore it would be to
>> make @trusted interfaces to this code -> remove @safe", you're
>> more likely to not have problems at all because the code you
>> call is already @safe because that's the default.
>
> Which is another way to say you will loose productivity all the time, before you know if that software has any business being good in the first place.
> Companies write lots of small tools, many of which can (and should) be pretty crappy! Else it's just bad focus.

But isn't this kind of code even more likely than most code to
be @safe? This isn't @nogc. It's just these restrictions:

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

The big one is "no calling system functions" and this DIP
will do a lot to alleviate the pain of that restriction. The
other stuff, you run into when you're trying to be clever or
improve code. Swap out the unnecessary copies of this idup by
casting stuff to immutable, e.g.
January 03, 2020
On 1/3/20 3:59 PM, Guillaume Piolat wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
>> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md 
>>
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> *Please stay on topic!*
>>
>> Thanks in advance to all who participate.
> 
> I'm still against:
> - it break everything for everyone, so we'll lose working packages on code.dlang.org who happen to have no maintainer but have worked for years

Can we auto-check this? It should be as easy as checking out each package and doing dub build with an altered compiler, along with the current one. If the current compiler builds but the altered one does not, then you have found an issue to be reported/analyzed. Such use cases would be instrumental for finding a reason NOT to do this DIP, or alternatively, show how little breakage would be.

I tend to think that the breakages will be both minor and few.

> - it doesn't seem like Community input is wanted in any way, it's all "there is no choice"

There is no choice in that D must support safety. But I'm certain that if there were a very compelling reason not to make it the default, this would not be accepted. This IS the community feedback.

> - ...but doing it just move the default. It's not an enabler for "safe reference counting" or things like that, since it's just a default.

It's very much an enabler because people tend to write safe code all the time without marking it. For example, I'm sure iopipe (with the exception of the calls into c-libraries such as memchr and zlib) can be marked safe. But I didn't, because I haven't bothered to worry about it. But absolutely it should be @safe.

I'd probably have to adjust a few things, and then it will build. The benefit is huge, because then someone doesn't have to choose between memory safety and iopipe speed. If the compiler complained about this when I was developing it, I'd fix the problems as they happened.

> - benefits are overstated since D has always had a lot less memory corruption than C++ (thanks to slices, GC, bounds-checks, and default initialization!). And C++ has less corruption than C thanks to encapsulation. CVE are often due to C which has the maximum number of corruptions.

The difference will be huge. I don't know if this can be overstated. I'd say 99% of code written is ALREADY safe. But we are missing out on the benefits of that because we don't bother marking (lazy idiots that we are). Then you have an ecosystem that is safe-unfriendly, and it begets more code that is safe unfriendly. Once any dependency didn't pay attention to safe, you have to deal with it with @trusted at the higher levels, and it's turtles all the way down. This is very similar to the const problem.

Take for example, mysql-native. Nothing in there is really safe friendly, yet. So if I want to use mysql, I have to make MY code safe-unfriendly, or just insert trusted escapes for everything, hoping that mysql-native is really actually safe (it pretty much is).

One step further, vibe.d now complains all over the place that your handlers are not safe, especially for REST routes. If I want to use mysql-native and vibe.d, everything either has to be trusted, or I have to use some other library.

When the compiler complains about the 1% of your code that isn't mechanically checkable as safe, you will spend the 1% of your time to fix it, and move on. It will just feel like another syntax error "oh yeah, I forgot a semicolon". I don't complain about semicolon requirements, I just fix them and move on.

> If one's software is an attack vector, then people that care could use the @safe subset instead of making the life of every beginner worse.

How does this make beginner life worse? Does the beginner start off doing pointer math, or using void *? The advantage here is that D eschews such things for more safe features, so D code is usually safe anyway!

void main()
{
   import std.stdio;
   writeln("Hello, world!");
}

will still work.

-Steve
January 03, 2020
On Friday, 3 January 2020 at 22:13:28 UTC, Steven Schveighoffer wrote:
>
> I'd probably have to adjust a few things, and then it will build. The benefit is huge, because then someone doesn't have to choose between memory safety and iopipe speed. If the compiler complained about this when I was developing it, I'd fix the problems as they happened.
>

Can anyone produce ONE example of a memory corruption code they write that was found with use of marking something @safe?