Chad J wrote:
> 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.


hehe -- that would certainly resolve the problem for existing libraries: just wrap each entire module in a mutable{} block -- phobos would be done in 15 minutes :D

Good idea!

"kris" <foo@bar.com> ??????:e8cu1q$nbc$1@digitaldaemon.com...
> Chad J wrote:
>> 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.
>
>
> hehe -- that would certainly resolve the problem for existing libraries: just wrap each entire module in a mutable{} block -- phobos would be done in 15 minutes :D
>
> Good idea!
>

NO, Yet another colon / brace syntax.

kris wrote:

> 
> hehe -- that would certainly resolve the problem for existing libraries: just wrap each entire module in a mutable{} block -- phobos would be done in 15 minutes :D
> 
> Good idea!


lol!

On Tue, 4 Jul 2006 13:42:11 +0800, Boris Wang wrote:

> "kris" <foo@bar.com> ??????:e8cu1q$nbc$1@digitaldaemon.com...
>> Chad J wrote:
>>> 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.
>>
>>
>> hehe -- that would certainly resolve the problem for existing libraries: just wrap each entire module in a mutable{} block -- phobos would be done in 15 minutes :D
>>
>> Good idea!
>>
> 
> NO, Yet another colon / brace syntax.

Disregard Boris ;-)   It's a great idea.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
4/07/2006 3:48:13 PM

"Derek Parnell" <derek@nomail.afraid.org> ??????:zrz58urdcgmf$.yw3ohvtn0rct$.dlg@40tude.net...
> On Tue, 4 Jul 2006 13:42:11 +0800, Boris Wang wrote:
>
>> "kris" <foo@bar.com> ??????:e8cu1q$nbc$1@digitaldaemon.com...
>>> Chad J wrote:
>>>> 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.
>>>
>>>
>>> hehe -- that would certainly resolve the problem for existing libraries:
>>> just wrap each entire module in a mutable{} block -- phobos would be
>>> done
>>> in 15 minutes :D
>>>
>>> Good idea!
>>>
>>
>> NO, Yet another colon / brace syntax.
>
> Disregard Boris ;-)   It's a great idea.
>
Please disregard me, again, :)

I work at linux kernel about two years once, love reading the kernel mail
list. i learn about
what's seriousness, professional and hacker in there. until now, my whole
works not on windows os.

IMHO, in NG of D, i can't get the feelings got from linux kernel mail list. The idea, like above, can't be approved in the world of LK.

> -- 
> Derek
> (skype: derek.j.parnell)
> Melbourne, Australia
> "Down with mediocrity!"
> 4/07/2006 3:48:13 PM
> 

BCS wrote:
> 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.

I would also propose that mutable function parameters become locally mutable in the scope of the function.  This would make it necessary to always 'grant mutability' and those make it obvious when reading code.  ie:

void fn5(char[] b, mutable char[] d)
{
    char[] c;

    b[5] = '\0';   // not allowed: b is immutable
    c[5] = '\0';   // allowed
    d[5] = '\0';   // allowed

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

Joe

BCS wrote:
> 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.

I think there's a problem with all this "grant mutability/immutability", which is that we're just degenerating into C++ with its const_cast. With it, the compiler has few, if any, guarantees about the constness of anything --- it can always be casted away.

The way I see it, something either is or isn't mutable, and it should stay that way for the duration of the program --- in some cases, for the duration of a function or the lifetime of an object.

Deewiant wrote:
> BCS wrote:
>> 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.
> 
> I think there's a problem with all this "grant mutability/immutability", which
> is that we're just degenerating into C++ with its const_cast. With it, the
> compiler has few, if any, guarantees about the constness of anything --- it can
> always be casted away.
> 
> The way I see it, something either is or isn't mutable, and it should stay that
> way for the duration of the program --- in some cases, for the duration of a
> function or the lifetime of an object.

I think the issue is to find a balance between clarity and elegance.  On the surface, const as default would suggest the need to qualify nearly all local variables as 'mutable'.  But if the issue really is enforcing call contracts for function parameters and return values, as well as loop invariant optimization, then perhaps const-ness could be limited to these areas as well?  For example, it should only be necessary to qualify reference types as 'mutable' as everything else is passed by value anyway.  I am coming to think that 'in' vs. 'inout' may be sufficient to distinguish intent for function parameters, which leaves return values and declarations.  I can't say I'm entirely happy with the idea of using 'mutable' all over the place for declarations even though it would probably be easiest.  In some respects I'd rather leave declarations as-is and "mutable" qualify variables at the point of use:

    MyClass fn( MyClass c, inout MyClass d ) {}

    MyClass a, b;

    inout MyClass e = fn( a, inout b ); // error

But I'll admit to not being entirely happy with this syntax either.


Sean

In article <e8bv9b$2gu8$1@digitaldaemon.com>, Rémy Mouëza says...
>
[...]
>Why couldn't we do it using the "in" keyword ?
>

"in" allows the function to change the array in the calling function. As used now, it has no barring on changeling the *contents* of said array.


[...]
>
>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:

What else could you do? Assume a reference to immutable data, and a function that takes a mutable reference. If the idea of "const" is going to have an meaning at all, you can't pass the reference to the function because the mutable attribute as much as says "I'll going to change this data". Unless I'm missing something huge, you have to pass the function a copy or not use the function.

[...]
>
>We could use the "out" keyword instead of the at sign. That might be more readable, or understandable.

The syntax is almost irrelevant at this point, however "out" don't seem to intuitive to me. OTOH I can't think of any better keywords at this point.

All in all, I haven't made up my mind on how to do const. Const by default looks viable at this point.

Deewiant wrote:
> 
> 
> I think there's a problem with all this "grant mutability/immutability", which
> is that we're just degenerating into C++ with its const_cast. With it, the
> compiler has few, if any, guarantees about the constness of anything --- it can
> always be casted away.

Casting away mutability (unless I'm totally nuts) is always safe. Casting away immutability should never be allowed.

> 
> The way I see it, something either is or isn't mutable, and it should stay that
> way for the duration of the program --- in some cases, for the duration of a
> function or the lifetime of an object.

Each specific reference *would* be mutable or immutable for it's entire duration. It would be a compile time attribute of a reference. The only time that the mutability of a reference would change is when it is copied to another reference, in a function call for instance, and then the only change that can be made is the new reference can *lose* mutability.