Simplification of @trusted

[Bruce Carneal]

On Wednesday, 16 June 2021 at 22:10:38 UTC, max haughton wrote:
> On Wednesday, 16 June 2021 at 22:02:18 UTC, Bruce Carneal wrote:
>> On Wednesday, 16 June 2021 at 21:47:55 UTC, jmh530 wrote:
>>> On Wednesday, 16 June 2021 at 21:22:32 UTC, Walter Bright 
>>> wrote:
>>>> [snip]
>>>>> [...]
>>>>
>>>> The idea is to encourage programmers to think about 
>>>> organizing code so that there are clear separations between 
>>>> safe and system code. Interleaving the two on a line-by-line 
>>>> basis defeats the purpose.
>>>
>>> This is a better argument against @trusted blocks within 
>>> @safe blocks than it is against @system blocks within 
>>> @trusted code.
>>
>> I'd love to see those gone as well but it could be hard to get 
>> there from here.
>>
>> It's easier to validate simply nested rather than finely 
>> interwoven dependencies.
>>
>> I hope we can start reversing course rather than moving 
>> further down the "convenience over practical safety" path.
>
> Where do you make the distinction between convenience and 
> practicality in this context?

"practical safety" was meant to signify "machine checked safety", 
as in "if humans are actively involved it is likely not safe".  
Should have been more specific.

Addressing what I believe you're asking, around my confusing 
formulation, I dont think that we have to choose between ease of 
use and safety in this case.  If we move to @safe checking by 
default within @trusted code we get additional safety with more 
localized (easier) manual checking.

I think the opt-in scheme I proposed (@system blocks trigger 
@safe checking) would be backward compatible and also 
readable/maintainable going forward.