On Wednesday, 25 March 2020 at 19:27:22 UTC, Jonathan M Davis wrote:
> On Wednesday, March 25, 2020 12:04:33 PM MDT Steven Schveighoffer via Digitalmars-d 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.
>
> Not only that, but if _any_ function is automatically marked as @safe when the compiler can't verify that it is, and no programmer has verified that it is and marked it with @trusted, then @safe is borderline pointless and useless, because it's not actually guaranteeing memory safety. We have enough of a problem with programmers incorrectly using @trusted without the compiler doing it. @safe needs to provide actual compiler guarantees, or it just provides a false sense of security. extern(C) functions ultimately exist in the call stack of every D program (even if most of them are buried in D code rather than being used directly by the program), and to have those treated as @system with no verification basically throws @safe's guarantees out the window.
>
> I agree with Walter's assertion that the DIP applies to extern(C) functions unless it says otherwise, but that being the case, the DIP needs to be fixed so that it does not apply to extern(C) functions, or it will do _far_ more damage than good.
>
> - Jonathan M Davis

I agree that safe is almost pointless if it's not on by default.

That being said, in practice I'm not sure how much benefit @safe actually provides. In theory it sounds nice.  It could help audit code, but for me, I audit all my code the same whether or not it's safe.  So for me the whole feature seems kinda pointless. Maybe this is different for others?  Does anyone have any real life examples/experience where @safe has helped?  Has the benefit warranted the cost to manage these tags throughout your code? 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?  Have they seen any benefits from doing so?

On Wed, Mar 25, 2020 at 09:58:40PM +0000, Jonathan Marler via Digitalmars-d wrote: [...]
> That being said, in practice I'm not sure how much benefit @safe actually provides. In theory it sounds nice.  It could help audit code, but for me, I audit all my code the same whether or not it's safe.  So for me the whole feature seems kinda pointless. Maybe this is different for others?  Does anyone have any real life examples/experience where @safe has helped?  Has the benefit warranted the cost to manage these tags throughout your code? 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?  Have they seen any benefits from doing so?

Some of the latest new features like DIP1000 are in full force only inside @safe code.  I've run into a couple of escaping reference bugs that were not caught because I didn't tag my code @safe, but once I added @safe I immediately got a compiler error pinpointing the code that leaked a scoped reference.

I wouldn't say this is a big impact, but it did catch a couple of bugs that would've been a pain to track down.  From this perspective, it makes sense to make @safe the default: most users would not bother with the pain of manually tagging everything @safe just to get a few minor benefits.  But having it by default means everyone reaps the benefits, and where you need an escape to do something seemingly dangerous, you can explicitly use @system or @trusted to temporarily suspend the compiler's checks for specific bits of code.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds

On Wednesday, 25 March 2020 at 22:40:10 UTC, H. S. Teoh wrote:
>
> Some of the latest new features like DIP1000 are in full force only inside @safe code.
> [...snip...]

Oh I didn't know DIP1000 was only enabled in @safe code.  Why is that?

On Wed, Mar 25, 2020 at 11:12:46PM +0000, Jonathan Marler via Digitalmars-d wrote:
> On Wednesday, 25 March 2020 at 22:40:10 UTC, H. S. Teoh wrote:
> > 
> > Some of the latest new features like DIP1000 are in full force only
> > inside @safe code.
> > [...snip...]
> 
> Oh I didn't know DIP1000 was only enabled in @safe code.  Why is that?

I don't know if *all* of DIP1000 only applies in @safe code, I think some of the fixes applies to @system code as well.  But the way I understand it, the idea is that in @system code the programmer is supposed to know what he's doing, and is assumed to be doing something "outside the box" that the compiler does not fully understand, so by default @system code is allowed to do seemingly "dangerous" things. @safe code is for when the programmer is committed to doing only safe operations, so that's where it makes the most sense to enforce these checks.

I think the intention is that most D code will be @safe, and things like DIP1000 will apply to enforce memory safety, and only when you need to "go under the hood" you'd have a @system function as the escape hatch to do the low-level hacks.  The way I read it, this is all part of a general grand plan, which includes this DIP, to move towards having most D code be @safe and only occasionally drop down to @system for operations that cannot be mechanically verified.  Hence, @safe by default.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On 3/25/2020 10:53 AM, Jonathan Marler wrote:
> I'm on the fence as to whether this is a good idea.  However, with all the D code I've written that would break from this I'd prefer not to do this;
Are you sure there'd be that much that breaks? If much does break, I'd suggest re-evaluating the coding techniques you use. How about the bugs in your code that it may find? I'm looking forward to applying this to the D code I've written.

