On 3/26/2020 10:00 AM, jmh530 wrote:
> I was talking about a hypothetical python person thinking about learning D, not about me personally.

Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.

Rust's marketing department is very good.

On 27/03/2020 10:26 PM, Walter Bright wrote:
> On 3/26/2020 10:00 AM, jmh530 wrote:
>> I was talking about a hypothetical python person thinking about learning D, not about me personally.
> 
> Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.
> 
> Rust's marketing department is very good.

It is a much younger language with people who signed on for this.

Its a bit late to take their approach.

On Friday, 27 March 2020 at 09:07:01 UTC, Walter Bright wrote:
>
> Making @safe the default will substantially reduce this problem for the simple reason that the vast bulk of code should be @safe.

I've been repeating for a while now that this is simply not true.
It was the very point (and last sentence) in my previous message:
> At the moment, all this is doing is ignoring the problem and pushing the complexity from one demographic to the other.

Changing the default makes it "easier" to deal with `@safe` by making it harder to deal with `@system`. How is that an improvement?

> BTW, I have an upcoming DIP that changes the default attributes for delegate parameter types to match the function they appear in.

I already gave it [a lengthy review](https://github.com/dlang/DIPs/pull/170#pullrequestreview-294073723).

On Friday, 27 March 2020 at 09:26:35 UTC, Walter Bright wrote:
> [snip]
>
> Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.

There are use cases for Rust where an increment in memory safety without sacrificing performance is important. However, I rarely hear of anyone doing anything that interests me personally in Rust. I'm more interested in statistics and stuff like that.

>
> Rust's marketing department is very good.

Rust has the support of Mozilla in its marketing.

On Wednesday, 25 March 2020 at 07:02:32 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/DIP1028.md
>
> The review period will end at 11:59 PM ET on April 8, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

I feel like this has gotten lost in the discussion, a comment from ag0aep6g:

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 also do not think allowing that to compile is acceptable. But it was unclear form the DIP if that's allowed or not because it specifically says D functions.

So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required? Is this correct?

On Thursday, 26 March 2020 at 17:02:51 UTC, 12345swordy wrote:
> On Thursday, 26 March 2020 at 16:19:44 UTC, Atila Neves wrote:
>> On Thursday, 26 March 2020 at 14:24:24 UTC, Adam D. Ruppe wrote:
>>> But D's runtime checks are also a valid solution.
>>
>> We can do better that at compile time.
>>
> But not always though. There are scenarios where you have to rely on runtime checks, such as user driven input for example.

Sure.

> Side note: There should be a significant push for runtime reflection if we are pushing for safe by default. I recall Andrei talking about it in one of his presentation on how the compile time reflection will lay ground work for runtime reflection. I have not seen any developments on that front. Reason being that classes can inherent from other classes.

I'm currently working on this.

On Friday, 27 March 2020 at 04:20:47 UTC, Mathias Lang wrote:
> On Thursday, 26 March 2020 at 10:55:44 UTC, Atila Neves wrote:
>> 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.
>
> There's a huge difference between correctly using `@safe` and having things compile.

I think there's a huge difference in using `@trusted` correctly and having things compile.

> And since exceptional claims calls for exceptional proof, I wanted to check whether or not your libraries would be any different. It took me less than 5 minutes to find this: https://github.com/atilaneves/unit-threaded/issues/176

Oops. Thanks for the bug report!

I've been quite bad at using @trusted myself. I think part of the reason that I've been using it wrongly is because @safe isn't the default, and code that *should* be @safe wasn't. The compiler complained and I wrongly applied @trusted somewhere.

It's my belief that I would've screwed up far less if @safe had been the default.

> Take any library that accepts a delegate:

Yes, this is a problem. In my libclang binding (it's on dub) I wanted to write @safe pure code but couldn't since libclang takes a visitor callback. I *could* make the callback declaration @safe and pure, but that's too restrictive for other users.

On 3/27/20 12:20 AM, Mathias Lang wrote:
> I haven't seen a *single* non-trivial library out there that does it correctly.

It's not completely merged, but it's ready for review, if you can find anything here, I'll fix it:

https://github.com/mysql-d/mysql-native/pull/214

I also made diet-ng @safe, and it wasn't hard.

https://github.com/rejectedsoftware/diet-ng

-Steve

On Friday, 27 March 2020 at 09:07:01 UTC, Walter Bright wrote:
> BTW, I have an upcoming DIP that changes the default attributes for delegate parameter types to match the function they appear in.

You'd probably have to make an exception there for @trusted... if a @trusted function takes a @trusted delegate it would get silently ugly.

OR perhaps

@trusted void foo(@trusted void delegate) { }


foo( () { /* do unsafe thing */} ); // fails to compile unless the body infers to @safe, it will never assume a @system literal is trusted

foo( () @trusted { /* do unsafe thing */}); // OK, you specifically said trusted so it works

On Friday, March 27, 2020 9:40:00 AM MDT Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 27 March 2020 at 09:07:01 UTC, Walter Bright wrote:
> > BTW, I have an upcoming DIP that changes the default attributes for delegate parameter types to match the function they appear in.
>
> You'd probably have to make an exception there for @trusted... if a @trusted function takes a @trusted delegate it would get silently ugly.
>
> OR perhaps
>
> @trusted void foo(@trusted void delegate) { }
>
>
> foo( () { /* do unsafe thing */} ); // fails to compile unless
> the body infers to @safe, it will never assume a @system literal
> is trusted
>
> foo( () @trusted { /* do unsafe thing */}); // OK, you
> specifically said trusted so it works

@trusted should never have been part of the name mangling / linkage of D functions. @trusted and @safe need to be treated very differently when compiling functions, and they signal very different things to the programmer, but their difference is an implementation detail. A function calling an @safe or @trusted function doesn't care about the difference, and all it takes is one @safe function in-between, and an @trusted function effectively becomes an @safe one anyway. If @trusted just mangled to the same thing as @safe, then that definitely improves the situation for stuff like delegates (not fix it given the attribute soup that we have, but it would certainly improve it).

I don't know if we can reasonably change how @trusted is treated in name mangling at this point, but I definitely think that it was a mistake to distinguish between @safe and @trusted with name mangling.

- Jonathan M Davis