On Tue, 19 Jun 2007 00:55:21 +0300, Walter Bright <newshound1@digitalmars.com> 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

Now I'm a bit confused... Oh, now I get it. (I hope.)
There can be constant views and constant, or literal, data. And literals are, of course, compile time, er, constants.

Sometimes 'const' means immutable and sometimes it means literal, compile time value...


At first I read:

  const foo = new Bar;  //or const Bar foo = new Bar;

as:

  final const(Bar) foo = new Bar;

That is, a final, constant view to an object (or, immutable reference (final variable) + immutable object (constant view).) Not as a constant view to a constant/literal object.

With value types, final will be sufficient:

  final int v = foo();

But with reference types, one must write "final const(...)"...? Uh, that's verbose. :/


With functions, you can write:

  void f(const Bar foo);

  f(new Bar);  //no need for compile time constant/literal

Ok, inside the function, 'foo' will be treated as a constant/literal, so it makes sense, kind of.
(And const-by-default function paramters are too inconsistent?... ;) )



Maybe I should also wonder this: how one can create an object that will be treated as invariant/constant?

  invariant Bar foo = new Bar;  //global variable; currently inline initialization not allowed though

  void f() {
    invariant obj = foo;
  }

Surely the object pointed by 'foo' will be invariant during the execution of the program.

Kristian Kilpi wrote:
> On Tue, 19 Jun 2007 00:55:21 +0300, Walter Bright <newshound1@digitalmars.com> 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
> 
> Now I'm a bit confused... Oh, now I get it. (I hope.)
> There can be constant views and constant, or literal, data. And literals are, of course, compile time, er, constants.
> 
> Sometimes 'const' means immutable and sometimes it means literal, compile time value...
> 
> 
> At first I read:
> 
>   const foo = new Bar;  //or const Bar foo = new Bar;
> 
> as:
> 
>   final const(Bar) foo = new Bar;
> 
> That is, a final, constant view to an object (or, immutable reference (final variable) + immutable object (constant view).) Not as a constant view to a constant/literal object.
> 
> With value types, final will be sufficient:
> 
>   final int v = foo();
> 
> But with reference types, one must write "final const(...)"...? Uh, that's verbose. :/
> 
> 
> With functions, you can write:
> 
>   void f(const Bar foo);
> 
>   f(new Bar);  //no need for compile time constant/literal
> 
> Ok, inside the function, 'foo' will be treated as a constant/literal, so it makes sense, kind of.
> (And const-by-default function paramters are too inconsistent?... ;) )
> 
> 
> 
> Maybe I should also wonder this: how one can create an object that will be treated as invariant/constant?
> 
>   invariant Bar foo = new Bar;  //global variable; currently inline initialization not allowed though
> 
>   void f() {
>     invariant obj = foo;
>   }
> 
> Surely the object pointed by 'foo' will be invariant during the execution of the program.

It has already been mentioned that you can 'cast(const) new Foo' to make it be treated as such (since you've cast it immediately upon creation, so there's no mutable referance available).  Likewise with 'cast(invariant)'.  I'm thinking these might be relatively common operations for some, so maybe it would be wise/better/convenient to allow these keywords between 'new' and 'Foo' like 'new const Foo'.  If nothing else, it reads well to me, and provides type deduction.

auto  mvar = new           Foo ; //                 Foo  mvar ;
auto  cvar = new const     Foo ; //       const    (Foo) cvar ;
auto  ivar = new invariant Foo ; //       invariant(Foo) ivar ;
final fvar = new const     Foo ; // final const    (Foo) fvar ;

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> Kristian Kilpi wrote:
>> On Tue, 19 Jun 2007 00:55:21 +0300, Walter Bright <newshound1@digitalmars.com> 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
>>
>> Now I'm a bit confused... Oh, now I get it. (I hope.)
>> There can be constant views and constant, or literal, data. And literals are, of course, compile time, er, constants.
>>
>> Sometimes 'const' means immutable and sometimes it means literal, compile time value...
>>
>>
>> At first I read:
>>
>>   const foo = new Bar;  //or const Bar foo = new Bar;
>>
>> as:
>>
>>   final const(Bar) foo = new Bar;
>>
>> That is, a final, constant view to an object (or, immutable reference (final variable) + immutable object (constant view).) Not as a constant view to a constant/literal object.
>>
>> With value types, final will be sufficient:
>>
>>   final int v = foo();
>>
>> But with reference types, one must write "final const(...)"...? Uh, that's verbose. :/
>>
>>
>> With functions, you can write:
>>
>>   void f(const Bar foo);
>>
>>   f(new Bar);  //no need for compile time constant/literal
>>
>> Ok, inside the function, 'foo' will be treated as a constant/literal, so it makes sense, kind of.
>> (And const-by-default function paramters are too inconsistent?... ;) )
>>
>>
>>
>> Maybe I should also wonder this: how one can create an object that will be treated as invariant/constant?
>>
>>   invariant Bar foo = new Bar;  //global variable; currently inline initialization not allowed though
>>
>>   void f() {
>>     invariant obj = foo;
>>   }
>>
>> Surely the object pointed by 'foo' will be invariant during the execution of the program.
> 
> It has already been mentioned that you can 'cast(const) new Foo' to make it be treated as such (since you've cast it immediately upon creation, so there's no mutable referance available).  Likewise with 'cast(invariant)'.  I'm thinking these might be relatively common operations for some, so maybe it would be wise/better/convenient to allow these keywords between 'new' and 'Foo' like 'new const Foo'.  If nothing else, it reads well to me, and provides type deduction.
> 
> auto  mvar = new           Foo ; //                 Foo  mvar ;
> auto  cvar = new const     Foo ; //       const    (Foo) cvar ;
> auto  ivar = new invariant Foo ; //       invariant(Foo) ivar ;
> final fvar = new const     Foo ; // final const    (Foo) fvar ;
> 
> -- Chris Nicholson-Sauls

I would prefer something like that.  I still can't get over the feeling anytime I type or see "cast" that I'm doing something dangerous and subversive.  Although I know things like cast(ClassType) in D are actually safe casts... but even using safe casts like that is kind of a warning sign in OO code that you may have factored your interface incorrectly.

--bb

Bill Baxter Wrote:
> I would prefer something like that.  I still can't get over the feeling anytime I type or see "cast" that I'm doing something dangerous and subversive.  Although I know things like cast(ClassType) in D are actually safe casts... but even using safe casts like that is kind of a warning sign in OO code that you may have factored your interface incorrectly.
> 
> --bb

I wouldn't say cast(const) was a OO problem - and the syntax is definitely improved over C++'s const_cast<ClassName>(), but it does point to 'C++ like' problems with how const works. I always thought the theory was that const_cast was there for dealing with legacy API's, not to overcome shortcomings in the language :)

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 
> 
> 

I hate to be the meanie here but this newsgroup this is the sort of message I think belongs in digitalmars.D.

-Joel