Simplification of @trusted

[GrimMaple]

On Wednesday, 16 June 2021 at 15:58:23 UTC, RazvanN wrote:
> On Wednesday, 16 June 2021 at 14:57:19 UTC, GrimMaple wrote:
>
>> What I like more, is permitting to temporarily increase the 
>> safety level by using eg @safe blocks inside a @trusted 
>> function. For example
>>
>> ```d
>> void foo() @trusted
>> {
>>     int[100] a = void;
>>     @safe
>>     {
>>         // Code with safety checks
>>     }
>> }
>> ```
>>
>
> I don't think that this is a good alternative. The normalcy we 
> are striving for is to have as much code as possible @safe and 
> as little as possible trusted. From that perspective it makes 
> much more sense to annotate the entire function as @safe and 
> have minor sections as being trusted.
>
With my approach, you can still cover as many code @safe as you 
want without lying to the end user about the function safety. 
IMHO, if you perform @trusted operations in a @safe function, the 
function cannot be called @safe .

>> Overall, if something like this is implemented, it should 
>> support all safety levels for blocks, including @safe and 
>> @system, for consistency purposes
>
> I don't really see the point in having @safe/trusted blocks 
> inside of @system functions or @system/trusted blocks inside 
> @safe functions. As for trusted functions, although I like the 
> idea of deprecating them, there are cases of functions that are 
> a few lines of code long (or even one liners) that do some 
> unsafe operations that can be trusted; in this situation it's 
> much easier to annotate the function as trusted. However, 
> outside of such scenarios (for big functions), annotating 
> functions as trusted is bad practice.

The point is enabling @safe checks on parts of @system/@trusted 
code, that otherwise would require weird solutions. Or, if you 
prefer, to be consistent over the lang. I think it is more 
predictable to the user, that if you can mark a block @trusted, 
it can be marked @safe or @system as well