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