Why can't we define re-assignable const reference variable?

Robert Fraser fraserofthenight at gmail.coim
Sun Feb 17 05:36:15 PST 2008


Janice Caron Wrote:

> On 16/02/2008, Christopher Wright <dhasenan at gmail.com> wrote:
> > generic programming != type system
> 
> I can't argue with that! :-) Perhaps I should have said, it will break
> /either/ generic programming /or/ the type system. I suppose I was
> thinking that if you have new syntax, and you want to keep generic
> programming, then somehow you must force the new syntax to work for
> all types, and /that/ breaks the type system, but I guess I was
> probably thinking too far ahead there. :-)

D already has types that break generic programming. Static arrays, anyone?

One thing I was arguing for before the const system was implemented as it is now is for structs to act as similarly to classes as possible, only stack allocated. So while there was still a question of "head-const" and "tail-const", a "tail-const" struct would be the same as a "tail-const" class: that is, the reference would be rebindable, but members would not be. For example:

struct S { int x; }
class C  { int x; }

tailconst(S) s1;
tailconst(S) s2;

tailconst(C) c1 = new C();
tailconst(C) c2 = new C();

s1 = s2; // Okay
c1 = c2; // Okay
s1.x = 5; // Not okay
c1.x = 5; // Not okay

When I proposed this, NOBODY agreed with me (that is, everybody who responded wanted structs/classes to act differently for generic programming purposes).



More information about the Digitalmars-d mailing list