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

• Gilles G. (17/17) Nov 13 2007 I am reading all those posts about constness and how some people want to...
• Janice Caron (10/11) Nov 13 2007 It doesn't distinguish between const and invariant.
• Gilles G. (12/19) Nov 13 2007 This is the same problem as above, you need a keyword to express that so...
• Bruce Adams (6/20) Nov 13 2007 Walter has 90% of (an) answer up his sleeve so this is all moot.
• David B. Held (17/30) Nov 13 2007 It's not at all obvious to me by looking at either expression that
• Gilles G. (16/46) Nov 13 2007 You misunderstood the proposition: it implies that all parameters given ...
• David B. Held (5/22) Nov 18 2007 From a pure functional point of view, that's all well and good. But D
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
```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
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
```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
"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?

non-intuitive way.  It's an interesting idea, but not very D-like.

Dave
```
Nov 13 2007
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
"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