On Thu, Mar 26, 2020 at 5:17 PM Manu <turkeyman@gmail.com> wrote:

> On Thu, Mar 26, 2020 at 12:15 AM Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> In response to Walter's response to ag*, I would say that there is a fatal problem with automatically allowing extern(C) function prototypes (and really, anything that does not mangle @safe) to be default @safe.
>>
>> The reason is simple -- the change is silent and automatically marks everything @safe that has not been checked.
>>
>> I would argue that if the compiler is going to make things @safe by default, then things that are not marked and are not @safe should not compile AT ALL COSTS. Otherwise the value of @safe is completely lost.
>>
>> The DIP should be rejected IMO unless all functions with no mechanism to
>> mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have
>> no implementation are either:
>>
>> a) required to be marked, or
>> b) default @system.
>>
>> Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.
>>
>> I will note that I support the notion of @safe by default. I would be in favor of the DIP as long as this fatal flaw is not included.
>>
>> -Steve
>>
>
> I'm really on board with this. My feeling though is that it should be b;
> extern(Language) should be @system by default, except maybe extern(Rust),
> which nobody has ever asked for.
>

There's also the matter that with this DIP we REALLY need @trusted expressions or scopes. It's inappropriate that you need to tag an entire function when you just want to make one unsafe call and the few lines of surrounding context assert any safety requirements.

I also think that the names make little sense in a @safe-by-default world, and really there should only be @unsafe. It's not necessary to have @system AND @trusted.

On Thursday, March 26, 2020 12:49:25 AM MDT Kagamin via Digitalmars-d wrote:
> On Thursday, 26 March 2020 at 05:43:41 UTC, Walter Bright wrote:
> > https://github.com/dlang/druntime/blob/master/src/core/stdc/limits.d#L29
> >
> > declares everything as @trusted, yet should be @safe. It isn't technically broken, but it isn't right.
>
> That one should be @system, like any other C header. @safe is supposed to be checked by the compiler, so C headers can't possibly have @safe declarations.

Really, the issue with that particular module is that it contains no function declarations whatsoever, making any kind of @safety attribute utterly pointless. Either way, I agree that @safe makes no sense for extern(C) declarations of any kind. @trusted can make sense but not @safe. Unfortunately though, it _is_ currently legal to mark non-extern(D) function declarations with @safe even though the compiler isn't verifying anything.

- Jonathan M Davis

On 3/25/2020 11:04 AM, Steven Schveighoffer wrote:
> This is overblown. Adding @system: at the top of a c library header is not hard.

https://github.com/dlang/druntime/pull/3008/files

On 3/26/2020 12:29 AM, Manu wrote:
> There's also the matter that with this DIP we REALLY need @trusted expressions 

() @trusted { expression; } ();

Yes, it's a bit inconvenient, and it's supposed to be inconvenient. Making it too convenient means it'll get used far too often.


> I also think that the names make little sense in a @safe-by-default world, and really there should only be @unsafe.

Please, no bikeshedding about the name. We considered @unsafe originally, but decided on @system because "unsafe" implies unsafe but that isn't what it means in this context, it means "not machine verified to be safe". "system" has the right connotations.

We're not changing it. We've got far, far more important things to do than argue about the name.


> It's not necessary to have @system AND @trusted.

@safe code isn't supposed to call @system functions directly, because they have an unsafe interface.

On 3/25/2020 11:43 PM, Jonathan Marler wrote:
> NOTE: I rebased it so I could use druntime/phobos off of master so I wouldn't have to cross-reference which versions of those repos to use to get everything working

I rebased the PR. It was getting a bit stale anyway :-/

On Wednesday, 25 March 2020 at 21:58:40 UTC, Jonathan Marler wrote:
> Has the benefit warranted the cost to manage these tags throughout your code?

Yes. Especially since the cost is trivial.

> Do we have any projects that are already using this behavior by putting "@safe:" at the top of every file?  Does anyone have any pointers to projects that have done this?

All my projects that aren't called reggae. The only reason for that exception is that it's ancient and I didn't know any better then.

I don't know how we've managed, but we've utterly failed at marketing @safe to the community. Writing @safe code is easy unless you're doing manual memory management or trying to abstract it with a library. *Especially* with DIP1000.

