On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:

> When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign and make the whole client code `@system`.

I really don't understand, there's no "maybe" memory safety: if there's no time to spend for memory safety in a project, why care?

> Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. And reading this theard, it would seem like most of you would agree.

I disagree: if you *really* want to use @safe in the rest of the codebase, just mark the binding as trusted, raising your hand towards reviewers (or everybody is interested in checking the memory safety of the project codebase), writing in the comment that "you" have decided to spend no time in a proper wrapping, and the motivations.

Let the reviewers and the other guys out there just decide what to do with your codebase.

> But when I think it, what I have accomplised from avoiding that antipattern? The only difference is, that if my D code does something `@system`, it'll remain under the radar. So I'm worse off than had I submitted to the antipattern!

It's not an anti pattern, it clearly show your motivation, that's all about @trusted. May also write a big *disclaimer* in the README pointing to the pitfalls

On 5/23/20 6:55 AM, Dukc wrote:
> The more I think of Atila's and Walter's responses, the more they are starting to make sense.
> 
> When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign and make the whole client code `@system`. Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. And reading this theard, it would seem like most of you would agree.

This is fine, the code *is* @system. There's nothing wrong with @system code in D.

What is wrong is blanket assumption of @safety. In this case, people who actually care about memory safety want to be sure that @safe functions are actually @safe. If you lie about that, then the whole system breaks down. @safe just becomes a convention, and really everything just has to be manually checked.

> 
> But when I think it, what I have accomplised from avoiding that antipattern? The only difference is, that if my D code does something `@system`, it'll remain under the radar. So I'm worse off than had I submitted to the antipattern!

I understand what you are saying, you want the @safety checking in your code, but do not want to deal with the hassle of making special wrappers.

And let's be honest here, if you are OK with it, putting @trusted: at the top of your extern(C) functions is fine with me. At least that's not a lie.

What is not fine is having the compiler do it for you so nary a @trusted marking is in sight. I don't really understand the draw of that.

-Steve

