On 01/07/2013 04:27 AM, Timon Gehr wrote:
> ... (Eg. I am still reducing the massive breakage introduced by 2.061
> regressions. Mostly 'forward reference' errors -- mentioned nowhere in
> the spec, and seemingly introduced in order to 'fix' ICEs.) ...

dustmite ftw.

http://d.puremagic.com/issues/show_bug.cgi?id=9276

On Mon, Jan 7, 2013 at 4:27 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:

>
>
> The compiler should obviously use the part of the parser that parses template arguments to parse UDA's. I am surprised this is not what is done.
>

I humbly concur. Walter, you yourself presented UDAs as 'linking the dots' between different part of the D language (tuples...). It's an interesting and elegant approach, but the current situation is somewhat inadequate: UDA can be manipulated like template tuple parameters and should be parsed as such.

On 1/6/2013 7:27 PM, Timon Gehr wrote:
> I am still reducing the massive breakage
> introduced by 2.061 regressions.

Sorry about that, but 2.061 has been available for 2 months in beta. We fixed all but 3 of the reported regressions, and had good reasons for deferring those.

In fact, the 2.062 work in progress release is currently up on the site.

On 1/6/2013 8:37 PM, Timon Gehr wrote:
> dustmite ftw.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9276

Thank you.

On 1/6/2013 9:44 PM, Philippe Sigaud wrote:
> I humbly concur. Walter, you yourself presented UDAs as 'linking the dots'
> between different part of the D language (tuples...). It's an interesting and
> elegant approach, but the current situation is somewhat inadequate: UDA can be
> manipulated like template tuple parameters and should be parsed as such.


Well, I am glad to see people using it.

On 01/07/2013 07:27 AM, Walter Bright wrote:
> On 1/6/2013 7:27 PM, Timon Gehr wrote:
>> I am still reducing the massive breakage
>> introduced by 2.061 regressions.
>
> Sorry about that,

No problem. There will be some way to get it to compile. The reduced code shows which points to concentrate modification on. I have quite a few workarounds for forward reference errors in my code already.

> but 2.061 has been available for 2 months in beta.

I think this is a valid point, but coincidentally, I have not been working on the code base for the past 2 months.

> We fixed all but 3 of the reported regressions, and had good reasons for
> deferring those.
>

I am sure that very good progress is being made. However, the forward reference error problem will need formal treatment at some point. I think one reason they pop up is that symbol lookup for the intended language is inherently impossible to compute.

> In fact, the 2.062 work in progress release is currently up on the site.

Great!

The remark was not intended as a critique of DMD's development process, rather I was attempting to support the point that for language design issues, implementation details are of secondary importance.

On 1/6/2013 11:31 PM, Timon Gehr wrote:
> I am sure that very good progress is being made. However, the forward reference
> error problem will need formal treatment at some point. I think one reason they
> pop up is that symbol lookup for the intended language is inherently impossible
> to compute.

A huge source of fwd ref problems was not at all about symbol lookup. It was about partial types referencing properties of themselves. For example,

struct S {
    int a;
    int b = S.sizeof;
    int c;
}

for a simple example. There've been all kinds of variations on this theme, some of them wickedly complicated, but always boiling down to the same general issue.

Some forward ref regressions have cropped up because the compiler now does a better job of checking if there is enough of the type computed to get the desired property. Formerly, it would just return an incorrect size (for example). (I do not know if this is the case for your example, yet.)

On Monday, 7 January 2013 at 07:58:29 UTC, Walter Bright wrote:
> A huge source of fwd ref problems was not at all about symbol lookup. It was about partial types referencing properties of themselves. For example,
>
> struct S {
>     int a;
>     int b = S.sizeof;
>     int c;
> }
>
> for a simple example. There've been all kinds of variations on this theme, some of them wickedly complicated, but always boiling down to the same general issue.
>
> Some forward ref regressions have cropped up because the compiler now does a better job of checking if there is enough of the type computed to get the desired property. Formerly, it would just return an incorrect size (for example). (I do not know if this is the case for your example, yet.)

 I've had certain headaches from that as well trying to make my polymorphic struct, it's easy to see how it can get lost.

  struct S {
    static struct Data {
      int i;
    }
    union {
      Data data;
      S2 s2;  //problem line
    }
  }

  struct S2 {
    S base;   //problem line
  }

  Here the whole size is defined by Data, however because S2 references S1 before it has a concrete size it can get stuck (may still get stuck, not sure).

  Hmmm in cases like this, a @size attribute could be useful (forces it to believe given size rather than looking it up). So that could become:

    union {
      Data data;
      @size(Data.sizeof) S2 s2;  //size hint, forward ref problem gone
    }