Ok, I know 'const' has been beaten to death in previous threads...

However, one thing that I've not seen beaten to death is 'const by default'.

In the following post, there's a link to comp.lang.c++.moderated where Walter puts forward some very good arguments regarding what's wrong with C++ (type modifier) const:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39437

In that thread, Walter mentions that he should have made const the default. Every subsequent post agreed with not one dissenter.

Walter, what exactly do you have in mind? Only reference types? Default const for everything? Everything but function local variables? Or function return types and function parameters only?

If some type of 'const by default' was implemented, it could have big consequences for Phobos. As Phobos is 'officially' supported and distributed w/ the compiler, it is the only thing that has to be changed along with the compiler.

I'd say:
- add the 'mutable' keyword in v0.163
- let the community start modifying Phobos.
- add a "warn on non-mutable" switch to the compiler by v0.167 (that way Walter could implement all of the logic, and later cutover by removing the switch and making those errors instead of warnings).
- let the community test Phobos using the new warning switch
- 'cutover' when Phobos is done.

I think the "too much water under the bridge" problem from Walter's standpoint is that he can't count on anyone else but himself making the changes to Phobos, and he simply doesn't have the time.

I would gladly volunteer for a few of the Phobos modules but I don't have the time nor enough explicit knowledge of Phobos to lead the effort efficiently. If we could just get the 'mutable' keyword in there, then we could start a Dsource project and get "promises" from people in the community to do the work.

Just some thoughts on the matter...

Thanks,

- Dave

Dave wrote:
> Ok, I know 'const' has been beaten to death in previous threads...
> 
> However, one thing that I've not seen beaten to death is 'const by default'.
> 
> In the following post, there's a link to comp.lang.c++.moderated where Walter puts forward some very good arguments regarding what's wrong with C++ (type modifier) const:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39437
> 
> In that thread, Walter mentions that he should have made const the default. Every subsequent post agreed with not one dissenter.
> 
> Walter, what exactly do you have in mind? Only reference types? Default const for everything? Everything but function local variables? Or function return types and function parameters only?
> 
> If some type of 'const by default' was implemented, it could have big consequences for Phobos. As Phobos is 'officially' supported and distributed w/ the compiler, it is the only thing that has to be changed along with the compiler.
> 
> I'd say:
> - add the 'mutable' keyword in v0.163
> - let the community start modifying Phobos.
> - add a "warn on non-mutable" switch to the compiler by v0.167 (that way Walter could implement all of the logic, and later cutover by removing the switch and making those errors instead of warnings).
> - let the community test Phobos using the new warning switch
> - 'cutover' when Phobos is done.
> 
> I think the "too much water under the bridge" problem from Walter's standpoint is that he can't count on anyone else but himself making the changes to Phobos, and he simply doesn't have the time.
> 
> I would gladly volunteer for a few of the Phobos modules but I don't have the time nor enough explicit knowledge of Phobos to lead the effort efficiently. If we could just get the 'mutable' keyword in there, then we could start a Dsource project and get "promises" from people in the community to do the work.
> 
> Just some thoughts on the matter...
> 
> Thanks,
> 
> - Dave


Good points!

Sorry for the minimal post, but there's just not much to add to what Dave says here.

-JJR

Ahem.
Excuse me, I'm not very enlightened about this "const" issue, but if your suggestion implies that people like me who don't care about "const" will have to add "mutable" qualifiers all over the place, then I'm gonna have to side against this, with a big NO.

If I've just said something that's too stupid, then please enlighten me. Thanks.

