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

[Atila Neves via Digitalmars-d]

I know about the differences between C++ const and D const. I'm 
not talking about head-const, tail-const or logical const.
If I'm not mistaken, the last thing that happened to me was 
storing the captures from a regex into a const variable, then I 
couldn't index it.
I didn't look at the implementation, but it's very weird to me 
that getting an element can't be done on a const object. And yes, 
I'll look into doing a PR for it.

I'm using stdx.data.json a bit now as well, and will have to give 
feedback there. I can't make anything const, it seems.

I wasn't aware of @safe stdio, it always annoyed me that @safe 
functions can't call writeln, that never made any sense to me.

Atila

On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote:
> 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.