www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - readonly member (but assignable at constructor time)

reply Dr.No <jckj33 gmail.com> writes:

declaration or constructor time, like this:

class C
{
   readonly myClass mc;

   this()
   {
     mc = new myClass();
   }


   void doSomething()
   {
     mc = new myClass(); // wrong! result in compiler error, mc is 
readonly
   }
}

Does D have something like this natively or there's a way to do 
so with traits/CTFE at runtime?
Apr 26 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, April 27, 2018 02:59:16 Dr.No via Digitalmars-d-learn wrote:


 declaration or constructor time, like this:

 class C
 {
    readonly myClass mc;

    this()
    {
      mc = new myClass();
    }


    void doSomething()
    {
      mc = new myClass(); // wrong! result in compiler error, mc is
 readonly
    }
 }

 Does D have something like this natively or there's a way to do
 so with traits/CTFE at runtime?


D has const, though that has some pretty far-reaching repercussions, since
it means that the object can't be mutated at all, and the only member
functions that can be called on it are const or inout.

If you want to specifically make it so that the object is mutable but the
reference can't be assigned to, then it would have to be protected by a
wrapper struct that  disabled opAssign and then either used alias this or
opDispatch to forward calls to the class reference inside the struct. D's
const is transitive and does not have any form of head-const, so const can't
be used in a case like that.

- Jonathan M Davis
Apr 26 2018
prev sibling parent reply lempiji <lempiji gmail.com> writes:
On Friday, 27 April 2018 at 02:59:16 UTC, Dr.No wrote:


 declaration or constructor time, like this:

 class C
 {
   readonly myClass mc;

   this()
   {
     mc = new myClass();
   }


   void doSomething()
   {
     mc = new myClass(); // wrong! result in compiler error, mc 
 is readonly
   }
 }

 Does D have something like this natively or there's a way to do 
 so with traits/CTFE at runtime?


You can use std.experimenta.typecons.Final.
https://dlang.org/phobos/std_experimental_typecons.html#.Final
Apr 27 2018
parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 28 April 2018 at 04:56:26 UTC, lempiji wrote:

 On Friday, 27 April 2018 at 02:59:16 UTC, Dr.No wrote:


 declaration or constructor time, like this:

 class C
 {
   readonly myClass mc;

   this()
   {
     mc = new myClass();
   }


   void doSomething()
   {
     mc = new myClass(); // wrong! result in compiler error, mc 
 is readonly
   }
 }

 Does D have something like this natively or there's a way to 
 do so with traits/CTFE at runtime?


 You can use std.experimenta.typecons.Final.
 https://dlang.org/phobos/std_experimental_typecons.html#.Final


I don't know why D always swears to have library solutions for 
everything.

This is clearly something that should have a DIP and a language 
implementation in my opinion, considering it's a type-system 
addition.

It looks like a bad hack honestly.
Apr 30 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, April 30, 2018 10:36:52 bauss via Digitalmars-d-learn wrote:

 On Saturday, 28 April 2018 at 04:56:26 UTC, lempiji wrote:

 On Friday, 27 April 2018 at 02:59:16 UTC, Dr.No wrote:


 declaration or constructor time, like this:

 class C
 {

   readonly myClass mc;

   this()
   {

     mc = new myClass();

   }


   void doSomething()
   {

     mc = new myClass(); // wrong! result in compiler error, mc

 is readonly

   }

 }

 Does D have something like this natively or there's a way to
 do so with traits/CTFE at runtime?


 You can use std.experimenta.typecons.Final.
 https://dlang.org/phobos/std_experimental_typecons.html#.Final


 I don't know why D always swears to have library solutions for
 everything.

 This is clearly something that should have a DIP and a language
 implementation in my opinion, considering it's a type-system
 addition.

 It looks like a bad hack honestly.


Well, once upon a time, early in D2's development, it actually did have both
head and tail const, but it was deemed too complicated, and we ended up with
the transitive const that we have today that works as tail-const under some
circumstances but not all. The fact that immutable exists really complicates
things, more or less requiring tranitive const, and the fact that the type
system doesn't really distinguish between a class and its reference also
complicates things.

Personally, I think that head-const is almost worthless, so I see no real
value in adding it, but the fact that we're forced to have Rebindable to get
tail-const for classes is defintely ugly, though AFAIK, Walter and Andrei
both consider it to be a perfectly acceptable solution given the issues with
altering how the language treats classes.

Maybe a solid DIP could be constructed which would be accepted, but it's
likely going to need some good arguments given how much this has been argued
over in the past.

- Jonathan M Davis
Apr 30 2018
parent bauss <jj_1337 live.dk> writes:
On Monday, 30 April 2018 at 10:57:51 UTC, Jonathan M Davis wrote:

 On Monday, April 30, 2018 10:36:52 bauss via 
 Digitalmars-d-learn wrote:

 On Saturday, 28 April 2018 at 04:56:26 UTC, lempiji wrote:

 On Friday, 27 April 2018 at 02:59:16 UTC, Dr.No wrote:


 declaration or constructor time, like this:

 class C
 {

   readonly myClass mc;

   this()
   {

     mc = new myClass();

   }


   void doSomething()
   {

     mc = new myClass(); // wrong! result in compiler error, 
 mc

 is readonly

   }

 }

 Does D have something like this natively or there's a way 
 to do so with traits/CTFE at runtime?


 You can use std.experimenta.typecons.Final. 
 https://dlang.org/phobos/std_experimental_typecons.html#.Final


 I don't know why D always swears to have library solutions for 
 everything.

 This is clearly something that should have a DIP and a 
 language implementation in my opinion, considering it's a 
 type-system addition.

 It looks like a bad hack honestly.


 Well, once upon a time, early in D2's development, it actually 
 did have both head and tail const, but it was deemed too 
 complicated, and we ended up with the transitive const that we 
 have today that works as tail-const under some circumstances 
 but not all. The fact that immutable exists really complicates 
 things, more or less requiring tranitive const, and the fact 
 that the type system doesn't really distinguish between a class 
 and its reference also complicates things.

 Personally, I think that head-const is almost worthless, so I 
 see no real value in adding it, but the fact that we're forced 
 to have Rebindable to get tail-const for classes is defintely 
 ugly, though AFAIK, Walter and Andrei both consider it to be a 
 perfectly acceptable solution given the issues with altering 
 how the language treats classes.

 Maybe a solid DIP could be constructed which would be accepted, 
 but it's likely going to need some good arguments given how 
 much this has been argued over in the past.

 - Jonathan M Davis


Yeah, honestly I'm in the same opinion as you.


really wanted to use is immutable.

I'm not saying we need to implement this in the language, but 
just that the library solution isn't really elegant at all, 
compared to what a language implementation would have been.
Apr 30 2018