Don Clugston wrote:
> Bruno Medeiros wrote:
> 
>> D's const has two meanings. The usual meaning is from the form:
>>   const int var = <some constant initializer>;
>> and it means that the variable is a compile-time constant and no storage is allocated for it, instead the value is substituted whenever the var is used (like #define, but safer).
>>
>> The second meaning is from the form:
>>   const int var; // no initializer
>> and means that the var must be initialized once in a constructor, and then it becomes non-recursively immutable (meaning you can't change the value of the var, but you can change referenced values). The var has storage and as such is an lvalue.
>> This is basically the same as final in other languages (Java, C#), and I wonder why it isn't in D as well(?). Walter said he didn't want a const keyword overloaded with many different meanings.
> 
> 
> I agree. I think it's a mistake to have a 'const' that isn't actually const! 'final' seems far more appropriate.
> 

We do have a 'final' keyword in D already.  Applied to a class decleration it describes a class which may not be inherited from.  Applied to class member function (method) declerations, it means a member which may not be overriden.  So far as I am aware, it is meaningless anywhere else.  Since 'final' in D currently means, in over-generalized terms, "this cannot be replaced," I don't think it would be much of a stretch to use 'final' to mean what 'const' currently does.

-- Chris Nicholson-Sauls

kris wrote:
> 
> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind?
> 
> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug*
> 
> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D
> 
> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p
> 
> 
> 
Crusade? LoL.
I can barely work on my own projects with my daughters(1 and 3 yrs).

My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far).

1. Tiny multithreaded advantages.
2. Limited optimization benefits.
3. Some memory optimizations for structs(call by reference).

Changing the whole language for the above just does seem like good investment vs return.

Cheers
-David

David Medlock wrote:

> kris wrote:
>> 
>> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind?
>> 
>> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug*
>> 
>> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D
>> 
>> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p
>> 
>> 
>> 
> Crusade? LoL.
> I can barely work on my own projects with my daughters(1 and 3 yrs).

What you mean? They can't code yet? ;)

> 
> My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far).
> 
> 1. Tiny multithreaded advantages.
> 2. Limited optimization benefits.
> 3. Some memory optimizations for structs(call by reference).
> 
> Changing the whole language for the above just does seem like good investment vs return.
> 
> Cheers
> -David

I believe you downplay those points too much, particularly the multithreaded advantages. You did also forget the most important point, IMO:

If you as a library writer or application writer care about the integrity of your data (very often you have to, as this might be necessary to guarantee correct operation), then you need to make sure that users of the library, or other threads don't modify the data in ways that breaks this integrity. Since D actually aims to make it easier to create safer software, strong immutability enforcement, however it is implemented (the logical const from C++ do seem like a somewhat dead end), is a must.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>>
>>> There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue).
>>
>> Ever tried taking the address of a const string?  That you can't take the address of other const types is simply a result of optimization.
>>
> 
> I tried it now, and the const string also can't be taken an address from:
> 
>   const char[] str = "ABC";
> 
>   void func()
>   {
>     *(&str) = "123"; // : "ABC" is not an lvalue
>   }

That's interesting.  I would have expected all strings to live in a static data segment.  And in fact they seem to, though initialization seems to happen in a slightly weird manner:

    const char[] str = "ABC";

    void main()
    {
        printf( "%.*s\n", str );
    }

generates:

    _DATA   segment
            db      041h,042h,043h,000h,000h,000h,000h,000h
    _D4test3strAa:
            db      003h,000h,000h,000h
            dd      offset FLAT:_DATA
            db      041h,042h,043h,000h,000h,000h,000h,000h
            db      003h,000h,000h,000h
            dd      offset FLAT:_D4test3strAa[8]
            db      025h,02eh,02ah,073h,00ah,000h
    _DATA   ends
    CONST   segment
    CONST   ends
    _BSS    segment
    _BSS    ends
    __Dmain comdat
            assume  CS:__Dmain
    L0:             push    dword ptr _D4test3strAa[014h]
                    push    dword ptr _D4test3strAa[010h]
                    push    offset FLAT:_D4test3strAa[018h]
                    call    near ptr _printf
                    xor     EAX,EAX
                    add     ESP,0Ch
                    ret
    __Dmain ends

Notice that "041h,042h,043h" exists both by itself as a literal and within the static initializer for 'str'.  Notice also that 'str' does indeed live within a static data segment.  I'm not entirely certain why the literal isn't optimized away, however, as it's only ever used for initializing 'str'.


Sean

David Medlock wrote:
> kris wrote:
>>
>> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind?
>>
>> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug*
>>
>> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D
>>
>> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p
>>
>>
>>
> Crusade? LoL.
> I can barely work on my own projects with my daughters(1 and 3 yrs).
> 
> My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far).
> 
> 1. Tiny multithreaded advantages.
> 2. Limited optimization benefits.
> 3. Some memory optimizations for structs(call by reference).
> 
> Changing the whole language for the above just does seem like good investment vs return.
> 
> Cheers
> -David

I'm assuming you meant "just doesn't seem like" up there.

The form exposed so far isn't all, const isn't just for multithreading apps: An immutability mechanism is great for ownership management, better than CoW because, like Kris said, the program becomes more expressive and there is more that the compiler can check and enforce (and it prevents redundant duping/cloning).


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

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> Bruno Medeiros wrote:
>>>>
>>>> There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue).
>>>
>>> Ever tried taking the address of a const string?  That you can't take the address of other const types is simply a result of optimization.
>>>
>>
>> I tried it now, and the const string also can't be taken an address from:
>>
>>   const char[] str = "ABC";
>>
>>   void func()
>>   {
>>     *(&str) = "123"; // : "ABC" is not an lvalue
>>   }
> 
> That's interesting.  I would have expected all strings to live in a static data segment.  And in fact they seem to, though initialization seems to happen in a slightly weird manner:
> 

Yes, they have to live in a static data segment. But does that change anything? The value of "ABC" is already the address of the string, thus &"ABC" is not valid. (akin to &(&somevar) )



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