View mode: basic / threaded / horizontal-split · Log in · Help
November 13, 2007
Const: what do you want to achieve (proposition...)?
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.
November 13, 2007
Re: Const: what do you want to achieve (proposition...)?
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.
November 13, 2007
Re: Const: what do you want to achieve (proposition...)?
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...
November 13, 2007
Re: Const: what do you want to achieve (proposition...)?
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.
November 14, 2007
Re: Const: what do you want to achieve (proposition...)?
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
Top | Discussion index | About this forum | D home