Suggestion: object const'ness

[Regan Heath]

On Sun, 21 May 2006 17:58:57 -0600, Hasan Aljudy <hasan.aljudy at gmail.com>  
wrote:
> This is just my opinion .. I don't think it's a big deal though, but  
> since you asked, here's what I think:
> I think a "ref" or "byref" keyword would be more meaningful than "inout".

I disagree. "byref" is _less_ meaningful (read on for my reasoning).

> "in" is the default and shouldn't need a keyword anyway.

Agreed. It's probably only there for the Derek's of this world :)
Each to their own I say.

> "out" is somewhat similar to inout (see my post/question in the learning  
> NG); it offers no special functionality, and I think it's rarely ever  
> used. so it's really not needed.

I use "out" in cases like:

void loadX(out int a, out int b, out int c);

where X can be anything you like i.e. UserDefaults or ServerSettings or  
whatever. Where the types need not be 'int', where they would have more  
meaningful names than a, b, and c. Basically in any situation where you  
want to return more than 1 "result" from the function.

(yes, there are other ways to do this sort of thing i.e. returning a  
composite data type struct/class etc)

The fact that "out" initialises the variables to their init values is  
important, just like D's other instances of default initialisation for  
variables. The other reason you would use "out" and not "inout" is that  
"inout" implies "input" as well as "output" and that's clearly not the  
case here. So saying "inout", or not saying anything (byref) is wrong,  
confusing or _less_ meaningful.

In short, "byref" says "this is being passed by reference" whereas "out"  
says "this variable will recieve output from this function", likewise  
"inout" says "this variable contains input and will/may receive output  
 from this function". In short, "out" and "inout" hold more meaning than  
"byref" would.

In actual fact, "out" and "inout" don't actually state the variable will  
be passed by reference, that's just how it happens to be implemented.  
There may in fact be no other way to do it, but that's not the point. The  
point is that "out" and "inout" do not mean "this is being passed by  
reference", they never have (IMO, of course).

> PS: "in" and "out" would still be keywords; they're used in function  
> contracts.

To my mind "out" and "inout" are solely function contracts. They just  
happen to cause pass by reference (because that's how they achieve their  
goal).

I don't want to re-start the old "byref" discussion, but, I still cannot  
see a need for it(byref). If you want to pass a struct, or other value  
type, as input, by reference, you just use a pointer, eg.

struct A { int abc; }
void foo(in A* p) {
   //note D automatically de-references the pointer for you (in most cases)
   p.abc = 5;
}

Until we get some sort of const system, the 'in' parameter, the pointer  
'p', is all that is 'protected' from modification, it's contents are open  
to modification.

Now, you _could_ pass it by value, that would protect it's contents, but  
what about the contents of it's contents, for example:

struct A { char *str; }
void foo(A a) { a.str[0] = 'a'; }

any reference contained in a struct is itself protected, but not so the  
data to which it refers. Any const system would ideally therefore need to  
handle several layers of protection, perhaps my preventing the use of  
reference types as an lvalue?


All in all, I guess all I'm trying to say is that I like "out" and "inout"  
I think they perform a valid and valuable task, in fact they're a big step  
up from the days of using a pointer or passing by reference because they  
add _more_ meaning, they actually tell you what the function programmer  
intended to do with the parameter.

I would like to see some sort of const guarantee and I think "in" should  
play a part, I think by default parameters should be passed as "in" (as  
they are) and should be protected/const/read-only by default.

Regan