Const, strings, and other things.

[Jarrett Billingsley]

"Janice Caron" <caron800 at googlemail.com> wrote in message 
news:mailman.52.1194907553.2338.digitalmars-d at puremagic.com...
>I like const!
>
> I like to know that when I pass /my/ data to /your/ function, then
> your function is not going to mess with my data. const in the
> declaration of your function is what gives me that guarantee.

Oh, _come on_.  Chances are if your code is passing data to my function, one 
or more of the following is true:

1) We're on the same team, and we have some sort of convention set up for 
this kind of thing.

2) You're using a library that I wrote, and it's probably well-documented, 
or at least self-obvious, whether or not my function modifies your data. 
(Keep in mind that even if there _is_ const available and my function is not 
well-documented, I don't _have_ to use const, and so you don't have any 
guarantee anyway.)

3) I'm not a complete moron and actually name my functions after what they 
do.  Face it, most people don't write functions with one name and have them 
do something completely different, and if that's happening, constness is not 
really going to help you with that.

My big question is: how often do you pass some reference type into a 
function and hope that it will/won't be modified?  Here are some possible 
reference types:

- Const refs to structs.  Why do these exist?  ref to get the compiler to 
pass the struct efficiently, and const to preserve value semantics. 
Wouldn't this be better served by some other mechanism, such as the 
optimizer?

- Pointers.  Come on, don't use pointers.  ;)

- Class instances.  I'll get back to this.

- Arrays of things other than characters.  OK, I can see a use for declaring 
an array as read-only, although most of the time I'm modifying my arrays 
left and right.

- Strings.  The single most common kind of array, and they even have special 
read-only literals built into the language.  It makes sense to provide 
read-only strings, if for nothing else efficiency.  Most of the time you're 
not going to be modifying the strings after you've done some machinations.

As for class instances, this is where it's a grey area.  So I did a bit of 
research into my own code, and this is what I've come up with, as far as why 
I'm passing class instances into functions:

- As some sort of object to be mutated, i.e. a context or state class (like 
a function that adds some symbol to a given symbol table).

- In order to construct/set up an aggregate object, such as some kind of 
complex IO class which takes an output stream, a layout instance, etc.  In 
virtually all cases these instances are subsequently modified by the methods 
of the owner object.

- As a sort of 'struct on steroids', that is, just a data-holding class 
instance with some methods.  These I guess are candidates for constness, but 
the incidence of these is so small and the functions which use them are so 
short and what they do is so obvious that I have no idea what gains I will 
get from using const.

I'm just absolutely curious as to what on earth, _other than strings_, that 
you'll be passing to other code that you don't want it to be modified.