• Yao G. (42/42) Aug 12 2010 Consider this code:
• Justin Johansson (21/26) Aug 13 2010 See the prior thread about the status and pandemonium of
• Stanislav Blinov (14/56) Aug 13 2010 If you rename Bar._foo to Bar._fooo, you'll see what it complains about

"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.

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

Stanislav Blinov <blinov loniir.ru> writes:

  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?

If you rename Bar._foo to Bar._fooo, you'll see what it complains about 
(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.

-- 
*
*