Fully transitive const is not necessary

[Sean Kelly]

== Quote from Janice Caron (caron800 at googlemail.com)'s article
> On 01/04/2008, Janice Caron <caron800 at googlemail.com> wrote:
> > However, in the future, you will be able to declare
> >
> >     class X
> >     {
> >         private static int _x;
> >         invariant int x()
> >         {
> >
> >             return _x++; /*ERROR*/
> >        }
> >    }
> >
> >  and suddenly - bingo - the offending line will not compile.
> Well, not exactly. I made a fatal typo in that code, and consequently
> completely screwed it up! So much for forward planning! Let's try
> again. What I meant was:
>        class X
>        {
>            private static int _x;
>            pure int x()
>            {
>                return _x++; /*ERROR*/
>           }
>       }
> and suddenly - bingo - the offending line will not compile.

You know, I'm a huge fan of D, but now we have const, invariant,
and pure, all ostensibly for making it possible for D to act more
like a functional language when functional languages don't need
all this mess to be parallelizable.  Perhaps it's because of the C++
0x post from yesterday, but the above is beginning to give me
flashbacks to C++ in that I'm starting to feel like D is trying to
be the universal solution to all problems, and thereby not an
ideal solution for any problem at all.  One thing D has really had
going for it thus far is conceptual and semantic simplicity, but
I'm starting the feel that the const features are causing that
simplicity to be lost.

Here's the thing: if I want to write heavily concurrent code I'm
not going to use D because imperative languages, D included,
are not structured in a way that inherently lend themselves to
parallelization.  It's certainly possible to write code that could
come close to matching a functional language--use 'pure' and
'invariant' everywhere, forego loops in favor of tail recursion
(which is hopefully optimized by the compiler to avoid stack
issues), etc.  But why mimic a functional programming structure
in an imperative language when I can simply use a functional
language in the first place?  I can only think of one reason:
in a large company it is often more difficult to choose one's
language than to choose one's programming style.  That's it.
But if that's the case then I probably won't be able to use D
anyway--I'll be using C++.

I can truly appreciate the desire to have D scale effectively
as programming becomes more concurrent.  At the same
time, I am beginning to worry that the struggle to achieve
this will end up destroying D's primary selling point (in my
view)--its simplicity.  I know this is all new ground for an
imperative language so there's nothing to do but wait and
see... I just wanted to get this out so I could move on with
my day :-)  Here's to hoping that D doesn't follow in the
way of C++.


Sean