Dave wrote:
> Ok, I know 'const' has been beaten to death in previous threads...
> 
> However, one thing that I've not seen beaten to death is 'const by default'.
> 
> In the following post, there's a link to comp.lang.c++.moderated where Walter puts forward some very good arguments regarding what's wrong with C++ (type modifier) const:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39437
> 
> In that thread, Walter mentions that he should have made const the default. Every subsequent post agreed with not one dissenter.
> 
> Walter, what exactly do you have in mind? Only reference types? Default const for everything? Everything but function local variables? Or function return types and function parameters only?
> 
> If some type of 'const by default' was implemented, it could have big consequences for Phobos. As Phobos is 'officially' supported and distributed w/ the compiler, it is the only thing that has to be changed along with the compiler.
> 
> I'd say:
> - add the 'mutable' keyword in v0.163
> - let the community start modifying Phobos.
> - add a "warn on non-mutable" switch to the compiler by v0.167 (that way Walter could implement all of the logic, and later cutover by removing the switch and making those errors instead of warnings).
> - let the community test Phobos using the new warning switch
> - 'cutover' when Phobos is done.
> 
> I think the "too much water under the bridge" problem from Walter's standpoint is that he can't count on anyone else but himself making the changes to Phobos, and he simply doesn't have the time.
> 
> I would gladly volunteer for a few of the Phobos modules but I don't have the time nor enough explicit knowledge of Phobos to lead the effort efficiently. If we could just get the 'mutable' keyword in there, then we could start a Dsource project and get "promises" from people in the community to do the work.
> 
> Just some thoughts on the matter...
> 
> Thanks,
> 
> - Dave

Hasan Aljudy wrote:
> Ahem.
> Excuse me, I'm not very enlightened about this "const" issue, but if your suggestion implies that people like me who don't care about "const" will have to add "mutable" qualifiers all over the place, then I'm gonna have to side against this, with a big NO.
> 
> If I've just said something that's too stupid, then please enlighten me. Thanks.
> 
I'm not sure what is being suggested but it's something like this:

Given a function that takes a reference type as an argument. The stuff the reference points to is not a valid target for a write unless you say so.


void fn1(char[] c)
{
	char i = c[5];	// allowed
	c[4] = i;	// not allowed
}


void fn2(mutable char[] c)
{
	char i = c[5];	// allowed
	c[4] = i;	// allowed
}


Furthermore, unless a variable is mutable, you can't pass it off to a function in a mutable parameter

void fn3(char[] c)
{
	fn1(c);	// allowed
	fn2(c);	// not allowed: c is immutable
}

The issue as to the mutability of local variables is another thing all together. I haven't heard any agreement on what is best here. One thought I like is local reference type variables are localy mutable. However if you are passing them to a function they become implicitly immutable unless you say otherwise. (Assume that "@" is the grant mutability operator)

void fn4()
{
	char[] c;

	c[5] = '\0';	// allowed

	fn1(c);		// allowed
	fn2(c);		// not allowed: arg 1 is mutable;
	fn2(@c)		// allowed
}

In the general case I expect that this change will have little effect on code. In my experience, most pass by reference cases are immutable anyway. The rest should be easy to find and fix as long as DMD gives good error messages.

BCS wrote:
> 
> The issue as to the mutability of local variables is another thing all together. I haven't heard any agreement on what is best here. One thought I like is local reference type variables are localy mutable. However if you are passing them to a function they become implicitly immutable unless you say otherwise.

I was thinking along the same lines.  There really isn't much of an advantage to making local variables immutable.


Sean

In article <e8bib0$1gn1$6@digitaldaemon.com>, BCS says...
>
>Hasan Aljudy wrote:
>> Ahem.
>> Excuse me, I'm not very enlightened about this "const" issue, but if
>> your suggestion implies that people like me who don't care about "const"
>> will have to add "mutable" qualifiers all over the place, then I'm gonna
>> have to side against this, with a big NO.
>> 
>> If I've just said something that's too stupid, then please enlighten me. Thanks.

I also share Hasan's point of view.

>I'm not sure what is being suggested but it's something like this:
>
>Given a function that takes a reference type as an argument. The stuff the reference points to is not a valid target for a write unless you say so.
>
>
>void fn1(char[] c)
>{
>	char i = c[5];	// allowed
>	c[4] = i;	// not allowed
>}
>
>
>void fn2(mutable char[] c)
>{
>	char i = c[5];	// allowed
>	c[4] = i;	// allowed
>}

