Stepping back and looking at constness from another angle.

Sean Kelly sean at f4.ca
Tue Jun 5 07:25:01 PDT 2007


Jarrett Billingsley wrote:
> 
> What I'm asking you more seasoned programmers, and those more experienced 
> with const-correctness to do, is to do something similar here.  Step back, 
> and have a look at what constness is for.  What problems does it solve?  Is 
> it necessarily the best way to solve them?  More importantly, what problems 
> does it introduce?  Remember, how the language _looks_ is just as important 
> as the features it has.  After all, what do you want to look at for hours on 
> end each day if you use it at your job?

'const' is essentially a contract that should guarantee certain behavior 
of a function.  It can make multi-threaded code more efficient because 
it obviates the need for locks in some cases, and can help verify at 
compile-time that code does not violate the guarantees it attempts to 
maintain.

That said, although I'm coming from a C++ background and though I have 
used 'const' as a matter of course, it has never actually improved my 
code.  I've never accidentally violated const behavior and had the 
compiler catch the mistake for me, and dealing with const qualifiers and 
overloads is an absolute nightmare at times.  I've got to admit that 
I've become somewhat of a D convert in this respect.  I don't miss 
'const' and will probably be annoyed if these changes complicate the 
code I write.

> I realize that this is late in the game.  I feel like Walter and company 
> have probably already ironed out most of the issues and semantics of the new 
> syntaxes, if not begun to work on them.  I don't want to discredit all 
> they've done at all.  I'm just wondering if it's the best thing for the 
> language.

The proposed changes are actually pretty decent from a conceptual 
standpoint but I don't like the syntax.  Using three synonyms to 
represent different facets of const behavior kind of stinks.  I'm sure 
I'll get used to it with practice, but I worry that the const features 
will hurt readability for those new to the language, and will complicate 
code in the general case for little actual gain.

> (And one final concern is -- what if this is implemented and it's a mess?  A 
> total disaster?  Will Walter just say "sorry guys, we messed up" and take it 
> out?  Or will he, having put in so much time and effort, just say "well 
> you're stuck with it"?  This is a huge feature.  This isn't regex match 
> expressions.  If it gets put into the language, it might not be taken back 
> out.  Especially since this is pretty much _the_ D 2.0 feature.) 

That's why it's in a branch.  Frankly, I'm surprised to say that 'const' 
is probably my least anticipated 2.0 feature.  I suppose I've simply 
been using D for long enough now that I don't really miss it from C++. 
That said, I suspect it may be important for D to gain acceptance in 
corporate environments, and wonder why no one has ever complained about 
Java's lack of const (to my knowledge).

What worries me most is that these new features will change things about 
the language that I like--the .length/T[new] issue being the most recent 
example.  Fritz's example is a core concept in much of Tango, and if it 
breaks we're pretty much sunk.  If the syntax changes but it still 
works... I suppose we'll see.  For the rest, I'm really just waiting to 
see how the new features pan out.


Sean



More information about the Digitalmars-d mailing list