Reiner Pope wrote:
> void foo(!const C c)
> {
>     c.x = 3;
> }
> 

Although, on second thoughts, the ! there looks quite invisible...

Bill Baxter wrote:
> Walter Bright wrote:
>> Another option is to reuse 'inout' to mean 'mutable', since 'inout' is replaced by 'ref'.
> ...which is what my last message was suggesting.

You're right, I read your posting too quickly.

> Any reason why that wouldn't work?

Breaking existing code.

> There is the question of what would happen to "out" and how you'd get out behavior applied to the pointer rather than the value.

I'd leave out as it is.

> And while "mutable" is on the table, is D going to have a story for private mutable members that don't affect the interface?  Like the classic private mutable cache member in C++.

Ah, the "logical constness" design pattern. I personally loathe that <g>. Const but mutable data just smacks of being far too clever.

Reiner Pope wrote:
> or why not use the ! operator, which already means 'not':
> 
> void foo(!const C c)
> {
>     c.x = 3;
> }

That's Andrei's suggestion, too. It would take some getting used to.

Walter Bright wrote:
> Reiner Pope wrote:
>> or why not use the ! operator, which already means 'not':
>>
>> void foo(!const C c)
>> {
>>     c.x = 3;
>> }
> 
> That's Andrei's suggestion, too. It would take some getting used to.

I'd prefer it, though. That, or some other mechanism for const by default, but I like this syntax because no new keywords are needed and it's not overly verbose.

Reiner's thought that the ! looks invisible doesn't matter, in my opinion, because you wouldn't ever write "const" without the ! for a function parameter.

A 2.0 release is the time to break existing code, and I don't see why you shouldn't do so. Existing projects can go on with only 1.0 support or convert to 2.0 as they will.

Walter Bright Wrote:
> Bill Baxter wrote:
> > Walter Bright wrote:
> >> Another option is to reuse 'inout' to mean 'mutable', since 'inout' is replaced by 'ref'.
> > ...which is what my last message was suggesting.
> 
> You're right, I read your posting too quickly.
> 
> > Any reason why that wouldn't work?
> 
> Breaking existing code.
> 
> > There is the question of what would happen to "out" and how you'd get out behavior applied to the pointer rather than the value.
> 
> I'd leave out as it is.
> 
> > And while "mutable" is on the table, is D going to have a story for private mutable members that don't affect the interface?  Like the classic private mutable cache member in C++.
> 
> Ah, the "logical constness" design pattern. I personally loathe that <g>. Const but mutable data just smacks of being far too clever.

My feeling is that if we have 'scope const final' as default and implicit then we do need some way to escape it, as we've all suggested.

I think the best way is as Daniel suggested, any keyword will override the implicit/default ones, so:

void foo(int i) {}  //scope, const, final
void foo(const int i) {} //just const
..etc..

So, that just leaves the problem you (Walter) proposed of:

>class C { int x; }
>void foo(C c)
>{
>     c.x = 3;
>}

and being able to pass a mutable reference.

Would this reference be 'scope' or 'final'?  My understanding is that 'final' means the reference itself could not be changed and 'scope' means an outside reference cannot be given it's value.

It seems to me you want both of these ('scope' because the reference will persist outside the function and 'final' because the very point of 'ref' is to be able to modify the reference) except in cases where you pass it by 'ref', in which case you want neither.

Assuming we want 'scope' and 'final' applied to these mutable references then I dislike re-using 'inout' because (and perhaps this is ingrained thinking due to having used inout and out) the 'out' part of the keyword doesn't immediately appear to be happening.  We're not setting the reference to something which is then used 'out'side the function, instead (as Bill mentioned) we're changing them internally and only in this way is it reflected outside the function.

I'd think I'd prefer to use a new keyword like 'mutable', which in our case would be a shortcut for 'scope final'.

In a general sense it seems we have 2 classes of keyword here, the base ones:

const
final
scope
ref

and these handy, shortcut, combination ones:

in(default) = const, scope, final
mutable = scope, final

