It's as simple as not finding a definition of S. I think it's pretty
obvious.
On Tue, May 15, 2012 at 1:18 PM, Jens Mueller <jens.k.muel...@gmx.de> 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
>
--
Bye,
Gor Gyolchanyan.
