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
next sibling 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
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
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 next sibling parent 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=




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




 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
May 15 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401fb1376bffc04c0109ff9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=





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





 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




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




 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. --f46d0401fb1376bffc04c0109ff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It&#39;s as simple as not finding a definition of S. I think it&#39;s prett= y obvious.<div><br><div class=3D"gmail_quote">On Tue, May 15, 2012 at 1:18 = PM, Jens Mueller <span dir=3D"ltr">&lt;<a href=3D"mailto:jens.k.mueller gmx= .de" target=3D"_blank">jens.k.mueller gmx.de</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">Timo= n Gehr wrote:<br> &gt; On 05/15/2012 07:44 AM, Ali =C3=87ehreli wrote:<br> &gt; &gt;On 05/14/2012 10:02 PM, Timon Gehr wrote:<br> &gt; &gt; &gt; On 05/15/2012 04:28 AM, John Belmonte wrote:<br> &gt; &gt; &gt;&gt; C API&#39;s often use a opaque struct pointer as a handl= e. Mapping such a<br> &gt; &gt; &gt;&gt; struct to D using a forward declaration, I noticed that = UFCS doesn&#39;t<br> &gt; &gt; &gt;&gt; work:<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;&gt; struct State;<br> &gt; &gt; &gt;&gt; ...<br> &gt; &gt; &gt;&gt; State* s =3D new_state();<br> &gt; &gt; &gt;&gt; foo(s); // ok<br> &gt; &gt; &gt;&gt; s.foo(); // compile error<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;&gt; Error detail:<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;&gt; Error: struct State is forward referenced when looking f= or &#39;foo&#39;<br> &gt; &gt; &gt;&gt; Error: struct State is forward referenced when looking f= or &#39;opDot&#39;<br> &gt; &gt; &gt;&gt; Error: struct State is forward referenced when looking f= or &#39;opDispatch&#39;<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;&gt; I&#39;m wondering if anything would be harmed by removin= g this restriction.<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;&gt; As a workaround I can use &quot;struct State {}&quot;, b= ut that feels wrong.<br> &gt; &gt; &gt;&gt;<br> &gt; &gt; &gt;<br> &gt; &gt; &gt; This is a compiler bug. You can report it here:<br> &gt; &gt; &gt; <a href=3D"http://d.puremagic.com/issues/" target=3D"_blank"=
http://d.puremagic.com/issues/</a><br>

&gt; &gt;I would expect the compiler to need to see the definition of S to = know<br> &gt; &gt;that it really does not have a matching foo() member function.<br> &gt; &gt;<br> &gt; &gt;Ali<br> &gt; &gt;<br> &gt;<br> &gt; S is opaque. It does not have any visible member functions.<br> <br> </div></div>How should the compiler infer that S is opaque? How does it kno= w when<br> you write &quot;struct State;&quot; that State has no members? Is opaquenes= s<br> implied when I do a forward declaration?<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Jens<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d0401fb1376bffc04c0109ff9--
May 15 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04088c755ae09a04c022e6e3
Content-Type: text/plain; charset=UTF-8

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.

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

-- Bye, Gor Gyolchanyan. --f46d04088c755ae09a04c022e6e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, May 16, 2012 at 4:59 AM, John Belmonte <= span dir=3D"ltr">&lt;<a href=3D"mailto:john neggie.net" target=3D"_blank">j= ohn neggie.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Tuesday, 15 May 2012 at 05:02:20= UTC, Timon Gehr wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 05/15/2012 04:28 AM, John Belmonte wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> C API&#39;s often use a opaque struct pointer as a handle. Mapping such a<b= r> struct to D using a forward declaration, I noticed that UFCS doesn&#39;t wo= rk:<br> <br> struct State;<br> ...<br> State* s =3D new_state();<br> foo(s); // ok<br> s.foo(); // compile error<br> <br> Error detail:<br> <br> Error: struct State is forward referenced when looking for &#39;foo&#39;<br=

br> Error: struct State is forward referenced when looking for &#39;opDispatch&= #39;<br> <br> I&#39;m wondering if anything would be harmed by removing this restriction.= <br> <br> As a workaround I can use &quot;struct State {}&quot;, but that feels wrong= .<br> <br> </blockquote> <br> This is a compiler bug. You can report it here: <a href=3D"http://d.puremag= ic.com/issues/" target=3D"_blank">http://d.puremagic.com/issues/</a><br> </blockquote> <br></div></div> Thanks-- filed <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D8= 104" target=3D"_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id= =3D8104</a>.<br> <br> </blockquote></div><br clear=3D"all"><div>voted up<br><br>--=C2=A0</div>Bye= ,<br>Gor Gyolchanyan.<br> --f46d04088c755ae09a04c022e6e3--
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