www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const system names

reply bearophile <bearophileHUGS lycos.com> writes:
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).

This is not compatible with C, but if you try to port C code to D2 with this
const regime, the code can't assign new values to variables that lack the "var"
attribute, it produce compile errors, so such porting doesn't look bug-prone to
me.

So this code:
  immutable int x1 = 1;
  const int x2 = 2;
  int x3 = 3;
  enum int x4 = 4;

Becomes:
  int x1 = 1;
  valview int x2 = 2;
  var int x3 = 3;
  int x4 = 4;

With such immutability by default, thread-local by default, notnull references
by default, the language starts to look quite different from C++ ;-)

Bye,
bearophile
Feb 15 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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. Regarding names; the fact that we currently have to write "enum x = 123;", which to me reads like "enumerate this single constant for me please, and BTW when I say 'enumerate' I really mean that I want to assign 123 to it", is one of the last remaining things in D that really bugs me. I have suggested the following scheme at least twice: const: manifest constants, no storage (like const in D1, enum in D2) readonly: a read-only view of mutable data (like const in D2) immutable: immutable data (like now) (Both times Yigal Chiprun was the first to reply, saying he thinks there should only be const and non-const, and the rest is up to the compiler. I'd almost be disappointed if that doesn't happen now. :) I still disagree, though.) -Lars
Feb 16 2010
next sibling parent reply retard <re tard.com.invalid> writes:
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; }
Feb 16 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
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; }

in that case it's kind of meaningless. Also, requiring immutability for the input is not what you usually want.
Feb 16 2010
prev sibling parent retard <re tard.com.invalid> writes:
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; }

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.
Feb 16 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> 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 like the idea, and would like to try D with a system like this. However, I disagree with the names. See, with my beautiful collection of bike shed colors, I would keep 'const' for 'const' (for backward- compatibility and familiarity, and I think valview is an abomination), and use 'alias' instead of 'enum' (which I still consider the most glaring error in the history of D). For transition purposes, 'immutable' could of course be a no-op. -- Simen
Feb 16 2010