Timon Gehr wrote: > On 05/15/2012 11:18 AM, Jens Mueller wrote: > >Timon Gehr wrote: > >>On 05/15/2012 07:44 AM, Ali Çehreli wrote: > >>>On 05/14/2012 10:02 PM, Timon Gehr wrote: > >>>>On 05/15/2012 04:28 AM, John Belmonte wrote: > >>>>>C API's often use a opaque struct pointer as a handle. Mapping such a > >>>>>struct to D using a forward declaration, I noticed that UFCS doesn't > >>>>>work: > >>>>> > >>>>>struct State; > >>>>>... > >>>>>State* s = new_state(); > >>>>>foo(s); // ok > >>>>>s.foo(); // compile error > >>>>> > >>>>>Error detail: > >>>>> > >>>>>Error: struct State is forward referenced when looking for 'foo' > >>>>>Error: struct State is forward referenced when looking for 'opDot' > >>>>>Error: struct State is forward referenced when looking for 'opDispatch' > >>>>> > >>>>>I'm wondering if anything would be harmed by removing this restriction. > >>>>> > >>>>>As a workaround I can use "struct State {}", but that feels wrong. > >>>>> > >>>> > >>>>This is a compiler bug. You can report it here: > >>>>http://d.puremagic.com/issues/ > >>> > >>>I would expect the compiler to need to see the definition of S to know > >>>that it really does not have a matching foo() member function. > >>> > >>>Ali > >>> > >> > >>S is opaque. It does not have any visible member functions. > > > >How should the compiler infer that S is opaque? How does it know when > >you write "struct State;" that State has no members? Is opaqueness > >implied when I do a forward declaration? > > > >Jens > > This is a compile time error: > struct S; > struct S{}
Yes. But how does this relate to the issue? Jens