Stepping back and looking at constness from another angle.

[Jarrett Billingsley]

"Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
news:f42c51$1ap8$1 at digitalmars.com...
> Here's a thought I had a while back.  Actually, the #1 practical thing I 
> want const for is to make it possible to pass a big struct efficiently to 
> a function and know for certain that the caller's value won't be modified.
>
> Taking a cue from the removal of 'virtual' from D, one thing D could do 
> would be to automatically choose to pass variables by reference based on 
> performance criteria.  Have the compiler let me write:
>     Vec4f add(Vec4f rbga1, Vec4f rgba2) { }
> and not have to worry about whether it would be more efficient to pass a 
> const ref there.  People pass const refs all over the place in C++ not 
> because they want reference semantics, but because they want reference 
> performace.  So let the compiler worry about the optimization, not me. 
> I'll specify the semantics, and you, Mr. Compiler, figure out how to make 
> it efficient. That's basically what Walter's done with virtual, which is 
> great.  One less low-level thing for me to worry about.
>
> The crux there is that I really don't care how it gets passed under the 
> hood as long as it's efficient and behaves as if it were passed by value.

I really like that idea.  It also implicitly reduces maintenance.  If today, 
passing a 16-byte struct on the stack is more efficient to pass by 
reference, or if a struct doesn't fit in a register, but five years from now 
that's no longer the case, we don't have to go around removing all the refs 
to improve performance.  The compiler knows what's better.

> In terms of a real, comprehensive answer to your question (as opposed to 
> just a trick for struct parameters), I think the two main alternatives you 
> see are 1) functional programing languages 2) the ostrich approach.
> In pure functional languages, everything is immutable, so problem solved. 
> It's the compiler's job to try to make it efficient.  But approach 2), put 
> your head in the sand and ignore it, is also quite popular.

Aww, but I like the ostrich approach :)

I'm actually more interested in the const-by-default idea, which is a lot 
like functional languages.  I'd be interested to see how it would pan out. 
It's also a _new idea_ -- nothing like this has ever been done in a 
non-functional language AFAIK, and we'd be breaking new ground.  Who knows, 
it could be what we've been looking for.  And if it isn't -- hey, we've got 
the current const ideas to fall back on.

> The question is whether the end result is really worth the effort.  I 
> don't really know.  I had thought so, but it really has to be weighed 
> against the inconveniences introduced by the new design for const, which 
> we can't be sure of right now.  But I think it's a very valid question. If 
> the safety line preventing you from falling off the cliff gets you all 
> tangled up and in the end ties one of your hands behind your back, then 
> clearly things have gone too far.

Which is why I think const-by-default would be interesting to try.  If you 
really think about it, there are a lot of things that usually don't change, 
and a lot of methods that shouldn't have any side effects.  Explicitly 
marking code which _does_ have side effects seems to make more sense than 
explicitly marking that which _doesn't_.