OK, I think I'm starting to grasp the subtle differences between const, final, and invariant.  It seems to me that to have three keywords is unnecessary.  Perhaps const and final could be merged into one?

From my understanding, the only difference between const and final is that local final fields can be initialized in a constructor, right?  Couldn't that just be the default behavior of a local const field?  Then we could get rid of final and have only two keywords.  Or am I missing something?  IMO, two keywords is way less confusing than three.

Another question.  Since invariant data should always be invariant, does it make sense to be able to cast non-invariant data to invariant?  The compiler will think that it is invariant when it isn't.

-Craig

Craig Black wrote:
> OK, I think I'm starting to grasp the subtle differences between const, final, and invariant.  It seems to me that to have three keywords is unnecessary.  Perhaps const and final could be merged into one?

Funny, I was going to say that about 'final' and 'invariant'.  So far as I can tell, the only difference between them from a user perspective is that 'invariant' is transitive while 'final' is not.  The ROMability of 'invariant' is a compiler issue and is meaningless to the user.

> From my understanding, the only difference between const and final is that local final fields can be initialized in a constructor, right?  Couldn't that just be the default behavior of a local const field?  Then we could get rid of final and have only two keywords.  Or am I missing something?  IMO, two keywords is way less confusing than three.

That was my thought as well.

> Another question.  Since invariant data should always be invariant, does it make sense to be able to cast non-invariant data to invariant?  The compiler will think that it is invariant when it isn't.

This is probably just a matter of not making special cases for the compiler.  Casts are always allowed, even those that don't make sense.


Sean

Craig Black wrote:
> OK, I think I'm starting to grasp the subtle differences between const, final, and invariant.  It seems to me that to have three keywords is unnecessary.  Perhaps const and final could be merged into one?
> 
> From my understanding, the only difference between const and final is that local final fields can be initialized in a constructor, right?  Couldn't that just be the default behavior of a local const field?  Then we could get rid of final and have only two keywords.  Or am I missing something?  IMO, two keywords is way less confusing than three.
> 
> Another question.  Since invariant data should always be invariant, does it make sense to be able to cast non-invariant data to invariant?  The compiler will think that it is invariant when it isn't.
> 
> -Craig 
> 
> 

Craig, const and final have two very different roles. Const ensures that the value referenced/pointed to by the reference/pointer cannot be changed. In other words, if an object reference is bound to a const variable, then the object is immutable when referenced via that variable.

Final is different in that it prevents a variable from having another value bound to it. In other words, if you have a reference variable, once initialised, you cannot assign a new reference to the variable.

Examples:

SomeObject is a mutable class, IE it's value can be modified.

auto mutvar = new SomeObject ();
mutvar.changesomething() -- ok

const var = new SomeObject ();
var.changesomething() -- fails

Now for final:

final finvar = new SomeObject (); -- ok
finvar.changesomething() -- ok
...
finvar = new SomeObject (); -- fails

Regards,

Myron.

Myron Alexander wrote:
> Craig Black wrote:
>> OK, I think I'm starting to grasp the subtle differences between const, final, and invariant.  It seems to me that to have three keywords is unnecessary.  Perhaps const and final could be merged into one?
>>
>> From my understanding, the only difference between const and final is that local final fields can be initialized in a constructor, right?  Couldn't that just be the default behavior of a local const field?  Then we could get rid of final and have only two keywords.  Or am I missing something?  IMO, two keywords is way less confusing than three.
>>
>> Another question.  Since invariant data should always be invariant, does it make sense to be able to cast non-invariant data to invariant?  The compiler will think that it is invariant when it isn't.
>>
>> -Craig
>>
> 
> Craig, const and final have two very different roles. Const ensures that the value referenced/pointed to by the reference/pointer cannot be changed. In other words, if an object reference is bound to a const variable, then the object is immutable when referenced via that variable.
> 
> Final is different in that it prevents a variable from having another value bound to it. In other words, if you have a reference variable, once initialised, you cannot assign a new reference to the variable.
> 
> Examples:
> 
> SomeObject is a mutable class, IE it's value can be modified.
> 
> auto mutvar = new SomeObject ();
> mutvar.changesomething() -- ok
> 
> const var = new SomeObject ();
> var.changesomething() -- fails
> 
> Now for final:
> 
> final finvar = new SomeObject (); -- ok
> finvar.changesomething() -- ok
> ...
> finvar = new SomeObject (); -- fails
> 
> Regards,
> 
> Myron.