For example, I'm pretty happy with the printf validator added to DMD. I had to fix a lot of my own code, and was glad to get it fixed. I'm happy about every bug that gets fixed the easy way (at compile time).

@safe by default is going to improve your code. As professionals, we should be eager for that.

On 3/25/2020 10:34 AM, bachmeier wrote:
> 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.

As someone who has converted a great deal of C code to D, I was more than satisfied with the results. Very few annotations were needed, and the ones that were improved the self-documenting clarity of the code.

Needing an @system annotation on your code should be rare, and it is certainly not pointless.

> If you're using C, you're well aware that it's not going to be safe.

It's very possible to write safe C code by writing in "D style". Of course, the C compiler won't check that. That's where DasBetterC comes in!

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.
>
> -Steve

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.

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

On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven Schveighoffer wrote:
>
> 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.
>

I realize my depreciation suggestion has some complication in static analysis, but I really think it is required to smooth the transition.

* methods using unsafe language features must have a @system annotation; @trusted might be an option.
* a method must be annotated if it calls an @system method

The first gives first chance to determine if your api is safe.

The second creates the next layer of opportunity to make a safe interface. If you mark it system then the second rule continues to have you evaluate for a safe interface.

This encourages safe interfaces early. While not doing this encourages safe interfaces at the top.

On Wednesday, March 25, 2020 9:36:15 PM MDT bachmeier via Digitalmars-d wrote:
> 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.
>
> Anyway, I'm going to let this die, because nobody else sees it as an issue.

In general, a D wrapper library around a C library should be presenting an @safe API which was verified by the programmer who wrote that wrapper library to be @safe. In some cases, that isn't possible, but regardless of whether @safe and @system is actually a thing, code which can't present an @safe API is a potential memory safety problem. D just makes it possible for the compiler to flag stuff that it knows is not memory safe so that you can easily find it and fix it. And the code that actually needs to do stuff that the compiler can't guarantee is memory safe (and thus requires that the programmer verify it) is then segregated by @trusted code so that you only have to examine a relatively small portion of a library or program for potential memory safety bugs.

D code does make it much easier to integrate with C code than is the case with many other languages, but it also loses a lot of its value if the compiler treats C code as if it were @safe even though its memory safety was not verified by the compiler, and the programmer gave no indication to the compiler that they had verified it. Having the compiler treat C bindings as @safe by default would be a huge whole in @safe and make it much harder to track down bugs related to memory safety when they occur.

- Jonathan M Davis

On Thursday, 26 March 2020 at 02:58:26 UTC, Walter Bright wrote:
> On 3/25/2020 10:53 AM, Jonathan Marler wrote:
>> I'm on the fence as to whether this is a good idea.  However, with all the D code I've written that would break from this I'd prefer not to do this;
> Are you sure there'd be that much that breaks? If much does break, I'd suggest re-evaluating the coding techniques you use.

I'm constantly re-evaluating and improving my coding techniques.  Something I love doing actually.  I'm not sure how this feature breaking code is related to poor coding techniques though?  The point is that to fix code after this feature comes in, I'll need to go through thousands of source files and tag code appropriately.  What does this have to do with the quality of the code itself?

> How about the bugs in your code that it may find? I'm looking forward to applying this to the D code I've written.

If it finds bugs then that's definitely an improvement that could justify the breakage.  I don't know about you but the code I write almost never has bugs.  It can have errors, and it can be unfinished, but almost never bugs. That's from the way I code though.  I use a combination of many techniques that make it very difficult for bugs to get through. If it does find bugs I would be surprised, but I'd love it if it did!

>
> For example, I'm pretty happy with the printf validator added to DMD. I had to fix a lot of my own code, and was glad to get it fixed. I'm happy about every bug that gets fixed the easy way (at compile time).

Yeah this sounds like a good thing to do for printf.

>
> @safe by default is going to improve your code. As professionals, we should be eager for that.

If that's true then I welcome it, but I've got to see it to believe it.  I'd be willing to go through some projects and try this feature out to see if that's the case.  I assume there's a command-line switch to enable it so I could see for myself?