www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const: what do you want to achieve (proposition...)?

reply Gilles G. <schaouette free.fr> writes:
I am reading all those posts about constness and how some people want to be
sure data never gets modified when passed as an argument to a function.

I would like to try a proposition:
For the following function, you cannot tell if foo is modified or not:
Bar myFunction(Foo foo)

Now, let me introduce an other way of expressing things. If one wants a
function that *can* modify foo, it could be defined like this:
(Bar,Foo) myFunction(Foo foo);

and this function may be used like this:
Bar myBar;
Foo myFoo;
Foo myFoo2;

(myBar,myFoo2) = myFunction(myFoo); // don't modify myFoo
(myBar,myFoo) = myFunction(myFoo); // modify myFoo

Here, the *compiler knows* if it must ensure the constness of myFoo or not. And
the user of the function knows *explicitly* if myFoo gets modified or not.

So, what do you think? Is this a clumsy proposition?

--
Gilles G.

PS: I don't say that this is *the* right way. I would just like to understand
why this proposition never arised.
Nov 13 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Nov 13, 2007 10:03 AM, Gilles G. <schaouette free.fr> wrote:

 So, what do you think?


It doesn't distinguish between const and invariant.

If the function is a member function, it doesn't tell me if the class
instance (this) will be modified.

But apart from that, I kinda like it. Of course, there have been
various requests for const-by-default in the past (including from me),
and also various requests for multiple return values (although I
believe we can do that now, with a slightly different syntax, using
value tuples), so I'd say the proposition has arisen before. (Just,
maybe not all at once). It's unlikely to happen though.
Nov 13 2007
next sibling parent Gilles G. <schaouette free.fr> writes:
Janice Caron Wrote:


 On Nov 13, 2007 10:03 AM, Gilles G. <schaouette free.fr> wrote:

 So, what do you think?


 
 It doesn't distinguish between const and invariant.


Of course, you need a keyword to express that something doesn't change, but you
don't need a keyword to express that a function doesn't change its arguments.


 
 If the function is a member function, it doesn't tell me if the class
 instance (this) will be modified.


This is the same problem as above, you need a keyword to express that something
is a constant. I was talking about "how some people want to be sure data never
gets modified when passed as an argument".

But now you could use the "invariant" keyword for that purpose:
class B{
    private int i=0;
    int invariant noModification(){return i;}
    int changeThis(int j){i=j;}
}
The benefit is that you only need one keyword to express that something doesn't
change, ever.

...

Wow, maybe I should dreaming and wake up now...
Nov 13 2007
prev sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Janice Caron Wrote:


 On Nov 13, 2007 10:03 AM, Gilles G. <schaouette free.fr> wrote:

 So, what do you think?


 
 It doesn't distinguish between const and invariant.
 
 If the function is a member function, it doesn't tell me if the class
 instance (this) will be modified.
 
 But apart from that, I kinda like it. Of course, there have been
 various requests for const-by-default in the past (including from me),
 and also various requests for multiple return values (although I
 believe we can do that now, with a slightly different syntax, using
 value tuples), so I'd say the proposition has arisen before. (Just,
 maybe not all at once). It's unlikely to happen though.


Walter has 90% of (an) answer up his sleeve so this is all moot.
But if the default behaviour was const you could have

foofunc(bar barValue);  //const 
foofunc(inout bar barValue); //non-const because barValue is also an output.

Doesn't solve the invariant problem though.
Nov 13 2007
prev sibling next sibling parent "David B. Held" <dheld codelogicconsulting.com> writes:
Gilles G. wrote:

 [...]
 and this function may be used like this:
 Bar myBar;
 Foo myFoo;
 Foo myFoo2;
 
 (myBar,myFoo2) = myFunction(myFoo); // don't modify myFoo
 (myBar,myFoo) = myFunction(myFoo); // modify myFoo
 
 Here, the *compiler knows* if it must ensure the constness of myFoo or
 not. And the user of the function knows *explicitly* if myFoo gets
 modified or not.
 [...]


