It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const.

Jakob Ovrum via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 12 03:19:25 PDT 2014


On Friday, 12 September 2014 at 09:53:45 UTC, Atila Neves wrote:
> This happens to me all the time. I write a function, stick the 
> aforementioned attributes on as a default then let the compiler 
> tell me when I can't.
>
> That happens a lot more often than I thought it would. Pretty 
> much anytime I call a Phobos function I have to remove at least 
> one of them but usually all three.
>
> Is it similar for everyone else? Is it considered a problem?

Phobos still hasn't been fully annotated since these attributes 
were introduced, but we are making progress. For one, I believe 
we got @safe std.stdio recently, which should be a big boost for 
@safe adoption in general.

It is slowly getting better. Pull requests are welcome.

> The other thing is I frequently have to "unconstify" my 
> variables to get them accepted by Phobos functions as well.

D's const is very different from C++'s const. It's tempting to 
use in the same situations because of superficial similarities, 
but D's const should only be used when immutable is in the 
picture. D simply doesn't have the equivalent of C++'s const 
(which is intentional), despite their similar names.

That said, there are fundamental issues with const and immutable 
that have yet to be resolved - for example, given an immutable 
container or a const reference to a container, it's not possible 
to get a head-mutable range over it for iteration. This is 
different from in-built slices which are conveniently convertible 
from const(T[]) to const(T)[], something that is not expressible 
with user-defined types at the moment.

Further, `inout` does not support considering callback parameters 
to be "out parameters":

struct S
{
     int* p;

     inout(int)* foo() inout { return p; } // OK

     void bar(void delegate(inout int*) dg) inout { // Not 
supported
         dg(p);
     }
}

Both of these issues have been discussed before and IIRC, 
consensus seemed to be that we do want to do something about them.


More information about the Digitalmars-d mailing list