• Georg Wrede (72/72) Sep 12 2007 Const is dead. Long live Const!
• Mike Streatfield (39/52) Sep 13 2007 Lately, when programming in C++ I've found myself getting bogged down in...

Georg Wrede <georg nospam.org> writes:

Const is dead. Long live Const!


After Walter declared the current const empire dead, the discussion has 
been about partially undressing the Christmas Tree and redecorating it 
"better". Nice, but no cigar.

Experience here has shown (*1) that most of us participate in 
discussions _as if they understand what's going on_. (*2) Since the 
parts one doesn't understand are different than the parts somebody else 
understands, both of them, and the audience too, may be lead to the 
impression that the entire discussion is based on facts, knowledge, and 
insight.

While this NG is not anymore /the/ place of language development, our 
contribution still is invaluable. Now our role is more in trying to 
mediate between the actual D users (ourselves, plus all those tens of 
thousands of D users who don't eve read this NG), and the core (that is, 
Walter, Andrei, etc.).

Our job is increasingly becoming watching that the solutions handed to 
us from above do stay within reason, within graspability, and are 
actually usable in real life and actual application development, by 
mortals. (There already are enough cool, respected, and awed languages 
that nobody uses.) (*3)


CONST

Today we need to simply start with a clean slate with const.

We need to go back to basics, to the actual needs that we want const to 
cater for.

Being such a fundamental and pervasive facet of contemporary 
programming, we should prioritise the issue /in the right way/. For 
example, it is becoming evident that the keywords used for the different 
flavors of const simply don't cut it. We must have words that instatnly 
convey their meaning, even to those who don't remember the entire 
documentation by heart. An issue as big as const has the /right/ to new 
keywords. And we, as programmers and D users, have the /right/ to have 
them proper, intuitive, and easy to remember.



We should also step back and give another try at enumerating (and 
sorting) the primary issues we are trying to achieve with const. Here 
again, every programmer and his granny seem to /really and fully/ know 
the what and the why. (*4) Before we can go further, we really need to 
be on the same board.


Likewise, we've forgotten to divide and conquer the problem. For 
example, pure vs. non-pure functions should be discussed separately from 
all the in/out/inout/ref argument issues. And constness should be 
generally understood from all the relevant viewpoints (local, global, 
relative, etc.) before any attempt at formulating them in the language 
is attempted. (*5)



-----

*1 Two years ago, there was a huge discussion about UTF. (September to 
November) When one now reviews that discussion, it becomes evident, 
first of all, how slowly new concepts spread in the community. And 
second, how various participants stated opinion upon opinion as if they 
were actual facts. Compared to the const issue, UTF is a really trivial 
thing, both in itself and in its ramifications. For a community that 
dares to tackle constness in its entirety, the UTF issue should have 
been fully understood within 2 weeks by everyone.

In that discussion I made a remark that the discussion should be 
reviewed after a couple of years. Insight into the participants, the 
overall dymamics of NG information exchange, and the [in]efficiency of 
insight transfer glare one right up in the face there.

*2 Some of us deliberately appear like we really understood the subject 
more fully than we do. But others simply don't see that they don't 
understand, so they honestly believe they do. And those few who openly 
say the don't understand, really are the heroes.

*3 We've already seen this happen with templates. They got all grand and 
"hi falutin'", and got outside the reach of 90% of D users. That's not 
acceptable, no matter how good press it brings.

*4 It's like asking everybody on the street what the word "respect" 
means. You're liable to get as many different answers as the folks you 
asked. Bush, Blair, the Dalai Lama, or Nelson Mandela sure would give 
you different answers to what "democracy" is.

*5 Sometimes I sorely miss the BBS bulletin boards. They were strictly 
sequential (non-threaded), and a good moderator could easily see to it 
that the common discussion got one issue settled for good before 
tackling the next one. Some things just have to be sorted out before 
there's any use in discussing others.

Mike Streatfield <dnewsgroup.c talyst.me.uk> writes:

Georg Wrede wrote:
 
 CONST
 
 Today we need to simply start with a clean slate with const.
 
 We need to go back to basics, to the actual needs that we want const to 
 cater for.
 
 We should also step back and give another try at enumerating (and
 sorting) the primary issues we are trying to achieve with const. Here
 again, every programmer and his granny seem to /really and fully/ know
 the what and the why. (*4) Before we can go further, we really need to
 be on the same board.

Lately, when programming in C++ I've found myself getting bogged down in 
whether I'm using const in the right places for the right things. When I 
recently switched to try out D for a new project, const really didn't 
seem to work in the same way at all so I dropped it, it was quite 
refreshing not to have to worry about where and when to use const in 
code and actually made me more productive.

However, I have found I've been missing being able to use const in a 
couple of cases, both of which I use essentially as a safety net. I'm 
sure these are fairly common use cases and I've not used D 2.0, so for 
all I know these are covered already, but I thought I'd contribute them 
anyway, in case they help any.


1) When declaring parameters of functions. There are a lot of cases 
where I use const to ensure that I don't accidentally change values 
passed in from another source. C++'s *const syntax was especially useful 
for this (and const references, for that matter). For example:

// Ok, I've not thought too hard about naming, but say I have
// a game state enumeration and I want to update my game's
// AI behaviour based on it. I wish to use gameState in the
// function but ensure I don't accidentally change it. Even though
// the funciton has a local copy of this int, I would rather
// the compiler caught any deviation from my intention.

void updateAIBehaviour(const int gameState)
{
	gameState = ROBOTS_ATTACK; // Compiler error here.
}



2) Essentially the same case, but when generating variables internally. 
I actually prefer Java's final syntax here, but C++ const is almost good 
enough. The idea is setting a variable once and not changing it after, 
for the same reasons as the previous case.

// Generate a height value for a terrain heightmap given the x and
// z values on the horizontal plane.
int generateHeight(int x, int z)
{
	// I wish to calculate cx once and maintain it's value
	// henceforth
	const int cx = x - OFFSET_X;

	cx = 37; // Compiler error.
}