www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - enum - auto

reply so <so so.so> writes:
Auto and immutable.
Can we please put an end to this issue?
I remember a few discussions, never a complete answer, but many  
contradicting answers.

1. Is enum (its current usage) still a temporary hack to a technical  
limitation on immutable?
2. Can or Will immutable replace enum? (Not that i want such a change)
3. Isn't enum a higher order immutable, which is guarantied to be a  
compile time constant?

--

Another issue, auto.
I was thinking that it works like C++0x auto.
Now i realize they are not that alike. Can anyone show me the D equivalent  
of the code below?

struct test {
     int a;
};

void main() {
     test tmp;
     auto& a = tmp.a;
}

Thanks.
Nov 14 2011
next sibling parent so <so so.so> writes:
On Mon, 14 Nov 2011 12:14:02 +0200, so <so so.so> wrote:


 Auto and immutable.


Uhm sorry, that should be "Enum and immutable"
Nov 14 2011
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
You obviously did not pay attention to the recent thread about enums. You 
participated in it as well... Enums are different things from immutables. 
End of story.
Nov 14 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2011 11:21 AM, Dejan Lekic wrote:

 You obviously did not pay attention to the recent thread about enums. You
 participated in it as well... Enums are different things from immutables.
 End of story.


I think discussing the matter does not hurt.
Nov 14 2011
prev sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Mon, 14 Nov 2011 11:14:02 +0100, so <so so.so> wrote:


 Auto and immutable.
 Can we please put an end to this issue?
 I remember a few discussions, never a complete answer, but many  
 contradicting answers.

 1. Is enum (its current usage) still a temporary hack to a technical  
 limitation on immutable?


Yes and no. Enum was chosen due to limitations in the linker, which made it
impossible to weed out unused constants. The linker is free to remove  
unused
constants, but DMD's linker will not do so. Perhaps in the future, it will.



 2. Can or Will immutable replace enum? (Not that i want such a change)


Enum is now an established part of the language, and even if such were  
possible,
it is not going to happen.



 3. Isn't enum a higher order immutable, which is guarantied to be a  
 compile time constant?


One could think of it as such, yes. That hardly gives much advantage over
immutable, though. The main feature of enum is that it takes up no space  
in the
result binary.



 Another issue, auto.
 I was thinking that it works like C++0x auto.
 Now i realize they are not that alike. Can anyone show me the D  
 equivalent of the code below?

 struct test {
      int a;
 };

 void main() {
      test tmp;
      auto& a = tmp.a;
 }


That would be a reference to an int, right? No such thing in D, except for
function parameters. What you would do instead is get a pointer:

struct test {
     int a;
}

void main() {
     test tmp;
     auto a = &tmp.a;
}
Nov 14 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2011 11:33 AM, Simen Kjærås wrote:

 On Mon, 14 Nov 2011 11:14:02 +0100, so <so so.so> wrote:


 Auto and immutable.
 Can we please put an end to this issue?
 I remember a few discussions, never a complete answer, but many
 contradicting answers.

 1. Is enum (its current usage) still a temporary hack to a technical
 limitation on immutable?


 Yes and no. Enum was chosen due to limitations in the linker, which made it
 impossible to weed out unused constants. The linker is free to remove
 unused
 constants, but DMD's linker will not do so. Perhaps in the future, it will.


I guess this is not a problem on Linux. I still find the enum storage 
class to add significant value to the language.


 2. Can or Will immutable replace enum? (Not that i want such a change)


 Enum is now an established part of the language, and even if such were
 possible,
 it is not going to happen.



 3. Isn't enum a higher order immutable, which is guarantied to be a
 compile time constant?




static immutable variables are also guaranteed to be compile time 
constants. enum and immutable are not too tightly related.



 One could think of it as such, yes. That hardly gives much advantage over
 immutable, though. The main feature of enum is that it takes up no space
 in the
 result binary.


There are other important differences. enums are always treated like 
values, even if their type has reference semantics. (basically, that 
means their value is just copied each time they are referenced.) This is 
necessary to guarantee their constancy without restricting operations on 
their values.

Furthermore writing

enum x = foo(); // CTFE'd/compile time constant

is much more convenient than having to write

static immutable x = foo(); // CTFE'd/compile time constant

Even when ignoring the fact that the second one infects x with the 
'immutable' type qualifier.
Nov 14 2011
prev sibling parent so <so so.so> writes:
Thanks Simen!

On Mon, 14 Nov 2011 12:33:26 +0200, Simen Kj=C3=A6r=C3=A5s <simen.kjaras=
 gmail.com>  =

wrote:


 Another issue, auto.
 I was thinking that it works like C++0x auto.
 Now i realize they are not that alike. Can anyone show me the D  =





 equivalent of the code below?

 struct test {
      int a;
 };

 void main() {
      test tmp;
      auto& a =3D tmp.a;
 }


 That would be a reference to an int, right? No such thing in D, except=


  =


 for
 function parameters. What you would do instead is get a pointer:

 struct test {
      int a;
 }

 void main() {
      test tmp;
      auto a =3D &tmp.a;
 }


I was at least expecting "[const ref/ref] auto a =3D tmp.a;" would work.=

I don't see why it won't (anyone knows if it was by design or just the  =

matter of implementation?), i think it is quite important.
Nov 14 2011