Const system names

[retard]

Tue, 16 Feb 2010 17:05:23 +0100, Pelle Månsson wrote:

> On 02/16/2010 04:27 PM, retard wrote:
>> Tue, 16 Feb 2010 10:28:28 +0100, Lars T. Kyllingstad wrote:
>>
>>> bearophile wrote:
>>>> Alternative names for the transitive const regime of D2, the main
>>>> difference is that now immutable values are the default:
>>>>
>>>> - "immutable" ==>  (nothing, it's the default). - "const" ==> 
>>>> "valview" (a local immutable value view of something). - mutable
>>>> variable ==> "var"
>>>> - "enum" ==>  "const" (or maybe it can be removed, so it becomes
>>>> immutable, that is no annotation. The link-time optimization of LDC
>>>> is able to remove unused values from the binary. Ten years from now
>>>> all D compilers can be able to do this).
>>>>
>>>> [...]
>>>
>>> I don't agree that immutable should be the the default.  The default
>>> should be the most common case, which is mutable.
>>
>> BTW, have you got some numbers from concrete examples such as real
>> world programming projects. Note that many variables are not immutable
>> in real projects, but they also could be:
>>
>> Integer boxedIntegerSum(Integer a, Integer b) {
>>    Integer c = new Integer();
>>    c.assign(a.getValue() + b.getValue()); return c;
>> }
>>
>> Here you have three immutable variables a, b, and c. In reality they
>> all could as well be constant references, a and b also could be
>> immutable views:
>>
>> Integer boxedIntegerSum(immutable Integer a, immutable Integer b) {
>>    const Integer c = new Integer();
>>    c.assign(a.getValue() + b.getValue()); return c;
>> }
> Only if you're assuming that the assign() doesn't alter the integer, but
> in that case it's kind of meaningless.

> Also, requiring immutability for
> the input is not what you usually want.

Yea, I don't really remember how the d2 const/immutability system works 
so that's why I said immutable view and not plain immutable. Basically a 
function usually shouldn't have an 'and' in its description so modifying 
the inputs is often not recommended. Anyways in other cases the 
references should be at least const if the objects aren't. This way the 
common noob bug:

class foo {
  int a;
  this(int a) { a = a; }
}

can be avoided.