May 22
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.
May 22
On 5/22/2020 10:33 AM, rikki cattermole wrote:
> To me at least, this butchers @safe/trusted/system into a system that is near useless for guarantees for an entire program.

It never attempted to guarantee safety in code that was never compiled with a D compiler. It's impossible to do that. No language does that.
May 22
On Fri, May 22, 2020 at 10:50:02PM -0700, Walter Bright via Digitalmars-d-announce wrote:
> On 5/22/2020 10:33 AM, rikki cattermole wrote:
> > To me at least, this butchers @safe/trusted/system into a system that is near useless for guarantees for an entire program.
> 
> It never attempted to guarantee safety in code that was never compiled with a D compiler. It's impossible to do that. No language does that.

And therefore what we need is a way of indicating verifiability up to things outside of our control. E.g., some kind of way to express that the safety of a piece of code is keyed upon some external function or delegate, thus enabling @safe checks for all code except calls into said external function/delegate.

This would work out to be practically where we're at now, except that we don't implicitly pretend external code is @safe where there is no verification at all.


T

-- 
Designer clothes: how to cover less by paying more.
May 23
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:
>
> Am I saying nothing bad can happen if we implicitly trust extern(C) declarations? No. I'm saying we'll be no worse off if they're all implicitly @system.
>
> This compiles with no warnings right *now*:
>
> void main() {
>     import core.stdc.stdlib: free;
>     free(cast(void*) 42);
>     free(new int);
>     free(&main);
> }

And this code won't compile at all when you make `@safe` the default:

```
void main ()
{
    int[] myArray = (cast(int*) malloc(42 * int.sizeof))[0 .. 42];
}
```

So, we changed the default.

Now those people that want to easily prototype something, or write applications that extensively use system libraries, will be extremely inconvenienced, but we satisfied the people that want more `@safe`ty, which we all known and agree is the future.

Except that in that process we also destroyed the meaning of `@safe` by shooting a hole into it, for the convenience of the people that want to easily prototype something and write applications that interact extensively with system libraries, because that's what half of the D users do.

Clearly, an improvement.
May 23
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 assume all non-extern (D) code was implciti @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?

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? We accept a modified version of DIP1028 in which safe-by-default applies only to function definitions and extern(D) function declarations. And then there's a separate compiler switch that changes non-extern (D) function declarations to be @trusted? If you like this "feature" you're free to use it on your personal projects, but please don't force it on everyone who wants @safe to mean anything meaningful.

May 23
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:
> memcpy isn't a good example since it's explicitly @system

Yes, it's a good example. Because if you include any C function, you don't know if it uses memcpy internally - except if you have the code. And as memcpy is used heavily within C libraries, it's not unlikely that your "oh so safe" function is using it too. Very bad advice.

It should be simply forbidden to slap @safe at anything with no code available, because @save should be reserved for mechanically verified parts of code.

Ok, you can slap @trusted on it, and it will compile (the easy way), but anyone using it is at least warned. So it's possible to check - and if no body is availabe (e.g. an object library) I would refrain from trusting it.

But I don't want the compiler to greenwash it for me, no thanks. There should be at least someone on the D side to blame, destroying his reputation by slapping @trusted at whole modules.
May 23
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.

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!

Now, were I designing a library instead of an application, of course I should not pass such client code as `@safe`, regardless of which of those two ways I choose. But I think the correct way would be to mark the API functions as @system. Then it's be best of both cheap tricks: The compiler will verify my D code from mistakes, but I won't pretend that my code is truly `@safe`.
May 23
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
> Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute.

Meant: blindly making the wrappers, without thinking whether calling the wrapper would always be `@safe`


May 23
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
> The more I think of Atila's and Walter's responses, the more they are starting to make sense.
> [snip]

In fact this former antipattern means that it'd make sense to have an inverse of `@trusted` attribute, lets say `@suspect`. It would mean that the body of the function is verified just like `@safe`, but calling it is allowed only within `@system` or `@trusted` code.
May 23
On 2020-05-22 03:16, Walter Bright wrote:

> 
> The level of negativity in that thread was what caused me to stop responding, though I continued reading. Every reply I made produced 10 responses, an exponential explosion, and yet I was just repeating myself. Two sides to every story.
> 
> FWIW, I am going to try again with another post here, for those who want a convenient summary of the rationale.

Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful?

I would definitely listen/watch; even if I were muted and could only chat maybe.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19