Why couldn't we do it using the "in" keyword ?

>void function2 ( in char [] c )
>{
>	char i = c [5];	// allowed
>	c [4]  = i ;	// allowed
>}

>Furthermore, unless a variable is mutable, you can't pass it off to a function in a mutable parameter
>
>void fn3(char[] c)
>{
>	fn1(c);	// allowed
>	fn2(c);	// not allowed: c is immutable
>}

Won't we have the same troubles than in C++ ? Mainly copying the immutable variables to mutable ones that we would pass to the function:
>void fn3 ( char [] c )
>{
>	fn1 ( c ); // allowed
>	// fn2 ( c );	// not allowed: c is immutable
>       mutable typeof ( c ) d = cast ( mutable ) c.dup ; // Something like this
>       fn2 ( d );
>}

Makes too much copy, memory inefficient for no reason.

>The issue as to the mutability of local variables is another thing all together. I haven't heard any agreement on what is best here. One thought I like is local reference type variables are localy mutable. However if you are passing them to a function they become implicitly immutable unless you say otherwise. (Assume that "@" is the grant mutability operator)
>
>void fn4()
>{
>	char[] c;
>
>	c[5] = '\0';	// allowed
>
>	fn1(c);		// allowed
>	fn2(c);		// not allowed: arg 1 is mutable;
>	fn2(@c)		// allowed
>}
>
We could use the "out" keyword instead of the at sign. That might be more readable, or understandable.

>In the general case I expect that this change will have little effect on code. In my experience, most pass by reference cases are immutable anyway. The rest should be easy to find and fix as long as DMD gives good error messages.

I don't like the C++ const type system. It creates two parallel universes... uh,
type systems : the const one and the non const one, and we turn to use ugly cast
or copy tricks to fight against that space time disruption.
I don't want to be stuck in a worm hole again.

Rémy Mouëza wrote:
>
> Why couldn't we do it using the "in" keyword ?

It may or may not be ideal with respect to reference types (ie. classes) where 'inout' allows one to reassign the reference itself in addition to potentially mutating the referenced data.  I'm not certain whether this distinction is worth preserving or not.


Sean

Dave wrote:
> Ok, I know 'const' has been beaten to death in previous threads...
> 
> However, one thing that I've not seen beaten to death is 'const by default'.
> 
> In the following post, there's a link to comp.lang.c++.moderated where Walter puts forward some very good arguments regarding what's wrong with C++ (type modifier) const:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39437
> 
> In that thread, Walter mentions that he should have made const the default. Every subsequent post agreed with not one dissenter.
> 
> Walter, what exactly do you have in mind? Only reference types? Default const for everything? Everything but function local variables? Or function return types and function parameters only?
> 
> If some type of 'const by default' was implemented, it could have big consequences for Phobos. As Phobos is 'officially' supported and distributed w/ the compiler, it is the only thing that has to be changed along with the compiler.
> 
> I'd say:
> - add the 'mutable' keyword in v0.163
> - let the community start modifying Phobos.
> - add a "warn on non-mutable" switch to the compiler by v0.167 (that way Walter could implement all of the logic, and later cutover by removing the switch and making those errors instead of warnings).
> - let the community test Phobos using the new warning switch
> - 'cutover' when Phobos is done.
> 
> I think the "too much water under the bridge" problem from Walter's standpoint is that he can't count on anyone else but himself making the changes to Phobos, and he simply doesn't have the time.
> 
> I would gladly volunteer for a few of the Phobos modules but I don't have the time nor enough explicit knowledge of Phobos to lead the effort efficiently. If we could just get the 'mutable' keyword in there, then we could start a Dsource project and get "promises" from people in the community to do the work.
> 
> Just some thoughts on the matter...
> 
> Thanks,
> 
> - Dave

