www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Could assertThrown be made safe/trusted?

reply simendsjo <simendsjo gmail.com> writes:
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.
Jan 17 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 17 2012
parent reply simendsjo <simendsjo gmail.com> writes:
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.
Jan 17 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 17 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 17 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 17 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 17 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 17 2012
parent bearophile <bearophileHUGS lycos.com> writes:
H. S. Teoh:


 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.


Common subexpression factorization for strongly pure functions that return
integral values.

Bye,
bearophile
Jan 18 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 17 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 17 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, January 17, 2012 23:40:35 Timon Gehr wrote:

 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.


I have no idea what currently gets optimized by the compiler with regards to 
pure except for the fact that the function must be strongly pure and that 
optimizations only ever occur in a single statement (maybe even only in a 
single expression). That's a compiler implementation issue that I don't 
generally worry about. I'd _like_ it to optimize a lot, but that could easily 
vary as the implementation changes even after the language has been fully 
implemented.

Now, if you want to test it, aside from looking at the assembly generated by 
the compiler, you could use debug{} blocks with print statements in them, 
since you can put impure code in debug{} blocks for debugging purposes. So, 
with something like

auto pureFunc(immutable Type arg)
{
 debug { writefln("%s(%s): pureFunc called", __FILE__, __LINE__); }
 //... code
}

it becomes easy to see how well optimized out a pure functions' calls are.

- Jonathan M Davis
Jan 17 2012