Encapsulating trust

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 2 10:07:35 PDT 2014


"Dmitry Olshansky"  wrote in message news:lu4jld$m0b$1 at digitalmars.com...

> Only these that import stdx.trusted. Trivial to check.

Sure, if this type of function only exists in that module (and there are no 
public imports of it).  But you've still made it so you now have to inspect 
@safe functions for non- at safe code.

> I'd be damned but it's made precisely because taking address is frequently 
> needed in a function that is otherwise @safe. Alternative of marking the 
> whole thing as @trusted ain't going in the right direction.

Of course marking the whole thing as @trusted is wrong.

> Instead of writing the same ugly shit (pardon local functions and 
> lambda+call) everywhere, let just compose a set of markers (2-3 functions) 
> that indicate something as trusted block.

If you're writing a lambda to take the address of a variable, then you're 
using @trusted wrong.  Neither should be done.

> Obviously one can easily abuse it, much like @trusted can be easily abuse 
> today, especially with templates where it's easy to fail in trap of 
> putting @trusted on the whole function and trust pretty much any 3rd party 
> type to be safe.

That's what we have code review for.

> They have in common is lot of noise that distracts and obfuscates the 
> thing that already needs our full attention making it both bigger and 
> harder to follow.

Yes, they are noisy.  But that noise does make them stand out more.

> Careful there - a trusted lambda must ensure that pointer is fine, 
> although the means of getting it are @system. The same review-driven thing 
> about @trusted remains.

A trusted lambda must give the same guarantees any other @safe of @trusted 
function gives - that when called from inside a @safe function it will not 
violate memory safety with any possible arguments.

I'm not saying that you should mark entire functions as @trusted because 
parts of them are not @safe.  You should instead extract the unsafe parts 
into a nested function or lambda (or external function) that provides a 
completely @safe interface.

This way the _only_ code than needs @safeness review is inside functions 
marked as @trusted. 



More information about the Digitalmars-d mailing list