Oops, forgot to add this:

> const var = new SomeObject ();
> var.changesomething() -- fails

var = new SomeObject (); -- ok

Regards,

Myron.

OK, didn't catch that.  Thanks.

"Myron Alexander" <someone@somewhere.com> wrote in message news:f569rr$22n9$1@digitalmars.com...
> Craig Black wrote:
>> OK, I think I'm starting to grasp the subtle differences between const, final, and invariant.  It seems to me that to have three keywords is unnecessary.  Perhaps const and final could be merged into one?
>>
>> From my understanding, the only difference between const and final is that local final fields can be initialized in a constructor, right? Couldn't that just be the default behavior of a local const field?  Then we could get rid of final and have only two keywords.  Or am I missing something?  IMO, two keywords is way less confusing than three.
>>
>> Another question.  Since invariant data should always be invariant, does it make sense to be able to cast non-invariant data to invariant?  The compiler will think that it is invariant when it isn't.
>>
>> -Craig
>
> Craig, const and final have two very different roles. Const ensures that the value referenced/pointed to by the reference/pointer cannot be changed. In other words, if an object reference is bound to a const variable, then the object is immutable when referenced via that variable.
>
> Final is different in that it prevents a variable from having another value bound to it. In other words, if you have a reference variable, once initialised, you cannot assign a new reference to the variable.
>
> Examples:
>
> SomeObject is a mutable class, IE it's value can be modified.
>
> auto mutvar = new SomeObject ();
> mutvar.changesomething() -- ok
>
> const var = new SomeObject ();
> var.changesomething() -- fails
>
> Now for final:
>
> final finvar = new SomeObject (); -- ok
> finvar.changesomething() -- ok
> ...
> finvar = new SomeObject (); -- fails
>
> Regards,
>
> Myron.

Myron Alexander wrote:
> const var = new SomeObject ();

The above line will fail because const declarations can only be initialized with something that can be evaluated at compile time. The example should be:

	const(SomeObject) var = new SomeObject();

> var.changesomething() -- fails

Walter Bright wrote:
> Myron Alexander wrote:
>> const var = new SomeObject ();
> 
> The above line will fail because const declarations can only be initialized with something that can be evaluated at compile time. The example should be:
> 
>     const(SomeObject) var = new SomeObject();
> 
>> var.changesomething() -- fails

Thanks for the correction.

Regards,

Myron.

Walter Bright wrote:
> Myron Alexander wrote:
>> const var = new SomeObject ();
> 
> The above line will fail because const declarations can only be initialized with something that can be evaluated at compile time. The example should be:
> 
>     const(SomeObject) var = new SomeObject();

Is there any way to use type deduction to avoid having
to repeat the SomeObject part of this?

-- James

James Dennett wrote:
> Walter Bright wrote:
>> Myron Alexander wrote:
>>> const var = new SomeObject ();
>> The above line will fail because const declarations can only be initialized with something that can be evaluated at compile time. The example should be:
>>
>>     const(SomeObject) var = new SomeObject();
> 
> Is there any way to use type deduction to avoid having
> to repeat the SomeObject part of this?
> 
> -- James

auto var = cast(const) new SomeObject();

It's one character shorter :P

	-- Daniel

James Dennett wrote:
> Walter Bright wrote:
>> Myron Alexander wrote:
>>> const var = new SomeObject ();
>> The above line will fail because const declarations can only be
>> initialized with something that can be evaluated at compile time. The
>> example should be:
>>
>>     const(SomeObject) var = new SomeObject();
> 
> Is there any way to use type deduction to avoid having
> to repeat the SomeObject part of this?
> 
> -- James
It seems like something like that should be plausible. How about:

    const() var = new SomeObject(); // --> const(SomeObject) var;
    const var2 = new SomeObject(); // --> const SomeObject var;



  -- Reiner