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


John Belmonte <j...@neggie.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |k.hara...@gmail.com,
                   |                            |timon.g...@gmx.ch


--- Comment #5 from John Belmonte <j...@neggie.net> 2012-05-20 06:44:31 PDT ---
@Kenji: When brought up on the forum there seemed to be consensus that this was
a bug.  http://forum.dlang.org/thread/rseaqsqosqrnirrcl...@forum.dlang.org

Why should the act of function member lookup on an opaque struct necessarily be
an error?  It should only be an error if the member cannot be resolved.  Prior
to UFCS, there was no way to resolve function members outside of the struct
itself, so it made sense to raise an error directly from the struct's search
call.

At http://dlang.org/struct.html there is a section "Opaque Structs and Unions".
 It says that the members of such a struct are hidden from the user.  It's not
clear on what "hidden" implies though.  With respect to function members this
documentation should be clarified:  an opaque struct behaves as if it has no
function members.

Note that all the errors regarding "forward reference" are misleading.  These
structs not a forward reference, there are opaque.  It's illegal to redefine an
opaque struct:

  struct S;
  struct S { int foo; } // Error: struct S conflicts with struct S

Given that, what are you trying to protect the user from by disallowing UFCS on
these structs?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to