const and immutable objects

[Jeremie Pelletier]

Andrei Alexandrescu Wrote:

> Jeremie Pelletier wrote:
> > Graham St Jack Wrote:
> > 
> >> On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:
> >> 
> >> 
> >>> I agree that D lacks a mechanism to separate the object from it's
> >>>  reference. Maybe syntax like the following could be used to
> >>> apply the storage class to the object value, and not the
> >>> reference value:
> >>> 
> >>> class Foo; void bar(in Foo& foo) {}
> >>> 
> >>> It's quite ugly and C-like, but that's the first thing that came
> >>> to mind. The reference value is unique to the current method and
> >>> shouldn't share the same storage qualifiers as it's referenced
> >>> memory.
> >> I think the time for pining over this particular syntax feature of
> >> D is over - as nice as it would be to be able to fix the problem in
> >> the language, it would be too disruptive right now.
> > 
> > I think it would be better to fix it in D2  instead of patching a
> > language design flaw with a template. It wouldn't be the first time
> > D2 has changes that breaks existing code anyways (and the upcoming
> > T[new] will definitely break a lot of code, so does shared when it
> > works, etc), so it would be less disruptive to do it now than never
> > do it.
> 
> I agree with the sentiment. The issue is, however, that the change adds 
> a fair amount of complexity to the const system for an arguably 
> not-often-used need.
> 
> Andrei

Correct me if I'm wrong, but I don't see how complex that could be, since the compiler already needs to make the difference between the reference value and the object being referenced. The only thing that would need change is how that view is reflected in the syntax.

How about a .ref property?

class A {}
void foo(in A a) {

}