www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - trusted delegates all over std.array

reply "TheFlyingFiddle" <kurtyan student.chalmers.se> writes:
Why is std.array litered with  trusted delegates?

Ex:

in the clear method in Appender.

void clear()  safe pure nothrow
{
    if(_data)
    {
       _data.arr = () trusted { return _data.arr.ptr[0 .. 0]; }();
    }
}

Is it to enable  safe? And should it be allowed i mean the code 
does deal with pointers so it really should be made  trusted? Or 
is the reasoning that as much of the standard library should be 
 safe as possible so some small hacks are ok?
Feb 02 2014
parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Sunday, 2 February 2014 at 17:40:47 UTC, TheFlyingFiddle wrote:

 Why is std.array litered with  trusted delegates?


IIRC these were added in the last few releases to make code 
CTFE-able or to allow pure code to call such functions. A lot of 
array/string-processing code wasn't usable from CTFE/pure, this 
was one workaround to the problem.
Feb 02 2014
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 2 February 2014 at 17:47:21 UTC, Andrej Mitrovic wrote:

 On Sunday, 2 February 2014 at 17:40:47 UTC, TheFlyingFiddle 
 wrote:

 Why is std.array litered with  trusted delegates?


 IIRC these were added in the last few releases to make code 
 CTFE-able or to allow pure code to call such functions. A lot 
 of array/string-processing code wasn't usable from CTFE/pure, 
 this was one workaround to the problem.


Pretty sure  trusted only affect the use of  safe and never makes 
CTFE work.

TheFlyingFiddle, the question is about this chunk of code:

     _data.arr = return _data.arr.ptr[0 .. 0];

Does this code run the risk of corrupting memory? The purpose of 
 trusted is to allow code which has been reviewed to be safe to 
be used in  safe code. It can do everything  system code can, but 
should be reserved for code that doesn't rely on the caller to 
provide proper data.

Since the compiler can't validate  system code to be safe, it 
relies on a human to tell it what is safe, this is where  trusted 
comes in.
Feb 02 2014
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/14, Jesse Phillips <Jesse.K.Phillips+D gmail.com> wrote:

 Pretty sure  trusted only affect the use of  safe and never makes
 CTFE work.


This is what I remember, it has a huge diff and has lots of these
trusted lambdas in it:
https://github.com/D-Programming-Language/phobos/pull/1337/files
Feb 02 2014
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 02, 2014 22:46:02 Andrej Mitrovic wrote:

 On 2/2/14, Jesse Phillips <Jesse.K.Phillips+D gmail.com> wrote:

 Pretty sure  trusted only affect the use of  safe and never makes
 CTFE work.


 
 This is what I remember, it has a huge diff and has lots of these
 trusted lambdas in it:
 https://github.com/D-Programming-Language/phobos/pull/1337/files


I think that the fact that the pull is labeled as "potentially  safe & pure 
formatting" doesn't have anything to do with the  trusted lambda stuff that's 
part of it. I believe that the  trusted lambda is a trick that Kenj came up 
with to be able to mark an expression as  trusted rather than being forced to 
mark the whole function as  trusted or create a separate wrapper function to 
be able to mark part of it as  trusted. Rather, he creates a wrapper function 
in place and calls it.

We'd probably be better off figuring out how to add the ability to mark pieces 
of code as  trusted to the language rather than using this trick, since it's a 
bit clunky and probably incurs unnecessary overhead (though maybe Kenji added 
stuff to the compiler to optimize away the overhead of the lambda, or we're 
lucky and it already did). But in the meantime at least, it is a neat trick, 
since it allows us to restrict what code gets marked as  trusted within a 
function.

- Jonathan M Davis
Feb 02 2014