Andrei Alexandrescu (See Website For Email) Wrote:
> Derek Parnell wrote:
> > On Fri, 16 Mar 2007 02:25:24 -0700, Andrei Alexandrescu (See Website For
> > Email) wrote:
> > 

<snip>

> 
> I was just trying to minimize the amount of broken code. Also, we

<snip>

> 
> An intuition that I see reasonable is that const by default engulfs everything to its right:
> 
> const char[] str = "Hi!"; // same as const(char[] str) = "Hi!";
> 
> When it engulfs the symbol, it makes it immutable, hence final. So by putting the parens you limit const's power.
> 
> But I'd be glad to drop this exception. I'm not sure what Walter and people who'll have to modify their code would say though.
> 

<snip>

> > 
> > The EXCEPTION (alarms still ringing)  seems to be saying that 'const char[] X' means that X.ptr, X.length and the data in X's RAM cannot be changed.
> 
> I am hearing it. :o)
> 

Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I really have to agree with Derek -- the exceptions need to be dropped <g>

Based on past NG discussions on 'const', I believe it is so important to get this right the first time that the exceptions need to be removed in favor of the most intuitive and consistent syntax.

Since the current "const char[] str = 'XYZ'"; semantics would prevent both str or its elements from being modified, we could make a reasonable assumption that code already properly tested and running (and just recompiled with a new compiler) would not break anyhow, correct?

Thanks,

- Dave

Dave wrote:
> Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I really have to agree with Derek -- the exceptions need to be dropped <g>
> 
> Based on past NG discussions on 'const', I believe it is so important to get this right the first time that the exceptions need to be removed in favor of the most intuitive and consistent syntax.
> 
> Since the current "const char[] str = 'XYZ'"; semantics would prevent both str or its elements from being modified, we could make a reasonable assumption that code already properly tested and running (and just recompiled with a new compiler) would not break anyhow, correct?


I think this is a valid point.

Andrei

Daniel Keep wrote:
> 
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Bruno has answered your specific questions, so I'll take a more
>>> general tack.
>>>
>>> A symbol is a name to which is 'bound' a value.
>>>
>>> static int x = 3;
>>>
>>> '3' is the value.
>>> 'int' is the type.
>>> 'x' is the symbol.
>>> 'static' is the storage class.
>>>
>>> Here, we bind a new value to the symbol x:
>>>     x = 4;
>>>
>>> A storage class originally meant where the symbol is stored, such as
>>> in the data segment, on the stack, in a register, or in ROM. It's been
>>> generalized a bit since then. The main way to tell a storage class
>>> apart is that:
>>> 1) a storage class applies to the symbol
>>> 2) a type is independent of storage class, i.e. you cannot create a
>>> type that is "pointer to static" or "array of extern". Storage classes
>>> do not affect overloading, nor type deduction.
>>>
>>> 'invariant' and 'const' are type modifiers (aka type constructors),
>>> which mean when they are applied to a type, a new type is created that
>>> is a combination.
>>>
>>> 'invariant' is a guarantee that any data of that type will never
>>> change. 'const' is a guarantee that any data of that type will never
>>> be modified through a reference to that type (though other, non-const
>>> references to that type can modify the data).
>> So 'final' will be a storage class and not a type modifier? That's one
>> of the questions I still have with regards to your design, because I'm
>> not seeing how 'final' can also not-be a type modifier. In particular,
>> again, what is
>>   typeof(&foo)
>> where foo is:
>>   final Foo foo;
>> ?
> 
> I imagine it would be (invariant Foo*): an invariant pointer to a
> reference to a Foo.  Since *no one* is ever allowed to change final
> storage, then a pointer to it must be invariant.
> 
> 	-- Daniel
> 

No, that's not possible. It was mentioned before in another post:
news://news.digitalmars.com:119/etv81l$m94$1@digitalmars.com
Since invariant is (planned to be) transitive, then that typeof can't be (invariant Foo*), since the contents of foo can change (altough the immediate-value won't).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Daniel Keep wrote:
>>
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>> Bruno has answered your specific questions, so I'll take a more general tack.
>>>>
>>>> A symbol is a name to which is 'bound' a value.
>>>>
>>>> static int x = 3;
>>>>
>>>> '3' is the value.
>>>> 'int' is the type.
>>>> 'x' is the symbol.
>>>> 'static' is the storage class.
>>>>
>>>> Here, we bind a new value to the symbol x:
>>>>     x = 4;
>>>>
>>>> A storage class originally meant where the symbol is stored, such as
>>>> in the data segment, on the stack, in a register, or in ROM. It's been
>>>> generalized a bit since then. The main way to tell a storage class
>>>> apart is that:
>>>> 1) a storage class applies to the symbol
>>>> 2) a type is independent of storage class, i.e. you cannot create a
>>>> type that is "pointer to static" or "array of extern". Storage classes
>>>> do not affect overloading, nor type deduction.
>>>>
>>>> 'invariant' and 'const' are type modifiers (aka type constructors), which mean when they are applied to a type, a new type is created that is a combination.
>>>>
>>>> 'invariant' is a guarantee that any data of that type will never change. 'const' is a guarantee that any data of that type will never be modified through a reference to that type (though other, non-const references to that type can modify the data).
>>> So 'final' will be a storage class and not a type modifier? That's one
>>> of the questions I still have with regards to your design, because I'm
>>> not seeing how 'final' can also not-be a type modifier. In particular,
>>> again, what is
>>>   typeof(&foo)
>>> where foo is:
>>>   final Foo foo;
>>> ?
>>
>> I imagine it would be (invariant Foo*): an invariant pointer to a reference to a Foo.  Since *no one* is ever allowed to change final storage, then a pointer to it must be invariant.
>>
>>     -- Daniel
>>
> 
> No, that's not possible. It was mentioned before in another post:
> news://news.digitalmars.com:119/etv81l$m94$1@digitalmars.com
> Since invariant is (planned to be) transitive, then that typeof can't be
> (invariant Foo*), since the contents of foo can change (altough the
> immediate-value won't).

You are, of course, right.  Damnit.  Just when I thought I understood all this... :(

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Andrei Alexandrescu (See Website For Email) Wrote:
> Dave wrote:
> > Ok, this maybe somewhat selfish since I haven't used D's 'const' much, but I really have to agree with Derek -- the exceptions need to be dropped <g>
> > 
> > Based on past NG discussions on 'const', I believe it is so important to get this right the first time that the exceptions need to be removed in favor of the most intuitive and consistent syntax.
> > 
> > Since the current "const char[] str = 'XYZ'"; semantics would prevent both str or its elements from being modified, we could make a reasonable assumption that code already properly tested and running (and just recompiled with a new compiler) would not break anyhow, correct?
> 
> 
> I think this is a valid point.
> 

Maybe a few more justifications for getting rid of the exceptions:

- It's more effort and complexity to add the exceptions to the compiler, docs., etc...
- IIUC, a search-and-replace operation from 'const' to 'final' or 'final const' could 'fix' most current source code.
- It would be better to have to add the exceptions later (based on programmer feedback) than to add them and then have to remove them.
- The other case you mentioned (i.e.: const real MyPI = 3.14159;) should not be a problem with most currently correct D code (like const char[] str = "XYZ"; above). Could this case (a value type constant) warrant an error with the new compiler?

Thanks,

- Dave