www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UFCS on forward reference

reply "John Belmonte" <john neggie.net> writes:
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.
May 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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/
May 14 2012
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
May 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
May 15 2012
next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Timon Gehr wrote:

 On 05/15/2012 07:44 AM, Ali =C7ehreli 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 =3D 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 'opDispat=








ch'

 I'm wondering if anything would be harmed by removing this restricti=








on.

 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


=20
 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
May 15 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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{}
May 15 2012
prev sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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 =C3=87ehreli 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 suc=










h

 a

 struct to D using a forward declaration, I noticed that UFCS doesn=










't

 work:

 struct State;
 ...
 State* s =3D 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




--=20
Bye,
Gor Gyolchanyan.
May 15 2012
prev sibling parent reply "John Belmonte" <john neggie.net> writes:
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.
May 15 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
May 16 2012
prev sibling parent "John Belmonte" <john neggie.net> writes:
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
May 26 2012