It's not at all obvious to me by looking at either expression that 
*anything* ought to be const.  If I saw a language that allowed that 
expression (like Perl, or many other languages with first-class 
tuples/lists), I would not immediately think "Oh, myFoo doesn't get 
modified in the first case".  Quite the contrary, looking at that I 
would assume that anything could be modified (but mostly because Perl is 
the first thing that comes to mind and Perl doesn't have a real const yet).

Another problem is that your syntax just looks like a way to return a 
tuple from a function, and doesn't at all imply that it's being used to 
declare constness.  Also, a function that takes 5 const arguments will 
have to repeat them, making for a very long invokation.  Also, a 
function returning void would cause this to be a very awkward syntax:

(val) = myFunctionReturningVoid(val);  // Uh...what?

Essentially, you're overloading the meaning of operator= in a very 
non-intuitive way.  It's an interesting idea, but not very D-like.

Dave
Nov 13 2007
prev sibling parent reply Gilles G. <schaouette free.fr> writes:
You misunderstood the proposition: it implies that all parameters given to a
function would be const *except* if they are returned by the function.
So, in the example you give, if you wanted to be sure that val is not modified,
you would just call:
myFunctionReturningVoid(val);

A function which wants to change its arguments would *have to* pass them as
return values.

For example this function:
Foo myFunction(Foo foo){
    foo.value = 0;
    return foo;
}
could be called like this:
myFunction(myFoo);   // don't modify myFoo since parameters are const by default
myFoo2 = myFunction(myFoo); // still don't modify myFoo
myFoo = myFunction(myFoo);   // this is the *only* way to modify myFoo: it is
explicit
It would be up to the compiler to decide if the parameters must be passed by
value, reference, (or whatever) to acheive constness.

Simple, isn't it?



David B. Held Wrote:


 Gilles G. wrote:

 [...]
 and this function may be used like this:
 Bar myBar;
 Foo myFoo;
 Foo myFoo2;
 
 (myBar,myFoo2) = myFunction(myFoo); // don't modify myFoo
 (myBar,myFoo) = myFunction(myFoo); // modify myFoo
 
 Here, the *compiler knows* if it must ensure the constness of myFoo or
 not. And the user of the function knows *explicitly* if myFoo gets
 modified or not.
 [...]


 
 It's not at all obvious to me by looking at either expression that 
 *anything* ought to be const.  If I saw a language that allowed that 
 expression (like Perl, or many other languages with first-class 
 tuples/lists), I would not immediately think "Oh, myFoo doesn't get 
 modified in the first case".  Quite the contrary, looking at that I 
 would assume that anything could be modified (but mostly because Perl is 
 the first thing that comes to mind and Perl doesn't have a real const yet).
 
 Another problem is that your syntax just looks like a way to return a 
 tuple from a function, and doesn't at all imply that it's being used to 
 declare constness.  Also, a function that takes 5 const arguments will 
 have to repeat them, making for a very long invokation.  Also, a 
 function returning void would cause this to be a very awkward syntax:
 
 (val) = myFunctionReturningVoid(val);  // Uh...what?
Nov 13 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Gilles G. wrote:

 You misunderstood the proposition: it implies that all parameters given to a
function would be const *except* if they are returned by the function.
 So, in the example you give, if you wanted to be sure that val is not
modified, you would just call:
 myFunctionReturningVoid(val);
 
 A function which wants to change its arguments would *have to* pass them as
return values.
 
 For example this function:
 Foo myFunction(Foo foo){
     foo.value = 0;
     return foo;
 }
 could be called like this:
 myFunction(myFoo);   // don't modify myFoo since parameters are const by
default
 myFoo2 = myFunction(myFoo); // still don't modify myFoo
 myFoo = myFunction(myFoo);   // this is the *only* way to modify myFoo: it is
explicit
 It would be up to the compiler to decide if the parameters must be passed by
value, reference, (or whatever) to acheive constness.
 [...]


 From a pure functional point of view, that's all well and good.  But D 
allows in-place mutation, and that means functions have to be allowed to 
have out parameters that look like out parameters.

Dave
Nov 18 2007