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

[Dmitry Olshansky via Digitalmars-d]

12-Sep-2014 16:43, Atila Neves пишет:
> 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.

My problem with const is that people try to use it as often as logical 
const in C++ (everywhere), it DOESN'T HAVE to be as used as often.

Being binary-wise immutable is harsh requirement on implementation, and 
forbids many techniques (like COW and ref-counting). That's one reason 
we might never have const Captures in std.regex.

>
> 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.
>


-- 
Dmitry Olshansky