const, final, scope function parameters

[Regan Heath]

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.

I think you may have a missunderstanding of one or more of the terms and the changes Walter suggested.  If I'm wrong feel free to ignore my reply, or read it out of interest only ;)

I don't think a re-write would be necessary in the case you describe above, just removal of 'const' from the input parameter (as you intend to call methods which modify the data to which the refernece refers).

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

But that's already what happens.  When you pass anything to a function a copy is made (unless you use 'ref' or 'out').  The important thing to realise is _what_ is copied.  In the case of a value type the entire value type is copied, but, in the case of a reference/array only the reference is copied.  The data to which a reference refers is never copied and 'scope' does not change that.

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

'scope' poses no performance problems as it doesn't change the existing behaviour, it is actually just a formalisation of existing behaviour.  Take this example:

class A { ..large object, lots of members.. }
void foo(A b) {}
A a = new A();
foo(a);

when foo is called a copy of the reference 'a' is made and it is called 'b'.  It is 'scope' because it exists solely in the function scope, once the function returns 'b' ceases to exist (because it was a copy of 'a' on the stack and the stack is reclaimed at function exit).

This is what currently happens in D, and is what happens in C and C++ too. 'scope' is intended to detact and prevent this:

A* pa;
void foo(A b) { pa = &b; }

In the above pa is set to the address of the reference 'b', this address becomes invalid when 'foo' returns and thus violates 'scope'.  Likewise this:

A* foo(A b) { return &b; }

will be caught and prevented.

This above code is currently valid D and the compiler gives no errors, once 'scope' is added to D the compiler will detect this and give an error.

As for the others...  

'final' means you cannot reassign the reference/array parameter during the function call.  eg.

void foo(A b) { b = new A(); }  //voilates 'final'

Initially you might not think this re-assign was dangerous and needed preventing, after all 'b' is a copy and changing it does not affect the original reference 'a' in any way.  However, in a large function re-using an input parameter can introduce hard to find bugs, especially if 2+ programmers are working on the same code.

Lastly 'const'.  I think this one is the most important, especially given that arrays data is referenced.  By this I mean when you call 'foo' here:

void foo(char[] b) { b[0] = 'a'; }

'b' may be a copy of the original array reference 'a', but they both refer to the same array data and therefore changes to that data using either reference affect the other.

This behaviour is often called 'aliasing' as 'b' is effectively an alias of 'a', changes via 'b' are the same as changed via 'a'.  This is a source of many bugs and providing some protection, and by default, will prevent a large number of 'aliasing' bugs.

Wow, that became a novel almost, sorry.

Regan