On 5/22/20 8:05 PM, Walter Bright wrote:
> On 5/22/2020 10:54 AM, Atila Neves wrote:
>>> BTW, you should fix that invalid attribute, freeing a pointer is never @safe unless you can guarantee nobody else has a copy of that pointer (and considering it's passed by value, the CALLER still has that pointer!)
>>
>> You're completely right.
> 
> @live is intended to fix that!
> 
> To get ahead of the curve, annotate pointer parameters with `scope` if you don't intend to transfer ownership to the callee. Better yet, use `ref` instead of pointer parameters where possible.

These are extern(C) functions written in C. How does one apply @live to that? You can't change it to ref in the prototype.

Besides, a deallocation function shouldn't use @live, it's about to destroy the pointer.

-Steve

On Saturday, 23 May 2020 at 12:13:45 UTC, Steven Schveighoffer wrote:
>
> What is not fine is having the compiler do it for you so nary a @trusted marking is in sight. I don't really understand the draw of that.
>
> -Steve

I think not only about how @safe mechanically verifiable is an advantage, but also @trusted blocks are very greppable so it's easy to find "danger zones" in any project.

I briefly skimmed through the discussion and I don't really see the issue with @trusted blocks other than the slightly awkward syntax. Yes, it's additional effort, but it should be an additional effort, so that people try to avoid unsafe code.

In languages like Rust and C# people are used to using unsafe blocks whenever interacting with C code, or people build safe wrappers over unsafe APIs, which is exactly what would be expected in D after these changes.

On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote:
> [..]
> Yes, there's a cost, which is carefully vetting extern(C) and extern(C++) declarations. The decision came down to finding this an acceptable trade-off.

How would you feel about a DIP that the only thing it did was make all non-extern (D) code implicitly @trusted? And how about if all such code suddenly became @safe without any vetting by developers and not even a compiler switch to revert to the old behavior?
Until DIP1028, putting @trusted: at the start of a module has always been considered bad practice and rightfully forbidden in libraries with a higher quality bar, such as phobos. But at least doing so is honest: you as an author are admitting that you don't have time to take care of @safe-ty for now, but it is likely ok to assume that the rest of your project is safe (well at least the @safe functions) *modulo* the @trusted parts. That way, later you can come back and search for @trusted and address those issues one by one.

As evidenced by the community outrage, no one but Walter and (maybe) you are convinced that safe-by-default on function bodies should imply @safe on non-extern(D) function declarations.

---

So how about a compromise?
1. We accept a modified version of DIP1028 in which safe-by-default applies only to function definitions and extern(D) function declarations.
2. We add a separate compiler switch that changes non-extern (D) function declarations to be @trusted.
If you enable 1. and 2. you get the current version of DIP1028, but at least corrected, so that extern(C) code @trusted, and not @safe.
If you like this "feature" (2.) you're free to use it on your personal projects, but please don't force it on everyone who wants @safe to be something meaningful.

On 5/21/20 7:49 PM, 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:
>>> Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options.
>>
>> 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?

A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead.

A committee would work if the community were at least one order of magnitude larger. It's just big numbers. Walter is world-class, another way of saying there's only a few of comparable strength in the world. A larger community would mean a larger likelihood of there being other people of comparable strength in it. Those could form a committee. As things are, Walter is so much stronger than every one of us, the relationship is highly asymmetric. His strength comes with equally unique ability to explain and debate, which makes many of the discussions in forums very frustrating.

On Sat, May 23, 2020 at 10:55:40AM +0000, Dukc via Digitalmars-d-announce wrote: [...]
> When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign and make the whole client code `@system`. Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. And reading this theard, it would seem like most of you would agree.
> 
> But when I think it, what I have accomplised from avoiding that antipattern?  The only difference is, that if my D code does something `@system`, it'll remain under the radar. So I'm worse off than had I submitted to the antipattern!
[...]

And this is precisely why I proposed that what we need is a way for the compiler to mechanically check all code *except* certain specified blackboxes that are skipped over.  Then you can have your calls to unvetted C functions and still have the mechanical checks enabled for the rest of your code.

This is also related to @trusted blocks inside a function, the intention of which is to limit the @system code to as small a surface area as possible while enabling @safe checks for the rest of the function.


T

-- 
Gone Chopin. Bach in a minuet.

On Saturday, 23 May 2020 at 15:33:05 UTC, H. S. Teoh wrote:
> On Sat, May 23, 2020 at 10:55:40AM +0000
>
> And this is precisely why I proposed that what we need is a way for the compiler to mechanically check all code *except* certain specified blackboxes that are skipped over.  Then you can have your calls to unvetted C functions and still have the mechanical checks enabled for the rest of your code.
>
> This is also related to @trusted blocks inside a function, the intention of which is to limit the @system code to as small a surface area as possible while enabling @safe checks for the rest of the function.
>
>
> T

@system void foo(...) {
    () @safe {
        // mechanically checked
    }();
    // not checked
}

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> I have made these points before, but I'll summarize them here
> for convenient referral.
> [..]

Thank you for the detailed and insightful explanation.
Would it be feasible to have a follow-up DIP that enables implicit @system extern as an opt-in (e.g. -nosafeextern). The frustration most people seem to have with @safe extern is that it lessens the promise of @safe without a recourse.

On 23/5/20 20:40, Johannes T wrote:
> On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
>> I have made these points before, but I'll summarize them here
>> for convenient referral.
>> [..]
> 
> Thank you for the detailed and insightful explanation.
> Would it be feasible to have a follow-up DIP that enables implicit @system extern as an opt-in (e.g. -nosafeextern). The frustration most people seem to have with @safe extern is that it lessens the promise of @safe without a recourse.

Also there will need to be an answer to this probably inthe future not unusual question:

My code is 100% @safe, there's no @trusted block anywhere, why am I getting memory corruption?

To me the expectation / promise was that @safe code was safe from memory corruption modulo bugs in the implementation.

The only source for issues would be then @trusted code that could be audited as needed.

You could say "well, you always had to check for those", but the difference is that until now the compiler would shout at me if I didn't, so I wouldn't forget about them.

Now it has to be clearly explained that you should check for @trusted code AND unmarked external C functions.