@system blocks and safer @trusted (ST) functions

Bruce Carneal bcarneal at gmail.com
Mon Jul 26 14:18:29 UTC 2021


On Monday, 26 July 2021 at 13:26:56 UTC, Steven Schveighoffer 
wrote:
> On Sunday, 25 July 2021 at 12:05:10 UTC, Steven Schveighoffer 
> wrote:
>> On Sunday, 25 July 2021 at 06:13:41 UTC, jfondren wrote:
>>> I appreciate that there's a vision also to 
>>> @safe/@trusted/@system, but it doesn't seem to have stuck, 
>>> with Phobos having more than twice as many @trusted lambdas 
>>> than @trusted functions:
>>>
>>> ```
>>> phobos$ grep -rP '\W\(\) @trusted' --include '*.d'|wc -l
>>> 238
>>> phobos$ grep -rP '\w\(\) @trusted' --include '*.d'|wc -l
>>> 111
>>> ```
>>
>> `@trusted` lambdas are required inside templates where you 
>> want code to be `@safe` when the type parameters allow it. The 
>> resulting function itself needs to be marked `@trusted` with 
>> the lambdas replaced with `@system` blocks to achieve the same 
>> effect, as memory safety review is still needed.
>
> One thing that is incredibly important to get right here is the 
> way to specify what to do with templates. I've been thinking 
> about this a bit, and even this isn't the right way to do 
> things (specify the function as `@trusted` and mark the actual 
> trusted part as `@system`), because you want the compiler to 
> infer `@system` for certain instantiations, and `@trusted` for 
> others.

Yes. You have argued, persuasively, that the language should 
infer these properties and others.  IIUC, in a pervasive 
inference scenario, @safe/@trusted/@nogc/... annotations would 
function as programmer assertions: "if this property doesn't 
hold, error out".  Couple this with Ali's @trusted-by-default 
proposal and you'd be living in a wonderful world (he says before 
walking off in to the unknown! :-) ).

>
> What we need is a way to say "this function should be 
> `@trusted` iff certain sections of code are inferred `@safe`".
>
> Perhaps the correct mechanism here is to encapsulate the 
> `@trusted` parts into separate functions, and make sure the API 
> is `@safe` (e.g. static inner functions).
>
> I think it would be too confusing to allow `@system` blocks 
> inside inferred templates.

Definitely more to work out, but I now think that we have an 
opportunity to achieve a much bigger win than that implied by the 
initial proposal.  It feels like there is a simple path forward 
patiently awaiting discovery.




More information about the Digitalmars-d mailing list