August 06, 2012
Is it bug or feature? :)

------------
class Foo
{
     int i;

     struct Bar
     {
         int j;

         int foobar()
         {
             return i + j;
         }
     }
}
------------

main.d(ХХ): Error: this for i needs to be type Foo not type Bar
August 06, 2012
On Mon, Aug 06, 2012 at 11:32:15PM +0200, RivenTheMage wrote:
> Is it bug or feature? :)
> 
> ------------
> class Foo
> {
>      int i;
> 
>      struct Bar
>      {
>          int j;
> 
>          int foobar()
>          {
>              return i + j;
>          }
>      }
> }
> ------------
> 
> main.d(ХХ): Error: this for i needs to be type Foo not type Bar

Try outer.i instead of just i.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
August 06, 2012
On 8/6/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Try outer.i instead of just i.

There is no "outer". A nested struct has the same access as a nested static class, meaning no access to any outer members unless they're static. OP could use a nested non-static class, but I don't know if the complications are worth it.
August 06, 2012
On Monday, 6 August 2012 at 21:51:24 UTC, Andrej Mitrovic wrote:

> There is no "outer". A nested struct has the same access as a nested
> static class, meaning no access to any outer members unless they're
> static.

Is there somewhere I can read the rationale behind that decision?

August 06, 2012
On Monday, 6 August 2012 at 22:28:40 UTC, RivenTheMage wrote:
> On Monday, 6 August 2012 at 21:51:24 UTC, Andrej Mitrovic wrote:
>
>> There is no "outer". A nested struct has the same access as a nested static class, meaning no access to any outer members unless they're static.
>
> Is there somewhere I can read the rationale behind that decision?

 I'm sorta half guessing on my logic here:

 If structs are value types that can be re-locatable (And separate entities) then having them dependent on something that you can't relocate means... what?

 Let's assume you create the struct, then pass it back out as a returned item (quite common); Later the class gets destructed. What happens with/to the struct? Since static functions/members are always accessible at compile time nothing changes. Perhaps your struct should probably be a class instead?
August 07, 2012
On Monday, 6 August 2012 at 23:42:45 UTC, Era Scarecrow wrote:
> On Monday, 6 August 2012 at 22:28:40 UTC, RivenTheMage wrote:
>> On Monday, 6 August 2012 at 21:51:24 UTC, Andrej Mitrovic wrote:
>>
>>> There is no "outer". A nested struct has the same access as a nested static class, meaning no access to any outer members unless they're static.
>>
>> Is there somewhere I can read the rationale behind that decision?
>
>  Let's assume you create the struct, then pass it back out as a returned item (quite common); Later the class gets destructed. What happens with/to the struct? Since static functions/members are always accessible at compile time nothing changes. Perhaps
> your struct should probably be a class instead?

In my program the class is a special kind of container, and the
struct is a С#-style iterator.

Common approach (std.container) is to copy all necessary data
inside the range through the constructor, it's good if traversing
is simple, but in my case it's inconvenient.

Anyway, it seems I have little choice :)

Thanks for help!
Top | Discussion index | About this forum | D home