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.

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.

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

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.

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