Immutable objects and constructor ?

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri May 20 14:15:25 PDT 2016


On Friday, May 20, 2016 20:30:22 chmike via Digitalmars-d-learn wrote:
> On Friday, 20 May 2016 at 17:35:01 UTC, Kagamin wrote:
> > On Friday, 20 May 2016 at 16:09:54 UTC, chmike wrote:
> >> But I now met another error in my main(). I can't assign the
> >> immutable object to a mutable reference.
> >>
> >> Info x1 = MyInfos.one;
> >>
> >> Is it possible to define a mutable reference to an immutable
> >> instance ?
> >
> > Sort of possible with a library solution:
> >
> > import std.typecons;
> > auto x1 = rebindable(MyInfos.one);
>
> I'm a bit surprized that the language doesn't support this. We
> have immutable strings that can be assigned to different
> variables. Why couldn't we do the same with objects ?

It has to do with the fact that the type system does not differentiate
between classes and references to class objects. When you type

Object o;

that's a reference to a class, not actually a class object, and the same
goes for every use of a class.  So, while you can have

const(int)* ptr;

and the compiler understands that, the compiler doesn't have an
understanding of the separation of an Object and a reference to an Object,
so not only is there no way to represent it syntactically, the compiler
can't currently represent it semantically either. This is at least partially
a result of making it so that classes inherently live on the heap.

It's certainly possible to change it so that we have a way to have
tail-const references to classes and so that Rebindable is then unnecessary,
but Walter and Andrei don't think that it's worth it, so it hasn't happened.
And while Rebindable is kind of ugly, it works just fine. So, the lack of
tail-const for classes in the language hasn't really been a blocker for
anything, just kind of ugly.

> This rebindable is not user friendly.
> I really wish the user could write this
>
> Info x = MyInfos.one;
>
> I may achieve this if Info is defined as a struct with a single
> member defined as rebindable.

Well, as long as you're dealing with local variables, you can use auto
rather than typing the type explicitly, and then you don't need to
explicitly use Rebindable, though you generally would for function
parameters and member variables. But while typing Rebindable is a bit ugly,
it's basically just a bit more verbose than what you'd get if it were built
in. Right now you have

Rebindable!Info info;

whereas if it were buit in, you'd probably get something like

tail_const(Info) info;

or I think that someone suggested something like

const(ref) Info info;

And both of those are about as verbose as Rebindable is. So, they wouldn't
save us much. So, sure, it would be nice if tail-const classes were built
into the language, but we don't seem to be losing much by not having them.
If someone could come up with why the lack of tail-const classes were a
major roadblocker somehow, then maybe Walter could be convinced to alter the
language, but you'd need a very solid reason as to why Rebindable doesn't
cut it, and thinking that it's a bit ugly isn't going to be enough.

- Jonathan M Davis



More information about the Digitalmars-d-learn mailing list