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