Walter wrote:

| "Ben Hinkle" <bhinkle@mathworks.com> wrote in message
| news:d1faqu$1pir$1@digitaldaemon.com...
|
|>new in dmd-119 on WinXP. The following causes dmd to crash
|>template Foo(alias tail) {
|>}
|>struct List(V) {
|>  mixin Foo!(tail);
|>  V tail;
|>}
|>int main(){
|>  List!(int) x;
|>  return 0;
|>}
|>
|>MinTL uses template to share code between parametrized structs so I
|>found the ability to pass data member names to templates very useful.
|
|
| The problem is 'tail' being forward referenced by the mixin. It works
| if you swap the declaration order of Foo!(tail) and tail.

Added to DStress as
http://dstress.kuehne.cn/run/mixin_07.d
http://dstress.kuehne.cn/run/mixin_08.d

Thomas

"Walter" <newshound@digitalmars.com> wrote in message news:d1f58u$1gq5$1@digitaldaemon.com...
> More dusty old bugs fixed.

" Now correctly diagnoses as an error attempts to access members of outer aggregate from within inner aggregate. "

NOOOO!

It's completely messed up my nice "property organization" in my project!!

Before, I was able to write..

class A
{
public:
    struct propSet
    {
        int x(int x)
        {
            return _x=x;
        }

        int x()
        {
            return _x;
        }
    }

private:
    int _x;
}

..

A a=new A;
a.propSet.x=5;

The propSet structure functioned as a nice organizational feature, acting as a sort of namespace.  This is now illegal (for what reason, I don't know: nested functions can access outer function variables, but not nested aggregates?).

Is there any way to simulate this now, or perhaps a way to access the "parent" this pointer?  The way I have things set up, it is not possible to move the outer aggregate members into the inner aggregate, nor would it be possible to make the inner aggregate a separate, outer aggregate.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d1k8go$qtn$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message news:d1f58u$1gq5$1@digitaldaemon.com...
> > More dusty old bugs fixed.
>
> " Now correctly diagnoses as an error attempts to access members of outer aggregate from within inner aggregate. "
>
> NOOOO!
>
> It's completely messed up my nice "property organization" in my project!!
>
> Before, I was able to write..
>
> class A
> {
> public:
>     struct propSet
>     {
>         int x(int x)
>         {
>             return _x=x;
>         }
>
>         int x()
>         {
>             return _x;
>         }
>     }
>
> private:
>     int _x;
> }
>
> ..
>
> A a=new A;
> a.propSet.x=5;
>
> The propSet structure functioned as a nice organizational feature, acting
as
> a sort of namespace.  This is now illegal (for what reason, I don't know: nested functions can access outer function variables, but not nested aggregates?).
>
> Is there any way to simulate this now, or perhaps a way to access the "parent" this pointer?  The way I have things set up, it is not possible
to
> move the outer aggregate members into the inner aggregate, nor would it be possible to make the inner aggregate a separate, outer aggregate.

The problem is this never worked in the first place, although it would compile and generate code as if the inner and outer structs were overlaid on top of each other. It was like a pointer to one struct being used to access the members of another, unrelated, struct.

D's nested classes do not behave like Java inner classes, which implicitly have a member that is initialized to be the 'this' pointer of the outer class. You can emulate this behavior, however, by explicitly providing such a member and initializing it.

"Walter" <newshound@digitalmars.com> wrote in message news:d1keph$110c$1@digitaldaemon.com...
> The problem is this never worked in the first place, although it would
> compile and generate code as if the inner and outer structs were overlaid
> on
> top of each other. It was like a pointer to one struct being used to
> access
> the members of another, unrelated, struct.

I can see how that might be an ideological problem, but isn't it more useful to think of it that way?  Usually when one defines an inner class, one intends for that inner class to be very tightly integrated into the outer class.

> D's nested classes do not behave like Java inner classes, which implicitly
> have a member that is initialized to be the 'this' pointer of the outer
> class. You can emulate this behavior, however, by explicitly providing
> such
> a member and initializing it.

I'll try that.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d1kja9$15c8$1@digitaldaemon.com...
>> D's nested classes do not behave like Java inner classes, which
>> implicitly
>> have a member that is initialized to be the 'this' pointer of the outer
>> class. You can emulate this behavior, however, by explicitly providing
>> such
>> a member and initializing it.
> I'll try that.

I managed to get it to work, but it's rather cumbersome.

My code now looks like this:

class A
{
public:
    this()
    {
        // I have to do "that=this" for every property set now
        pos.that=this;
    }

    struct propSetStruct
    {
        int x(int xx)
        {
            // I now have to use "that." every time I need access to an
outer member
            return that._x=xx;
        }

        int x()
        {
            return that._x;
        }

        // every prop set needs a "that" pointer now
        private A that;
    }

    // every prop set must now be explicitly declared
    propSetStruct propSet;

private:
    int _x;
}

It's ugly, cumbersome, and prone to bugs if I forget to add in all the appropriate code to add in a new property set.

Like I said - it's probably idealogically better, but it's just a hassle.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d1faqu$1pir$1@digitaldaemon.com...
> new in dmd-119 on WinXP. The following causes dmd to crash
> template Foo(alias tail) {
> }
> struct List(V) {
>   mixin Foo!(tail);
>   V tail;
> }
> int main(){
>   List!(int) x;
>   return 0;
> }
>
> MinTL uses template to share code between parametrized structs so I found the ability to pass data member names to templates very useful.

The problem is the forward reference to tail. I have it fixed to diagnose it now, the fix for the code is to reverse the mixin and tail declarations.

> The problem is the forward reference to tail. I have it fixed to diagnose
> it
> now, the fix for the code is to reverse the mixin and tail declarations.

yup. I updated the mintl code after your initial post. I'm glad you have
added a check for it.
Are the rules about forward references documented? It seems fragile. Every
now and then something subtle changes and people start reporting code
breaking in non-obvious ways.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d2v5i7$5hq$1@digitaldaemon.com...
> > The problem is the forward reference to tail. I have it fixed to
diagnose
> > it
> > now, the fix for the code is to reverse the mixin and tail declarations.
>
> yup. I updated the mintl code after your initial post. I'm glad you have
> added a check for it.
> Are the rules about forward references documented? It seems fragile. Every
> now and then something subtle changes and people start reporting code
> breaking in non-obvious ways.

I'd like to eventually make D work with all forward references. Unfortunately, this has turned out to be harder than I expected. What works and doesn't is often subtle. My first priority is to at least correctly diagnose the problems.