Const, strings, and other things.

[David B. Held]

Jarrett Billingsley wrote:
> [...]
> 1) We're on the same team, and we have some sort of convention
> set up for this kind of thing.

Hahahahaha!!!  I see you've never worked for a company with more than 5 
people.  The idea that you can get even 5 people in a team in a large 
company to agree on a "convention" is rather amusing.  If you work in a 
company with at least 5 *teams*, you have another class of problem 
altogether.

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

Wow, maybe you write libraries that way, but you should take a look 
around.  95% of software engineers don't.  Most of the code I see, I'd 
be happy of there were *comments*, let alone documentation about 
mutability and constness.

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

I have the guarantee that if you use const, you can't hack my data, and 
if you don't use const, I don't have to use your code.  At the worst, I 
will copy my data before hand and curse you for the performance hit. 
And I can show you code bases where you will do this for your own 
sanity; and yes, the code will make you cry.

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

So you're in the middle of an app that executes a bunch of business 
logic, and the function is a hundred lines long and is called 
processFoo(Foo foo, Bar bar, Baz baz).  Which of those arguments do you 
expect to get modified and why?  Does this sound like an unreasonable 
name?  Well, unreasonable or not, I see names like this a hundred times 
a day.  I don't have the luxury of going around and renaming them as 
processFooModifiesFooButNotBarOrBaz(Foo foo, Bar bar, Baz baz).

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

Just about every time I write some code.

> [...]
> - 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?

Sure.  And for the optimizer to tell that it can replace a copy with a 
const ref, what does it need to do?  It needs to prove that there are no 
mutable operations on the object.  I.e., it needs to prove that the 
object is const!  Granted, once you have const, you could have the 
optimizer do these replacements for you, but clearly, the const-proving 
mechanism itself is essential.

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

Easier said in D than C++.

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

Yeah, since classes only cover maybe 2% of user types in D.

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

This depends entirely on the nature of the code you're writing.  For 
some kinds of apps, in-place modification makes perfect sense.  For 
others, you want to transform data from one form to another, and the 
input and output types are different, so there is no opportunity for 
in-place modification.  In this case, you may want the input to be 
immutable so you can reuse it in a subsequent call.

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

But clearly, nobody needs read-only vectors, because scientific 
computing *always* entails modifying your matrices, tensors, etc.  And 
if they do, they can just translate them to read-only strings instead, 
which are faster.

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

Have you ever heard of a little thing called "Service-Oriented 
Architecture"?  The idea there is to decompose a large distributed app 
into independent components so that you have loose coupling and 
well-defined interface boundaries, as well as nice opportunities for 
parallelization for scaling.  Well, in SOA, all the data gets passed 
between services as messages.  And in a business with big data objects, 
those messages can get rather large.  Most of the time, there is no 
reason to manipulate the message itself (any more than you need to 
manipulate a packet you received over a network).  When a function needs 
to dig into one of these, there's no reason for it to be non-const, and 
you may want to pass the message to multiple functions for processing.

Any time you read a business object off a database for display to a 
user, you don't want to mutate the object.  This kind of thing happens a 
*lot* in business apps.  Things that happen to be very dynamic and 
stateful will have more mutation (like games, simulations, etc.).  The 
rest are going to benefit a lot from 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.

How about "just about everything"?

Dave