const, final, scope function parameters

[Myron Alexander]

Robert Fraser wrote:
> Heh; this is quite the interesting thread, though I seem to feel
> quite different than most of you. I agree most function parameters
> should be final, but const, and especially scope, just seem very
> wrong to me to be a default. Maybe it's my Java background, but there
> are quite a few times I want users to pass in reference to classes
> that implement a particular interface, or otherwise have some sort of
> "setter" function for reference types, and having to rewrite all my
> existing code to somehow allow that just seems like a total waste.
> 
> Also, think about all the copying that would have to be made if scope
> was the default - if I was passing in references to big objects into
> a collection, I sure as hell wouldn't want a copy of each one made...
> one of D's advantages is runtime performance. I know that scope could
> be turned off, but if on was the default, a lot of coders would be
> more likely to use it, so I'd be much more worried about using
> someone else's code for a performance-critical task.

I have changed my mind and now think that Walter is right.

I originally thought that const meant invariant but now know that you 
can rebind a const reference to a non-const variable and affect changes. 
In my original assumption, a const value would not incur performance hit 
with scope as the optimizer could make assumptions and no copy would be 
necessary. I now know this to be incorrect.

Even though I prefer all parameters to be, at least, final, this would 
mean I am imposing my methodology on others and D is not supposed to be 
about enforcing a religion ;)

I guess I am going to have to accept that there will be libraries/code 
that are almost impossible to read, or have undocumented/unintended 
side-effects. This is something that Darwinian forces will have to sort 
out. This was the reason I left C/C++ and joined the Java circus; well, 
that and I hate #define, #import :)

On a side note, I originally considered D because I saw C+=1 done right, 
and with modules instead of source import. Of course, since then, the 
other lush goodies have their warm place in me heart.

> 
> In an ideal wold, most functions would indeed be "pure" functions,
> and if your code has a lot of math going on or something, I can
> surely see that being the case. However, real code is ugly, and
> programmers do break rules, usually knowing full-well what we're
> doing. Reassigning a parameter does occasionally introduce bugs, but
> it's a useful feature that we've come to accept and use when it
> should be used, and avoid when it shouldn't be. I'm willing to put
> "in" on API functions, and functions I expect others to use, but for
> private methods and internal functions, let me code it how I want,
> and how I expect it to work, without having to think about what I'm
> going to do with every parameter.

I agree with you 100%.

> 
> Eek, on re-reading, that came off a bit combative.... Sorry... I'll
> retreat to my Virtual-Machine-managed world, and let you
> systems-level coders duke this one out.
> 

I don't think you presented a combative tone, just laying it down like 
it is.

> All the best, Fraser
> 
> Walter Bright Wrote:
> 
>> It looks like making "const final scope" be the default for
>> function parameters is going to be infeasible. The troubles are
>> that:
>> 
>> 1) It seems to knock a lot of people for a loop, who will be
>> assuming that an undecorated name would be like an undecorated name
>> for a local or global variable.
>> 
>> 2) Having to turn off one of the const, final, or scope, introduces
>> the need for some sort of "not" keyword, like mutable, !const,
>> !final, etc. It comes off looking bizarre.
>> 
>> However, making "in" be equivalent to "const final scope" does seem
>> to work fine, requires no new keywords, and doesn't seem to confuse
>> anyone.
>> 
>> On a related note, "cstring" has received universal condemnation
>> <g>, so I'll just have to make "string" work.
> 

Regards,

Myron.