On Friday, 17 January 2020 at 08:10:48 UTC, Johannes Pfau wrote:

> I'm curious, what do you think would be the ideal scheme if we could redesign it from scratch? Only @safe/@system as function attributes and @trusted (or @system) blocks which can be used in @safe functions?

Yes, pretty much the same as in Rust.
And we can get there: just need to introduce @trusted blocks (which would not a change what is already possible but only a simplification of syntax) and changing all @trusted functions to @safe (with one big @trusted block around the function body).

These are pretty small changes, but would yield a much better structure.

On Friday, 17 January 2020 at 09:21:30 UTC, Dominikus Dittes Scherkl wrote:
> On Friday, 17 January 2020 at 08:10:48 UTC, Johannes Pfau wrote:
>
>> I'm curious, what do you think would be the ideal scheme if we could redesign it from scratch? Only @safe/@system as function attributes and @trusted (or @system) blocks which can be used in @safe functions?
>
> Yes, pretty much the same as in Rust.
> And we can get there: just need to introduce @trusted blocks (which would not a change what is already possible but only a simplification of syntax) and changing all @trusted functions to @safe (with one big @trusted block around the function body).
>
> These are pretty small changes, but would yield a much better structure.

And by the way: I would not call the blocks @system, they should be distinguishable from @system functions to make them better searchable!

I still think the @trusted blocks should be rare and small and only necessary at the lowest level deep within libraries.

On 1/17/20 4:39 AM, Dominikus Dittes Scherkl wrote:
> On Friday, 17 January 2020 at 09:21:30 UTC, Dominikus Dittes Scherkl wrote:
>> On Friday, 17 January 2020 at 08:10:48 UTC, Johannes Pfau wrote:
>>
>>> I'm curious, what do you think would be the ideal scheme if we could redesign it from scratch? Only @safe/@system as function attributes and @trusted (or @system) blocks which can be used in @safe functions?
>>
>> Yes, pretty much the same as in Rust.
>> And we can get there: just need to introduce @trusted blocks (which would not a change what is already possible but only a simplification of syntax) and changing all @trusted functions to @safe (with one big @trusted block around the function body).
>>
>> These are pretty small changes, but would yield a much better structure.
> 
> And by the way: I would not call the blocks @system, they should be distinguishable from @system functions to make them better searchable!
> 
> I still think the @trusted blocks should be rare and small and only necessary at the lowest level deep within libraries.

@system blocks would only live inside @trusted functions. So you can search for @trusted, and then look for the system blocks to see which parts need attention.

-Steve

On Friday, 17 January 2020 at 09:21:30 UTC, Dominikus Dittes Scherkl wrote:
> [snip]
>
> Yes, pretty much the same as in Rust.

Somewhat OT, but HN is blowing up with an article [1] about the Rust community complaining unsafe being overused, resulting in the maintainer of the HTTP framework quitting.

[1] https://words.steveklabnik.com/a-sad-day-for-rust

On 1/17/20 11:33 AM, jmh530 wrote:
> On Friday, 17 January 2020 at 09:21:30 UTC, Dominikus Dittes Scherkl wrote:
>> [snip]
>>
>> Yes, pretty much the same as in Rust.
> 
> Somewhat OT, but HN is blowing up with an article [1] about the Rust community complaining unsafe being overused, resulting in the maintainer of the HTTP framework quitting.
> 
> [1] https://words.steveklabnik.com/a-sad-day-for-rust

Well, those people for sure won't be running to D any time soon.

We have had our share of quitters as well. It happens, people get very emotional sometimes. It's good to remember that the Internet is not a nice place, it's good to have somewhat of a thick skin for that kind of stuff.

-Steve

On Friday, 17 January 2020 at 16:57:04 UTC, Steven Schveighoffer wrote:
> [snip]
>
> Well, those people for sure won't be running to D any time soon.
>
> We have had our share of quitters as well. It happens, people get very emotional sometimes. It's good to remember that the Internet is not a nice place, it's good to have somewhat of a thick skin for that kind of stuff.
>
> -Steve

I don't disagree with your sentiments. My interest in the piece was also that Rust doesn't have the trusted/system dichotomy. The problem the community had with the code was that there were unsafe blocks all over the place, which made it difficult to verify if it was safe or not. I think that ties in with some of the discussion here.

On Friday, 17 January 2020 at 16:33:14 UTC, jmh530 wrote:
> On Friday, 17 January 2020 at 09:21:30 UTC, Dominikus Dittes Scherkl wrote:
>> [snip]
>>
>> Yes, pretty much the same as in Rust.
>
> Somewhat OT, but HN is blowing up with an article [1] about the Rust community complaining unsafe being overused, resulting in the maintainer of the HTTP framework quitting.
>
> [1] https://words.steveklabnik.com/a-sad-day-for-rust

I think this is pretty funny and also predictable. There is an overuse of unsafe in Rust because the programmers want/must escape their Gulag in order to do the things they want, it's human behaviour. I have for long predicted that Rust is not the way forward for programming languages even if the language have some good things and now they are trying to escape from it. BTW, here is another proof of that, the blog "Learning Rust the dangerous way", http://cliffle.com/p/dangerust/. Which was appreciated by many users and beginners.

This is one of the reasons I'm a bit skeptical against DIP 1028, https://forum.dlang.org/thread/ejaxvwklkyfnksjkldux@forum.dlang.org. That people will not value it that much. I have nothing against a safe subset, but I'm not sure making it default is the right way to go.

A bit OT, but there will be another round of that DIP at least.

On 17.01.20 18:16, jmh530 wrote:
> My interest in the piece was also that Rust doesn't have the trusted/system dichotomy.

They really do, and the fact that many people do not understand this is a pretty solid argument against Rust's `unsafe` keyword. In Rust, the `unsafe` keyword is overloaded to have dual meanings. Functions with `unsafe` blocks are trusted functions. Functions annotated `unsafe` are system functions.

On 17.01.20 09:10, Johannes Pfau wrote:
> Am Thu, 16 Jan 2020 04:34:26 +0100 schrieb Timon Gehr:
> ...
> I'm curious, what do you think would be the ideal scheme if we could
> redesign it from scratch?

Different approaches have different trade-offs and I am not sure how to weight the benefits and drawbacks. However, whatever the final solution is, the type system should not make a difference between @safe and @trusted function signatures.

> Only @safe/@system as function attributes and
> @trusted (or @system) blocks which can be used in @safe functions?

I do not particularly like this option. @trusted blocks are better than @system blocks, but an implicit assumption many people are still going to make is that only the code inside the block is @trusted, and this will typically be incorrect.

On Friday, 17 January 2020 at 18:12:21 UTC, Timon Gehr wrote:
> [snip]
>
> They really do, and the fact that many people do not understand this is a pretty solid argument against Rust's `unsafe` keyword. In Rust, the `unsafe` keyword is overloaded to have dual meanings. Functions with `unsafe` blocks are trusted functions. Functions annotated `unsafe` are system functions.

Ah, that is correct. I had not even realized it.

Some of the discussion on this thread and some others recently who are skeptical of @trusted would thus find this useful. Rust has the equivalent of @system and @system blocks, but no equivalent keyword to express @trusted. At the same time, they are also having problems with people marking too much code as their equivalent of @system, contributing to problems in their community. This would suggest removing @trusted should have a very high bar.