Could assertThrown be made safe/trusted?

Jonathan M Davis jmdavisProg at
Tue Jan 17 14:31:32 PST 2012

On Tuesday, January 17, 2012 14:14:36 H. S. Teoh wrote:
> On Tue, Jan 17, 2012 at 05:04:18PM -0500, Jonathan M Davis wrote:
> [...]
> > Attribute inferrence is a big step forward in making as much as
> > possible @safe and pure, but there's still plenty to do there.
> [...]
> Funny you should mention that, I was just starting to wonder if I should
> start littering my code with 'pure', and whether it's possible to make
> the compiler infer it for me. From the little that I know, it seems that
> in most cases 'pure' can be automatically inferred. The compiler already
> distinguishes between weakly pure and strongly pure internally, so why
> not take it all the way? Not sure how this will affect inter-module
> analysis, though.
> But since this is apparently not yet implemented, just what *is*
> implemented currently when you specify 'pure'? Common subexpression
> factorization? Hoisting? Not (yet) memoization, apparently.

_pure_ is implemented. It's @safe that isn't fully implemented. pure, @safe, 
and nothrow are inferred for templated functions when they're instantiated so 
that they can be pure (or @safe or nothrow) based on the code that's generated 
rather than always forcing it to be one or the other, since that would be far 
too restrictive. But that's completely unnecessary for normal functions. You 
_do_ need to mark those pure, @safe, or nothrow yourself.

If attributes were inferred for normal functions, the compiler would always 
have to have the full source of every function. And even then, it might be an 
instance of the halting problem. Every function is and must be pure (or @safe 
or nothrow) or not when it's declared, and that's part of its signature, so it 
can be known even when the full source isn't. Inference works with templates 
only because they're generating code, and the compiler needs their full source 

- Jonathan M Davis

More information about the Digitalmars-d-learn mailing list