Const, strings, and other things.

[Bill Baxter]

Jarrett Billingsley wrote:
> "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.

Also important to point out that "you" in the above often means "myself 
two months ago".

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

My convention in D1 is this:
    foo(/*const*/ ref T a, /*const*/string b);

It works ok.  Puts the label right there in front of the parameter where 
you can see it when looking at the function signature.  Sure would be 
nice if it actually did some checking, though.

My other convention is to name ref parameters that are meant to be 
output like  "ref Foo something_out".  I also end up making a lot of out 
parameters be pointers instead references, because then looking at the 
signature I know that it must be an out parameter, because there's no 
other reason to pass it as a pointer.

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

Come on.  Code is poorly documented.  For 90% of open source projects 
out there "better documentation" is in the top 5 on the TODO list.

> (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.)

Yes, the library writer might not have used const.  In C++ those are 
usually the ones I glance at quickly and conclude "this guy probably had 
no idea what he was doing ... tread with caution".

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

Bad naming really has nothing to do with it.

> 
> 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?

For me, I do this all the time.  Passing 4 different 4-vectors of 
doubles to a function is a good formula for killing your performance.
But I'm with you.  I shouldn't *have* to worry about the performance. 
If I could pass structs around efficiently it would kill 90% of what I 
want const for.  I think the idea of having the compiler quietly 
substitute in pass-by-reference for pass-by-value to improve efficiency 
has some promise.

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

I do hardly any text processing.  I'm mostly passing vectors and 
matrices and meshes and images around.  And a most of those things are 
big enough that you really don't want to make a copy unless you 
absolutely have to.  So whether you plan to modify the data or not 
you're going to pass it around by some sort of reference/pointer/handle.

--bb