http://d.puremagic.com/issues/show_bug.cgi?id=8104
John Belmonte <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #5 from John Belmonte <[email protected]> 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/[email protected] 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: -------
