On 5/22/20 6:13 AM, Dukc wrote:
> Wrong :-(. The scenario is this:
> 
> ```
> @safe void foo(int* p)
> {   import customfreefunction.noannotations;
>      p.free;
>      p.free;
> }
> ```
> 
> Now, this will not compile, because `free` is `@system`. But if `free` is in unannotated module, this will compile after the DIP implementation. Obviously not with the standard library `free` because it'll be annotated `@system` anyway, but with some custom `free` function this is an issue.

I want to interject slightly to say that this isn't the exact problem. The exact problem is that today `foo` is NOT marked @safe (or else it wouldn't compile). But after the DIP it will be IMPLICITLY marked safe, and so will `free`. Thereby silently migrating all system code that should actually be (and was INTENDED to be) system code straight to safe code without any warnings.

This in itself isn't a problem, code that compiled yesterday compiles today, and is just as bad.

The true problem is that after the DIP is implemented, new users will use foo within safe code they INTEND to be safe, and will be none the wiser that it's not.

The scenario I imagine is that unadorned code will exist for years as @safe (implicitly) and only after years of being depended on as @safe code, is discovered to be completely unsafe, and the only way to fix is to break existing usage. Or worse, it's not discovered and then D's already shaky reputation for @safe code is destroyed when a hacker exploits the memory corruption in fully-marked @safe code.

The actual bug may be extremely subtle. We have code in phobos that does stuff like:

static if(is(typeof(() @safe { obj.doSomething(); }))) obj.doSomething();
else doSomethingSafely(obj);

which will silently switch to using unsafe (but marked safe) mechanisms (for optimization).

-Steve

On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote:
> DIP 1028, "Make @safe the Default", has been accepted without comment.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md

I've made a draft PR to try and address the potential safety issue discussed in this thread. Any and all constructive feedback is greatly appreciated, so feel free to comment:

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

On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer wrote:
> [snip]
>

Fortunately, the above point can be more easily fixed by making `free` @system, which will then require annotating every subsequent piece of code that touches it. It's annoying transition, but it's do-able. The problem is when you aren't sure what needs to be marked @system. For instance, if you have some function now that is @system by default and does pointer arithmetic, then the switch to @safe by default will result in that no longer compiling. That's good. The emphasis on prototypes is that the compiler will not be able to notify you that the function should not be compiled. If the `free` function comes from a prototype (and thus cannot be manually verified by the compiler), then that is much worse for safety than a `free` function with the full body available.

This comes back to a point I had made on one of the original DIP discussion threads that one issue is that @safe is a blacklist of things you can't do rather than a whitelist of allowed things. If @safe were designed as a whitelist, then only things that are compiled verified could be marked @safe. That means that a function without a body should not be inferred to be @safe.

That `static if` thing just looks like a nightmare, but I think the point still applies that you will get error messages if the body is available and you try to do something that isn't @safe.

On Friday, 22 May 2020 at 16:39:42 UTC, jmh530 wrote:
> Fortunately, the above point can be more easily fixed by making `free` @system

With the o/b system `free` might actually work out OK....

On Fri, May 22, 2020 at 12:03:00PM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: [...]
> Or worse, it's not discovered and then D's already shaky reputation for @safe code is destroyed when a hacker exploits the memory corruption in fully-marked @safe code.
[...]

TBH, this whole fiasco just confirms my initial skepticism about @safe. The concept of mechanical verifiability is cool, I'm on board with that. But the execution of it in @safe up to before this DIP already left a lot to be desired (the beginning of which is the fact that @safe is based on a blacklist rather than a whitelist, but let's not go there now).  Now with this DIP, it's basically another nail in the @safe coffin.

Essentially what it means is that @safe is a nice tool to have for casual use, but don't depend on it for real-world, mission critical use, because it doesn't have the strong guarantees you might imagine it has. It promises a lot in bold letters, but the fine print contains a lot of disclaimers.

Which means, in my case, it's not worth bothering with. The amount of effort required to make code 100% @safe is just not worth the leaky "guarantees" it brings.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

On 5/22/20 12:39 PM, jmh530 wrote:
> On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
> 
> Fortunately, the above point can be more easily fixed by making `free` @system, which will then require annotating every subsequent piece of code that touches it. It's annoying transition, but it's do-able.

