On 3/25/20 11:36 PM, bachmeier wrote:
> On Wednesday, 25 March 2020 at 18:04:33 UTC, Steven Schveighoffer wrote:
>> On 3/25/20 1:34 PM, bachmeier wrote:
>>> On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
>>>
>>>> Everything else in the DIP is possibly annoying to deal with but at least doesn't silently destroy the meaning of @safe.
>>>
>>> To be perfectly honest, I can't imagine D being a sensible option for someone wanting to work heavily with C code if you have to add pointless annotations and constantly deal with compiler errors. It's not a matter of annoyance, it's simply impractical to add that kind of overhead, particularly if someone else is involved. If you're using C, you're well aware that it's not going to be safe. Rust was designed for *writing* safe code, not for wrapping C libraries, which is maybe the main use of D right now.
>>
>> This is overblown. Adding @system: at the top of a c library header is not hard.
>>
>> Tools which generate headers for C libraries (e.g. dpp) can automatically do the right thing.
>>
> 
> Let me put it differently. Suppose I release a linear algebra library that's a wrapper over a C library. Nobody using D the way it's supposed to be used can use my library. It just doesn't make sense for a language that claims strong C interoperability.

I understand, it is a good point.

To rephrase (to make sure I understand): Today, people open an editor, start a main function, and import your library, and everything works. They don't realize or care that they are using @system code.

If this DIP gets accepted, they open their editor, start a main function, which is now implied safe, and they cannot use their library without marking their main @system. It's an extra step, and one that forces them to think about what they are doing in terms of safety.

So even though nothing has changed exactly (things that were @system are still @system), the status quo for D code changes, which means now your library moves from by-default acceptable, to you need to go into dangerous territory to use this library.

I still think this is the appropriate path. We cannot continue to ignore memory safety as a secondary concern just because C code is by-default unsafe. Memory unsafe HAS to be opt-in for any new modern language to succeed.

I think for sure people need to have guidance as to what makes sense. I think unlike something like Rust, the path to using all @system code is pretty straightforward in D. So yes, it's a burden, but with guidance and the tools we have, it should be a small burden.

And in actuality, most D code is @safe, so for most D code out there, this is not going to be a huge problem. You will have to mark few things. Wrappers/bindings for C libraries are going to be an exception, and that's just the pain we have to deal with. Either use trusted markings to make everything safe (after verification), or just punt to the user.

> Anyway, I'm going to let this die, because nobody else sees it as an issue.

I think it's worth discussing, and I hadn't thought of this perspective, so thanks for clarifying.

-Steve

On Thursday, 26 March 2020 at 14:12:24 UTC, Steven Schveighoffer wrote:
> I still think this is the appropriate path. We cannot continue to ignore memory safety as a secondary concern just because C code is by-default unsafe. Memory unsafe HAS to be opt-in for any new modern language to succeed.

What frustrates me about these discussions is the facts that slices always check bounds by default. The GC prevents use-after-free bugs by default.

C doesn't do those. So assuming C's problems apply to D is fallacious. Rust's complication is because they wanted to avoid the runtime checks. But D's runtime checks are also a valid solution.

I suspect 95+% of C's problems already are extremely rare in D, yet the @safe advocates never seem to consider this at all.

On Thursday, 26 March 2020 at 14:12:24 UTC, Steven Schveighoffer wrote:
> [snip]
> And in actuality, most D code is @safe, so for most D code out there, this is not going to be a huge problem. You will have to mark few things. Wrappers/bindings for C libraries are going to be an exception, and that's just the pain we have to deal with. Either use trusted markings to make everything safe (after verification), or just punt to the user.
>

There is a lot of functionality that depends on C libraries. For instance, every or almost every function in lubeck calls at least one C function. If someone comes to D from python and wants to replace something from numpy/scipy with a lubeck equivalent, they will need to start slapping @trusted or @system on everything. That means they will need to understand the safety system and why stuff like that matters. For some people, that may be a big enough burden that they just throw up their hands and keep using python.

On 3/26/20 10:40 AM, jmh530 wrote:
> On Thursday, 26 March 2020 at 14:12:24 UTC, Steven Schveighoffer wrote:
>> [snip]
>> And in actuality, most D code is @safe, so for most D code out there, this is not going to be a huge problem. You will have to mark few things. Wrappers/bindings for C libraries are going to be an exception, and that's just the pain we have to deal with. Either use trusted markings to make everything safe (after verification), or just punt to the user.
>>
> 
> There is a lot of functionality that depends on C libraries. For instance, every or almost every function in lubeck calls at least one C function. If someone comes to D from python and wants to replace something from numpy/scipy with a lubeck equivalent, they will need to start slapping @trusted or @system on everything. That means they will need to understand the safety system and why stuff like that matters. For some people, that may be a big enough burden that they just throw up their hands and keep using python.
> 

Writing

@system:

At the top of your modules is not a big burden. If that drives you away from the language, then I'm sorry to say that you are missing out on the awesomeness of D, but I can't really help you.

How many people were driven away from windows development because they had to deal with __stdcall? You just googled for it (or whatever the hell was available at the time), said "oh this is how you do it", and did it. It wasn't a problem, you just did it.

This is only even a discussion because of the current situation. If D started out this way, you would have no idea there was even a problem here.

-Steve

On 3/26/20 10:24 AM, Adam D. Ruppe wrote:
> On Thursday, 26 March 2020 at 14:12:24 UTC, Steven Schveighoffer wrote:
>> I still think this is the appropriate path. We cannot continue to ignore memory safety as a secondary concern just because C code is by-default unsafe. Memory unsafe HAS to be opt-in for any new modern language to succeed.
> 
> What frustrates me about these discussions is the facts that slices always check bounds by default. The GC prevents use-after-free bugs by default.

