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.

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

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