You can't, you don't control that code, someone else does (this is important, you can declare extern(C) functions anywhere, even locally).

And from the experience of .save for forward ranges, people just aren't going to do this. They are going to do the easiest thing that works without complaint -- i.e. don't bother marking.

> That `static if` thing just looks like a nightmare, but I think the point still applies that you will get error messages if the body is available and you try to do something that isn't @safe.

It essentially is a "best effort" at calling the right thing. The code compiles either way, and be @safe either way, but will do the unsafe thing when it really should do the safe thing. It's ACTIVELY trying to ensure safety, but the compiler will thwart it.

-Steve

On Fri, May 22, 2020 at 04:39:42PM +0000, jmh530 via Digitalmars-d-announce wrote: [...]
> This comes back to a point I had made on one of the original DIP discussion threads that one issue is that @safe is a blacklist of things you can't do rather than a whitelist of allowed things.
[...]

Yes, and that's why @safe has been on a shaky foundation since the beginning.  In theory, a perfect, bug-free blacklist is equivalent to a perfect, bug-free whitelist.  But given the rate at which D is adopting new features, and the combinatorial explosion of feature combinations, any of which might lead to violation of @safe, my confidence level on the completeness of the blacklist is on the low side.  Had it been a whitelist, it would have been much better, because when people ran into a combination of features that ought to be allowed, but isn't, they would file a bug, and then that case could be added to the whitelist after careful vetting. You always err on the safe side. With a blacklist, you're playing catch-a-mole with missed cases, overlooked cases, and you never have complete certainty that you've weeded out all dangerous constructs.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra

On Thursday, 21 May 2020 at 23:49:22 UTC, Bruce Carneal wrote:
> On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:
>> On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
>>> [...]
>>
>> ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless.
>
> As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see.  If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down".
>
> Atila, what's your take on all this?  Is it fork time?

No.

On Friday, 22 May 2020 at 03:57:22 UTC, H. S. Teoh wrote:
> On Thu, May 21, 2020 at 06:22:19PM -0700, Walter Bright via Digitalmars-d-announce wrote:
>> I have made these points before, but I'll summarize them here for convenient referral.
> [...]
>
> Thank you.  This makes your position clear, even if I don't entirely agree with it.  On that note, though: this really should have been part of the DIP acceptance announcement, not added as an afterthought. Otherwise people will perceive (correctly or not) the DIP as being accepted without acknowledging any of the issues raised.  This summary is exactly what would have defused a lot of the frustrations raised here.  For the future may I recommend making it a point to include such a summary with the announcement of each DIP accepted/rejected.
>
>
> T

This is a very good point, and I think that in the future Walter and I should attach an explanation of why a DIP got accepted or not for transparency and communication reasons.

On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
> On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
>> With the rationale laid out clearly as it is here, I do have some responses in mind.  But before sharing them, I'd like to know whether that would be useful right now: I've no wish to just press for a re-hashing of conversations that have already been had.
>
> No.
>
> This wasn't the first and certainly won't be the last time we as a community have been very unhappy with how Walter conducts himself with his DIP's.
>
> Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position.

I'm going through posts in order, so apologies if I'm "ignoring" something that shows up later in the discussion.

Personally and initially, I would have preferred it if non-extern(D) declarations were implicitly @system. I understood Walter's argument about special cases and how they're bad, but the thought of them being @safe made me feel, for lack of a better word, "icky".

Then I talked to Walter and he pointed out that if those declarations were @system, users would be prevented from calling them from now @safe code. A regular user would probably just slap `@safe:` at the top of the bindings module anyway. Then I realised that I did exactly that with my libclang bindings:

https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L254

"Worse", I made all functions `pure` and all parameters `in` as well for good measure. Why? I wanted to call them from my @safe pure code with `const` arguments. My reasoning at the time was "I trust libclang".

And so I was convinced that everything being @safe is actually ok, especially because in real life, most C/C++ APIs aren't going to secretly corrupt your code.

Then there's the fact that, today, there's no safety anyway calling anything because everything is @system by default. And D source code won't be able to lie.

Does that clear it up?