digitalmars.D - UFCS on forward reference
- "John Belmonte" <john neggie.net> May 14 2012
- Timon Gehr <timon.gehr gmx.ch> May 14 2012
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> May 14 2012
- Timon Gehr <timon.gehr gmx.ch> May 15 2012
- Timon Gehr <timon.gehr gmx.ch> May 15 2012
- Jens Mueller <jens.k.mueller gmx.de> May 15 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> May 15 2012
- "John Belmonte" <john neggie.net> May 15 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> May 16 2012
- "John Belmonte" <john neggie.net> May 26 2012
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
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
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
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
Timon Gehr <timon.gehr gmx.ch> 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
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
--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=
astruct 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's as simple as not finding a definition of S. I think it'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"><<a href=3D"mailto:jens.k.mueller gmx= .de" target=3D"_blank">jens.k.mueller gmx.de</a>></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> > On 05/15/2012 07:44 AM, Ali =C3=87ehreli wrote:<br> > >On 05/14/2012 10:02 PM, Timon Gehr wrote:<br> > > > On 05/15/2012 04:28 AM, John Belmonte wrote:<br> > > >> C API's often use a opaque struct pointer as a handl= e. Mapping such a<br> > > >> struct to D using a forward declaration, I noticed that = UFCS doesn't<br> > > >> work:<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 f= or 'foo'<br> > > >> Error: struct State is forward referenced when looking f= or 'opDot'<br> > > >> Error: struct State is forward referenced when looking f= or 'opDispatch'<br> > > >><br> > > >> I'm wondering if anything would be harmed by removin= g this restriction.<br> > > >><br> > > >> As a workaround I can use "struct State {}", b= ut that feels wrong.<br> > > >><br> > > ><br> > > > This is a compiler bug. You can report it here:<br> > > > <a href=3D"http://d.puremagic.com/issues/" target=3D"_blank"=http://d.puremagic.com/issues/</a><br>
> >I would expect the compiler to need to see the definition of S to = know<br> > >that it really does not have a matching foo() member function.<br> > ><br> > >Ali<br> > ><br> ><br> > 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 "struct State;" 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
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
--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"><<a href=3D"mailto:john neggie.net" target=3D"_blank">j= ohn neggie.net</a>></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'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'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 'foo'<br=
br> Error: struct State is forward referenced when looking for 'opDispatch&= #39;<br> <br> I'm wondering if anything would be harmed by removing this restriction.= <br> <br> As a workaround I can use "struct State {}", 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
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