At the top of the module:
@safe:

later
unittest {
  assertThrown(...)
}

Ooops. AssertThrown not safe.

Changing the top to:
version(Unittest) {}
else { @safe: }

makes it work, but then I'll need to use that idom in all safe modules as assert*Thrown is handly methods.

On Tuesday, January 17, 2012 15:27:04 simendsjo wrote:
> At the top of the module:
> @safe:
> 
> later
> unittest {
>    assertThrown(...)
> }
> 
> Ooops. AssertThrown not safe.
> 
> Changing the top to:
> version(Unittest) {}
> else { @safe: }
> 
> makes it work, but then I'll need to use that idom in all safe modules as assert*Thrown is handly methods.

Exception itself isn't @safe yet (its constructor in particular), and I don't think that AssertError is either. A number of stuff like that in druntime and Phobos still needs to be marked @safe or @trusted.

- Jonathan M Davis

On Tue, Jan 17, 2012 at 09:07:05AM -0800, Jonathan M Davis wrote: [...]
> Exception itself isn't @safe yet (its constructor in particular), and I don't think that AssertError is either. A number of stuff like that in druntime and Phobos still needs to be marked @safe or @trusted.
[...]

Just out of curiosity, why isn't it marked @safe? I looked over the source and didn't see anything immediately obvious that would preclude @safe.


T

-- 
If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell

On 17.01.2012 18:07, Jonathan M Davis wrote:
> On Tuesday, January 17, 2012 15:27:04 simendsjo wrote:
>> At the top of the module:
>> @safe:
>>
>> later
>> unittest {
>>     assertThrown(...)
>> }
>>
>> Ooops. AssertThrown not safe.
>>
>> Changing the top to:
>> version(Unittest) {}
>> else { @safe: }
>>
>> makes it work, but then I'll need to use that idom in all safe modules
>> as assert*Thrown is handly methods.
>
> Exception itself isn't @safe yet (its constructor in particular), and I don't
> think that AssertError is either. A number of stuff like that in druntime and
> Phobos still needs to be marked @safe or @trusted.
>
> - Jonathan M Davis

So basically @safe is mostly a no-go as of now? Not sure I understand what you mean though.. enforce() can be used in @safe mode.

On 01/17/2012 08:21 PM, H. S. Teoh wrote:
> On Tue, Jan 17, 2012 at 09:07:05AM -0800, Jonathan M Davis wrote:
> [...]
>> Exception itself isn't @safe yet (its constructor in particular), and
>> I don't think that AssertError is either. A number of stuff like that
>> in druntime and Phobos still needs to be marked @safe or @trusted.
> [...]
>
> Just out of curiosity, why isn't it marked @safe? I looked over the
> source and didn't see anything immediately obvious that would preclude
> @safe.
>
>
> T
>

The code for it was presumably written before SafeD was invented.

On Tuesday, January 17, 2012 20:26:48 simendsjo wrote:
> So basically @safe is mostly a no-go as of now? Not sure I understand what you mean though.. enforce() can be used in @safe mode.

Honestly, I suspect that that's a hole in @safe, since Exception's constructor isn't @safe. But I don't know. @safe is not fully implemented, so there are likely to be issues with it. I don't know how much it really works.

- Jonathan M Davis

On Tuesday, January 17, 2012 20:28:52 Timon Gehr wrote:
> On 01/17/2012 08:21 PM, H. S. Teoh wrote:
> > On Tue, Jan 17, 2012 at 09:07:05AM -0800, Jonathan M Davis wrote: [...]
> > 
> >> Exception itself isn't @safe yet (its constructor in particular), and I don't think that AssertError is either. A number of stuff like that in druntime and Phobos still needs to be marked @safe or @trusted.
> > 
> > [...]
> > 
> > Just out of curiosity, why isn't it marked @safe? I looked over the source and didn't see anything immediately obvious that would preclude @safe.
> > 
> > 
> > T
> 
> The code for it was presumably written before SafeD was invented.

That, and not many Phobos developers have been in the habit of using @safe. It isn't fully implemented, and any code in druntime or Phobos which is using it is generally newer. It's a lot like pure in that not all that much has been marked with it historically, making it kind of useless - though pure has generally been used more than @safe. Attribute inferrence is a big step forward in making as much as possible @safe and pure, but there's still plenty to do there.

- Jonathan M Davis

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.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

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 anyway.

- Jonathan M Davis

On 01/17/2012 11:31 PM, Jonathan M Davis wrote:
> 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
> anyway.
>
> - Jonathan M Davis

I think he is interested in the state of implementation of specific compiler _optimisations_ that make use of function purity in order to prove their correctness. IIRC ldc has CSE for pure functions, but I don't know exactly.