www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - alias this and immutable shenanigans

reply "Yao G." <nospamyao gmail.com> writes:
Consider this code:

---
module test;

struct Foo
{
     this( int f ) {
         _foo = f;
     }

      property int baz() {
         return _foo;
     }

     // alias _foo this;
     // alias baz this;	

     immutable int _foo;
}

struct Bar
{
     this( int f ) {
         _foo  = Foo(f);
     }

     private:
     immutable Foo _foo;
}
---

If I uncomment the alias _foo this line, I get the following error message:

% Test.d(22): Error: can only initialize const member _foo inside  
constructor

WTF! I'm initializing it in a constructor! Is this a bug? Or by design you  
cannot alias this to a immutable member of a struct. It seems that there's  
a hidden temp created that wants to initialize the field. Also, I wanted  
to alias the property Foo.baz, but it also caused the following errors:

% Test.d(22): Error: function test.Foo.baz () is not callable using  
argument types (Foo) immutable
% Test.d(22): Error: expected 0 arguments, not 1 for non-variadic function  
type  property int()

It seems that somehow the property is used as a "setter", not as a  
"getter".

So, my questions are:
1. Why is disallowed to alias this an immutable data inside a struct?
2. Why is disallowed to alias this a struct "getter" property?


-- 
Yao G.
Aug 12 2010
next sibling parent Justin Johansson <no spam.com> writes:
Yao G. wrote:
 WTF! I'm initializing it in a constructor! Is this a bug? Or by design 
 you cannot alias this to a immutable member of a struct. It seems that 
 there's a hidden temp created that wants to initialize the field. Also, 
 I wanted to alias the property Foo.baz, but it also caused the following 
 errors:

See the prior thread about the status and pandemonium of const/immutable/shared as your post is manifestly related to the same. Whether your particular observation is a bug or not depends on what the language specification calls out for. Of course (being cynical), if the language specification says to raise these kinds of errors that you observe under your input conditions then it is not a bug and that's simply how this PL compiler happens to work (and is expected to work according to its specification). Now, since no warranties are given that said PL is useful for any particular purpose, the sole responsibility is on you, the user, to determine whether or not said PL is useful for your purposes. ATOH, whether or not the language specification (formal/informal/absent/otherwise) is in concert with any formal/established theory of programming is yet another question. While feeling somewhat awkward about making this response, me thinks that the "roadmap for the holy grail of D" needs to be redrafted from scratch in many areas. -- Justin Johansson
Aug 13 2010
prev sibling parent Stanislav Blinov <blinov loniir.ru> writes:
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

  13.08.2010 9:37, Yao G. wrote:
 Consider this code:

 ---
 module test;

 struct Foo
 {
     this( int f ) {
         _foo = f;
     }

      property int baz() {
         return _foo;
     }

     // alias _foo this;
     // alias baz this;

     immutable int _foo;
 }

 struct Bar
 {
     this( int f ) {
         _foo  = Foo(f);
     }

     private:
     immutable Foo _foo;
 }
 ---

 If I uncomment the alias _foo this line, I get the following error 
 message:

 % Test.d(22): Error: can only initialize const member _foo inside 
 constructor

 WTF! I'm initializing it in a constructor! Is this a bug? Or by design 
 you cannot alias this to a immutable member of a struct. It seems that 
 there's a hidden temp created that wants to initialize the field. 
 Also, I wanted to alias the property Foo.baz, but it also caused the 
 following errors:

 % Test.d(22): Error: function test.Foo.baz () is not callable using 
 argument types (Foo) immutable
 % Test.d(22): Error: expected 0 arguments, not 1 for non-variadic 
 function type  property int()

 It seems that somehow the property is used as a "setter", not as a 
 "getter".

 So, my questions are:
 1. Why is disallowed to alias this an immutable data inside a struct?
 2. Why is disallowed to alias this a struct "getter" property?

(yep, about A._foo). When you use 'alias x this', methods not defined for 'typeof(this)' will be searched in typeof(x). In this case, _foo = Foo( f ) is a constructor call, but... If alias is present, _foo = Foo(f) translates to _foo._foo.opAssign(Foo(f)), or, when you alias to baz, to property assignment (and you indeed don't have a setter). Thus being said, I'm not sure if it's a bug or not - seems like an ambiguity at least. -- * *
Aug 13 2010