Article about problems & suggestions for D 2.0

[Jonathan M Davis]

On Saturday, August 27, 2011 12:01:21 Mehrdad wrote:
> On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
> > After having used the D 2.0 programming language for a year now and
> > having completed 3 projects with it, I wrote a small article about the
> > problems I had with the D 2.0 programming language and what
> > suggestions I have to improve it.
> > 
> > http://3d.benjamin-thaut.de/?p=18
> > 
> > Comments and criticism welcome
> > 
>  > "This transitiv[it]y basically kills you everywhere."
> 
> I feel like you hit the nail on the head. I feel the same way about const.
> 
> Transitivity is beautiful on the outside, but I can never actually get
> it working, so I just make everything non-const. I have to sometimes do
> this even in Phobos itself, because the compiler complains about
> something random caused by transitivity.
> I also fail to see what /problem/ it's trying to solve. The DigitalMars
> website simply states:
> 
> "With transitivity, there is no way to have a const pointer to mutable int."
> 
> But... so what? Maybe it should actually explain the benefit, since I
> can't figure it out on my own. (The related discussion on "head-const"
> and "tail-const" seems completely irrelevant to the topic."
> 
> C++'s non-transitivity seems to be quite type-safe, even if unintuitive
> to the beginner (which I don't think it is). I *never* ran into issues
> with it.
> 
> 
> *On the bright side*, I LOVE immutable. It's one of the best features of
> D, IMO. (Or at least it would be, if only it /wasn't/ transitive.) I
> don't like the way C++ mixes the idea of "this never mutates" versus
> "YOU can't mutate this object", and I feel like D was really smart in
> making the distinction between the two.

I believe that the fact that we have immutable pretty much forces const to be 
the way that it is in D. const _must_ be more restrictive than it is in C++, 
because it could actually refer to immutable data in D, whereas in C++, you 
_know_ that the data is actually mutable. And so const _must_ guarantee that 
you can't change the data. And to do that, you need transitive const, or you 
don't have enough guarantees that const really is const.

For instance, take this class in C++

class C
{
public:

    C(const vector<int*>& vec) : _vec(vec)
    {}

    vector<int*> getVec() const
    {
        return _vec;
    }

private:
    vector<int*> _vec;
};

If you call getVec, _vec is copied and returned, so _vec can't be altered. 
However, since both _vec and the returned vector contain the exact same 
elements and those elements are pointers, you can alter the data in _vec in 
spite of the fact that you used a const function to get the data. So, you can 
alter the data inside of const C. That just doesn't work when you added 
immutable to the language. You need to be able to guarantee that an immutable 
C isn't going to be altered at all. You need transitive const.

Now regardless of that, head-const and tail-const are still possible on some 
level. There's nothing wrong with having const pointers to non-const, non-
const pointers to const, non-const pointers to non-const, and const pointers 
to const. The problem is complexity. C++'s const syntax is pretty bad when it 
comes to differentiating between head-const and tail-const - hence why parens 
are used in D - so it's not really acceptable. And early in D2's development, 
head-const and tail-const were definitely explored, but ultimately they were 
rejected because of the complexity that they added to the language. There 
wasn't a clean enough way to indicate that something was head-const or tail-
const. Parens do well enough to get you most of the way, but having explicit 
head-const and tail-const was just too messy. Maybe we'll have something 
better in D3, but for D2, we have parens and full transivity for const.

So ultimately, while I understand your frustrations with const, the immutable 
that you love so much pretty much requires const to be the way that it is. 
It's what Andrei refers to as a forced error. One design decision in the 
language forces another. So, while the result is not entirely ideal, we're 
kind of stuck.

- Jonathan M Davis