And so any code that uses the defaults will be @safe and continue to compile.

> C doesn't do those. So assuming C's problems apply to D is fallacious. Rust's complication is because they wanted to avoid the runtime checks. But D's runtime checks are also a valid solution.

Unsafe D code can do exactly the same thing that C code does (use pointers and malloc). The runtime checks are gone at that point. How do you distinguish code like that from the good D code?

> I suspect 95+% of C's problems already are extremely rare in D, yet the @safe advocates never seem to consider this at all.

I consider that BECAUSE of these mitigating factors you listed, most D code is already @safe, just not marked that way. Most code that is written will currently "just work".

Unless it doesn't. We are going to have a hard time finding that code or those migration pains without trying it. And it's hard to judge that this will be such a huge burden that we need to reconsider this path. this is why it should be a trial switch, and people should be encouraged to use the switch and report the pains that come from it. We can potentially make things pretty seamless of a transition, or even adjust our thinking to make things more palatable.

I've recently migrated 2 significant projects into fully-safe code. One is diet-ng, which was a couple hours of work. Mostly just consisted of slapping @safe: at the top of modules that had non-templates. This is because most of the code was ALREADY safe. The one major difficulty? Object.opCmp is not safe, even though the implementation in the classes was safe. So I have this awesome shim: https://github.com/rejectedsoftware/diet-ng/blob/e2e947f24faaa71a4bab9dd8bda6f93375c67755/source/diet/parser.d#L31-L36

The other project was mysql-native. I'm still not finished there, but the largest problem is/was Variant. Because of that, I had to create two almost identical APIs and split them into safe/unsafe packages (where eventually the unsafe packages will be deprecated and removed). Thanks to the awesome taggedalgebraic package, and Sönke has been really helpful including features to make it easier to do @safe code, we should be able to have a drop-in replacement for Variant that is @safe, and your code should (almost) just work. You can read about it here (not released yet): https://github.com/schveiguy/mysql-native/blob/safeupdate/SAFE_MIGRATION.md

My point is, putting in the effort to migrate to @safe is the best way to determine where the sticking points are (and there are definitely sticking points). Hand-wavy statistics aren't persuasive.

-Steve

On Thursday, 26 March 2020 at 11:40:41 UTC, IGotD- wrote:
>
> 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.

The problem I see is this:

extern(C) int add1(int i, int j) @safe {
    return i + j + 1;
}

extern(C) doesn't necessarily mean the code is written in C and can't be verified by the compiler. It might just be written in D (or C++, or Rust, or...). I do however understand why one would want to say that an external C library has no @safe interface. But that can be done by applying @system manually. I'm not sure what the best solution is.

On Thursday, 26 March 2020 at 14:24:24 UTC, Adam D. Ruppe wrote:

> What frustrates me about these discussions is the facts that slices always check bounds by default.

As they should.

> C doesn't do those. So assuming C's problems apply to D is fallacious.

C's problems apply to D as soon as you allocate on the C heap or use pointers to stack-allocated memory.

> Rust's complication is because they wanted to avoid the runtime checks.

Rust's complication is because they wanted to avoid a GC, which was marketing genius. It has runtime checks for when access patterns can't be guaranteed at compile-time.

> But D's runtime checks are also a valid solution.

We can do better that at compile time.

> I suspect 95+% of C's problems already are extremely rare in D,

Yes. The remaining 5% are all related to the stack and allocating on the C heap.

> yet the @safe advocates never seem to consider this at all.

I'm not sure what you mean by this. Is it your opinion that writing @safe code is hard and/or restrictive?

If you allocate on the GC heap and use -preview=dip1000, then writing @safe code is writing D code*, *except* when you call non-@safe library code. Unfortunately this is common because @safe isn't the default.

* Pretty much, but not exactly always

On Thursday, 26 March 2020 at 15:14:35 UTC, Steven Schveighoffer wrote:
> My point is, putting in the effort to migrate to @safe is the best way to determine where the sticking points are (and there are definitely sticking points).

we should do a trial release with it all compiled in, with all the associated switches set by default, so it is dead easy to drop in and see what happens.

On Thu, Mar 26, 2020 at 06:59:23AM +0000, Andrej Mitrovic via Digitalmars-d wrote:
> On Thursday, 26 March 2020 at 04:35:23 UTC, Jonathan Marler wrote:
> > I don't know about you but the code I write almost never has bugs.
> 
> I don't usually post around here anymore, but this gave me a good belly laugh. Thanks for that.

+1 :-)


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser

On 26.03.20 17:02, Atila Neves wrote:
> I do however understand why one would want to say that an external C library has no @safe interface. But that can be done by applying @system manually. I'm not sure what the best solution is.

Applying @system manually is fine, as long as the compiler reminds you to do it with an error. Otherwise, the DIP that makes @safe the default will end up weakening @safe.

Today, this rightfully fails compilation:

----
extern (C) void* memcpy(void* dst, const void* src, size_t n);

int main() @safe
{
    auto x = new int;
    auto y = new int(13);
    immutable r = new int(0);
    memcpy(x, y, 100);
    return *r;
}
----

With DIP 1028 in its current state, it passes.

I think that's unacceptable. As far as I see, that's the majority opinion. Hopefully, you and/or Walter can agree and avoid accepting a DIP with a "fatal flaw" (as Steven put it).