On Thursday, 26 March 2020 at 05:14:44 UTC, Jonathan M Davis wrote:
>
> Making it so that all code must be either verified by the compiler to be @safe or be marked by the programmer to be @trusted or @system means that all code which could contain memory safety issues will be segregated by @trusted or system, whereas right now, you can have large swathes of code which is not marked with anything and is unchecked. If the programmer is not using the compiler to verify @safety and is not verifying @system sections of code and marking it as @trusted, then there are no compiler guarantees about memory safety in that code. Sure, the programmer may have done a good enough job that there are no memory safety bugs in the code (and that's far more likely with D code than C/C++ code), but by making @safe the default, it makes it so that none of that will fall through the cracks unless the programmer explicitly tells the compiler to not check.

FFI functions like extern(C) must be @system as the compiler cannot check this. Should extern(C) automatically mean @system? Well I think so because that's the only feasible possibility.

I think we are heading into the @safe, @trusted, @system discussion and that's where I think the problem really lies, that @trusted just messes things up. If @safe code can call @system code directly then we are good and we can us extern(C) just as before (with or without @system block, another discussion) If we have this strange "human verified" @trusted nomenclature then things starts because fuzzy. What is an FFI function, trusted or system?

I think that @trusted must go, then things start to clear up.

On Thursday, 26 March 2020 at 11:40:41 UTC, IGotD- wrote:
> On Thursday, 26 March 2020 at 05:14:44 UTC, Jonathan M Davis wrote:
>>
>> Making it so that all code must be either verified by the compiler to be @safe or be marked by the programmer to be @trusted or @system means that all code which could contain memory safety issues will be segregated by @trusted or system, whereas right now, you can have large swathes of code which is not marked with anything and is unchecked. If the programmer is not using the compiler to verify @safety and is not verifying @system sections of code and marking it as @trusted, then there are no compiler guarantees about memory safety in that code. Sure, the programmer may have done a good enough job that there are no memory safety bugs in the code (and that's far more likely with D code than C/C++ code), but by making @safe the default, it makes it so that none of that will fall through the cracks unless the programmer explicitly tells the compiler to not check.
>
> FFI functions like extern(C) must be @system as the compiler cannot check this. Should extern(C) automatically mean @system? Well I think so because that's the only feasible possibility.
>
> I think we are heading into the @safe, @trusted, @system discussion and that's where I think the problem really lies, that @trusted just messes things up. If @safe code can call @system code directly then we are good and we can us extern(C) just as before (with or without @system block, another discussion) If we have this strange "human verified" @trusted nomenclature then things starts because fuzzy. What is an FFI function, trusted or system?
>
> I think that @trusted must go, then things start to clear up.

Safe code is about preventing memory corruptions:

 - external c library can have bugs, and corrupt memory
 - the kernel can have bugs, and corrupt memory
 - the CPU can have bugs, or designs that lead to memory dumping

At least, D has a tool, the trusted/safe attribute that simply says:

"hey folks, I can't mechanically or manually check you code, as I don't have the sources, but, function A API description assurers me that can't corrupt memory, so I mark its declaration trusted, while function B can corrupt memory if I use the wrong parameters, so I mark it system, and I will provide a trusted D wrapper that will assure that the correct parameters are used"

At least, that's how I read the whole things.

Coming back to the discussion, 'not D' externs should be system by default.

On Thursday, 26 March 2020 at 11:55:32 UTC, Paolo Invernizzi wrote:
>
> At least, D has a tool, the trusted/safe attribute that simply says:
>
> "hey folks, I can't mechanically or manually check you code, as I don't have the sources, but, function A API description assurers me that can't corrupt memory, so I mark its declaration trusted, while function B can corrupt memory if I use the wrong parameters, so I mark it system, and I will provide a trusted D wrapper that will assure that the correct parameters are used"
>
> At least, that's how I read the whole things.
>
> Coming back to the discussion, 'not D' externs should be system by default.

Another problem is that @safe is "viral", if some function is @system then the whole function chain must be @system. @trusted was meant to bridge this gap and as I think that @trusted is an oxymoron, I think that we need @system blocks in order to allow a @system escape hatch in @safe code.

Apart from my worries that @safe by default will break more code than we think. The whole @safe, @trusted, @system patchwork needs an overhaul as well in order for @safe by default should be usable and convenient to work with.

The roadmap for @safe as default, I think should be.
1. Remove @trusted.
2. Implement @system blocks.
3. Then we can set @safe as default.

Right now in order for @safe to be usable, we more or less have to introduce a new keyword "AllowSystemInSafeCode:", otherwise code that use FFIs cannot use @safe at all. Alternatively we just make everything @system but that defeats the purpose of @safe as default.

On Thursday, 26 March 2020 at 12:18:05 UTC, IGotD- wrote:
> On Thursday, 26 March 2020 at 11:55:32 UTC, Paolo Invernizzi wrote:
>>
>> At least, D has a tool, the trusted/safe attribute that simply says:
>>
>> "hey folks, I can't mechanically or manually check you code, as I don't have the sources, but, function A API description assurers me that can't corrupt memory, so I mark its declaration trusted, while function B can corrupt memory if I use the wrong parameters, so I mark it system, and I will provide a trusted D wrapper that will assure that the correct parameters are used"
>>
>> At least, that's how I read the whole things.
>>
>> Coming back to the discussion, 'not D' externs should be system by default.
>

<snip>

>  The whole @safe, @trusted, @system patchwork needs an overhaul as well in order for @safe by default should be usable and convenient to work with.

I respectfully disagree: I'm pretty happy with the status quo.

I would leave out of the discussion 'convenient', as anyone has its habits, but definitely the current situation is 'usable'.