[Issue 8104] UFCS on opaque struct won't compile
http://d.puremagic.com/issues/show_bug.cgi?id=8104 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2012-06-28 12:21:33 PDT --- I believe this is invalid. Code must not change behavior depending on whether a struct's members are there or are opaque, hence if there is a possible dependency on what those members are then it should fail to compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8104] UFCS on opaque struct won't compile
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: ---
[Issue 8104] UFCS on opaque struct won't compile
http://d.puremagic.com/issues/show_bug.cgi?id=8104
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2012-05-20 08:31:49 PDT ---
(In reply to comment #5)
@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.
Because of function hijacking.
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.
No. opaque struct means may or may not have members, not has no members.
They are different.
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?
I'd like to explain a use case.
---
1. module m_a has a struct S with members. module m_b imports m_a and use S.
module m_a;
struct S { void foo() { ... } ... }
S* makeS() { ... }
module m_b;
void foo(S* ps) { ... }
void main(){ auto ps = makeS(); ps.foo(); /* call S.foo */ }
2. S is changed to 'opaque struct'.
(e.g. m_a is provided by hand-made di file.)
module m_a;
struct S;
S* makeS();
3. In module m_b, now ps.foo() accidently calls m_b.foo.
---
Additionaly, current UFCS lookup mechanism is not completely
defined/implemented.
It's debated recently (See
http://forum.dlang.org/thread/jl09ui$ii8$1...@digitalmars.com), so I wouldn't
like
to change/add lookup mechanism yet.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8104] UFCS on opaque struct won't compile
http://d.puremagic.com/issues/show_bug.cgi?id=8104 --- Comment #3 from John Belmonte j...@neggie.net 2012-05-19 18:57:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/955 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8104] UFCS on opaque struct won't compile
http://d.puremagic.com/issues/show_bug.cgi?id=8104
--- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-05-19 19:10:14 PDT ---
(In reply to comment #0)
It should be possible to use UFCS on an opaque struct.
struct State;
void foo(State*) {};
void main() {
State* s;
foo(s); // ok
s.foo(); // compile error
}
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 think this is expected behavior. s.foo() should look up Stete's members, but
it is impossible, then errors occur.
UFCS should be a lookup for fall-back. If properly lookup fails, UFCS should
not hide the error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
