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.

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