The question I think we need to ask before we decide what keyword to use is:  do we want/need to have opposites for all the base keywords? or do we want to use !<keyword>? or do we want something else?

I dislike !<keyword> purely for aesthetic reasons, to me it looks *ick*.

So, if we had opposites what would they be?

const - mutable?
scope - global?
final - mutable?

I seem to have hit a little wall here, we can't use mutable for both the opposite of const and final, and then also for the combination of 'scope final', can we?

It seems I have asked more questions than given answers, hopefully someone else can come up with a few solutions :)

Regan Heath

Regan Heath Wrote:
> It seems to me you want both of these ('scope' because the reference will persist outside the function and 'final' because the very point of 'ref' is to be able to modify the reference) except in cases where you pass it by 'ref', in which case you want neither.

Re-reading this it appears I have made a mistake and worded it terribly to boot.  To clarify...

What I was trying to say is twofold:

1. Because we have 'ref' as an option then in the cases where we do not use 'ref' we do not need to modify the reference and therefore it should be 'final'.

2. Because the reference is not passed by 'ref' it is a copy and will not persist outside the function and therefore is 'scope'

In short, unless you use 'ref' you want 'scope final' applied to these references.

Fingers crossed I haven't made any more mistakes there.

Regan Heath

Regan Heath wrote:
> Walter Bright Wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> Another option is to reuse 'inout' to mean 'mutable', since 'inout' is replaced by 'ref'.
>>> ...which is what my last message was suggesting.
>> You're right, I read your posting too quickly.
>>
>>> Any reason why that wouldn't work?
>> Breaking existing code.
>>
>>> There is the question of what would happen to "out" and how you'd get out behavior applied to the pointer rather than the value.
>> I'd leave out as it is.
>>
>>> And while "mutable" is on the table, is D going to have a story for private mutable members that don't affect the interface?  Like the classic private mutable cache member in C++.
>> Ah, the "logical constness" design pattern. I personally loathe that <g>. Const but mutable data just smacks of being far too clever.
> 
> My feeling is that if we have 'scope const final' as default and implicit then we do need some way to escape it, as we've all suggested.
> 
> I think the best way is as Daniel suggested, any keyword will override the implicit/default ones, so:
> 
> void foo(int i) {}  //scope, const, final
> void foo(const int i) {} //just const
> ..etc..
> 

That makes sense to me too.  If you don't say anything it's 'scope const final'.  But if you do specify something then it's only that.  I'm not wild about the aesthetics of !const for parameters, and even less wild about the possibility that !const could become common idiom for modifiable parameters.  If it's a common way to pass a parameter, then there should be a way to express the attribute positively (like "mutable" or "variable" or "inout") in terms of what it does do, rather than what it doesn't.

--bb

Bill Baxter wrote:
> That makes sense to me too.  If you don't say anything it's 'scope const final'.  But if you do specify something then it's only that.

Right. There are too many qualifies to do otherwise.

> I'm not wild about the aesthetics of !const for parameters, and even less wild about the possibility that !const could become common idiom for modifiable parameters.  If it's a common way to pass a parameter, then there should be a way to express the attribute positively (like "mutable" or "variable" or "inout") in terms of what it does do, rather than what it doesn't.

Uh, I think you put a finger on just where I was getting a bad feeling about !const. It's generally confusing to use negatives as attributes, i.e., having state variables named:
	"notFull"
is a bad idea.

I'm at the moment thinking we should just bite the bullet and introduce 'mutable' as a keyword.

On Mon, 21 May 2007 19:11:01 -0700, Walter Bright wrote:

> I'm at the moment thinking we should just bite the bullet and introduce 'mutable' as a keyword.

Excellent!

And could the opposite of 'scope' be 'persist', maybe?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/05/2007 3:37:15 PM

Derek Parnell wrote:
> On Mon, 21 May 2007 19:11:01 -0700, Walter Bright wrote:
> 
>> I'm at the moment thinking we should just bite the bullet and introduce 'mutable' as a keyword.
> 
> Excellent! 
> 
> And could the opposite of 'scope' be 'persist', maybe?

No, the opposite of scope would just be - nothing.