Why D const is annoying

[Mehrdad]

Okay, so let's say you're right

    void process1(Student s) { .. }
    void process2(const(Student) s) { ... }

and that what I  guess what I REALLY want is to say, "process1() won't 
change the student's name, birthday, or any other attribute, but process2() 
will".

How do you propose I make that guarantee known to the compiler/caller?
Is that not the entire point of saying "const(Student)" in the first place?




"Chris Cain"  wrote in message news:mivrzrerrqlvskxcndva at forum.dlang.org...

On Wednesday, 2 May 2012 at 03:22:40 UTC, Mehrdad wrote:
> Yes, that's **exactly** why I've said 'const is broken' for at least a 
> year now, but it seemed like people objected to my conclusion...
>
> The trouble, as I just showed, is that it isn't.
> "Lazy-loading" and caching aren't exactly obscure or rarely-used 
> concepts --  which seems to be the way they are portrayed here. They are 
> *bound* to be used in any nontrivial program.
> So, if D doesn't let you use those techniques without 'hacking around' the 
> language, then it doesn't matter how awesome D is otherwise -- C++ 
> programmers _simply won't_ switch to D, and other programmers will 
> definitely have trouble using const, immutable, shared, etc...

I've never commented on this issue, but here's my viewpoint:

If you intend to change something, it's NOT const. Don't make an
object and say you won't change it then change it. It's
nonsensical. 9 times out of 10, what you really mean is "I have
an object that has some immutable/const data in it".

A clear way to understand what I mean is a Matrix. Some people
want "immutable matrices" which cache their determinant when it's
time to calculate it. What they REALLY want is a matrix of
immutable data. So, instead of a "immutable Matrix!int", they
really need to be "Matrix!immutable(int)". Effectively it's the
same thing, only it's more precisely defined and it's actually
possible to do caching with it.

The way C++ works is simply incorrect, and yes it might take some
time to get used to the fact that const means const and immutable
means immutable, but if you don't want to respect those types in
the first place, there's no sense in using them.