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.

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/

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

-- 
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html

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.

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

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.mueller@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.

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{}

On Tuesday, 15 May 2012 at 05:02:20 UTC, 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/

Thanks-- filed http://d.puremagic.com/issues/show_bug.cgi?id=8104.

On Wed, May 16, 2012 at 4:59 AM, John Belmonte <john@neggie.net> wrote:

> On Tuesday, 15 May 2012 at 05:02:20 UTC, 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/
>>
>
> Thanks-- filed http://d.puremagic.com/issues/**show_bug.cgi?id=8104<http://d.puremagic.com/issues/show_bug.cgi?id=8104> .
>
>
voted up

-- 
Bye,
Gor Gyolchanyan.

Status update:

I created a pull request for the trivial change required to allow UFCS on opaque structs.  Kenji Hara balked at the change however, on the grounds that it opens up function hijacking.  I argued why that is not true-- at least using Walter's original definition of hijacking.  No response from Kenji, and things have been at a standstill for a week now.

Really this comes down to how we want to define opaque struct in the language specification.  The current definition from (http://dlang.org/struct.html):

    "The members are completely hidden to the user, and so the only operations on those types are ones that do not require any knowledge of the contents of those types."

That definition is a bit vague.  Do methods count as "contents" of a struct?  I propose distinguishing between structural content (fields, types, and sizes) and non-structural content (methods):

    "Members are completely hidden to the user.  Operations which require knowledge of the struct layout are not allowed and yield a compile error.  As far as methods, an opaque struct has none-- a property which can be relied on when employing uniform function call syntax."


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