I wasn't necessarily supporting it, but if all the D experts think it is a good idea after having a long conversation about it in the newsgroups, then I wouldn't mind making changes.

clayasaurus wrote:

> Dave wrote:
> 
>> Ok, I know 'const' has been beaten to death in previous threads...
>>
>> However, one thing that I've not seen beaten to death is 'const by default'.
>>
>> In the following post, there's a link to comp.lang.c++.moderated where Walter puts forward some very good arguments regarding what's wrong with C++ (type modifier) const:
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39437
>>
>> In that thread, Walter mentions that he should have made const the default. Every subsequent post agreed with not one dissenter.
>>
>> Walter, what exactly do you have in mind? Only reference types? Default const for everything? Everything but function local variables? Or function return types and function parameters only?
>>
>> If some type of 'const by default' was implemented, it could have big consequences for Phobos. As Phobos is 'officially' supported and distributed w/ the compiler, it is the only thing that has to be changed along with the compiler.
>>
>> I'd say:
>> - add the 'mutable' keyword in v0.163
>> - let the community start modifying Phobos.
>> - add a "warn on non-mutable" switch to the compiler by v0.167 (that way Walter could implement all of the logic, and later cutover by removing the switch and making those errors instead of warnings).
>> - let the community test Phobos using the new warning switch
>> - 'cutover' when Phobos is done.
>>
>> I think the "too much water under the bridge" problem from Walter's standpoint is that he can't count on anyone else but himself making the changes to Phobos, and he simply doesn't have the time.
>>
>> I would gladly volunteer for a few of the Phobos modules but I don't have the time nor enough explicit knowledge of Phobos to lead the effort efficiently. If we could just get the 'mutable' keyword in there, then we could start a Dsource project and get "promises" from people in the community to do the work.
>>
>> Just some thoughts on the matter...
>>
>> Thanks,
>>
>> - Dave
> 
> 
> I wasn't necessarily supporting it, but if all the D experts think it is a good idea after having a long conversation about it in the newsgroups, then I wouldn't mind making changes.

FYI: I posted my thoughts in D.learn under :
"so what exactly is const supposed to mean?"

I should have posted here...oh well.

So far I'm pretty convinced that some kind of "constness" is a good thing.  I've already run into one area where this would be useful.

I have one peeve about it though: I really would not like it if the keyword used to represent constness was "const".  I will explain from my newbie-to-Cplusplus background, having come from languages that seem, at least to me, to be much more well thought out than Cplusplus.

When I see "const" I think of it as a shorthand for "constant", just as "bool" is shorthand for "boolean".  My understanding of something constant is that it does not change... EVER.  Thus it makes no sense to me why something as ephemeral as data passed into a function could be considered constant.  If the constant data leaves the scope of the function, becomes no longer constant, and gets changed, then it isn't really constant to me.

I do like the mutable word though, as it seems to have an english meaning very close to its programming meaning  :)
It also seems that if we were to make things immutable by default, we could make an "immutable" keyword.  Sure it's kinda long, but since most things are that by default then we won't be typing it much.  It also seems so much more logically related to the word "mutable".

Another worry I have is that of being stuck with many instances of "mutable" littering my code, if only because said code happens to modify referenced data a lot.  One way I might see this worry dissappearing if there was a way to blanket stuff into being immutable, in order to avoid repeating the word over and over again.  Sorta like:

class Foo
{
  mutable:
    int[] data; // this is mutable
    char[] name; // this too
    // etc
}

or maybe even something as radical as

mutable
{
  // from now on everything works as it used to

  void func1( char[] string1, char[] string2 )
  {
    string1[5] = 'a'; // ok
    string2[3] = 'b'; // also good
  }

  void func2( int[] data )
  {
    data[8] = 42; // just dandy.
  }
}

Note:  I am probably so newbish at language design compared to you guys it is not even funny, so maybe the syntax suggestions suck, but please consider my naming plea, at least as a "this experience was unpleasant so please fix it" sorta thing.