View mode: basic / threaded / horizontal-split · Log in · Help
January 07, 2013
Re: So, User-Defined Attributes
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
January 07, 2013
Re: So, User-Defined Attributes
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.
January 07, 2013
Re: So, User-Defined Attributes
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.
January 07, 2013
Re: So, User-Defined Attributes
On 1/6/2013 8:37 PM, Timon Gehr wrote:
> dustmite ftw.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9276

Thank you.
January 07, 2013
Re: So, User-Defined Attributes
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.
January 07, 2013
Re: So, User-Defined Attributes
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.
January 07, 2013
Re: So, User-Defined Attributes
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.)
January 07, 2013
Re: So, User-Defined Attributes
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
    }
Next ›   Last »
3 4 5 6 7
Top | Discussion index | About this forum | D home