On 06.10.2017 03:01, Walter Bright wrote:
On 10/5/2017 4:26 AM, Timon Gehr wrote:
I know that some of the UFCS code was written without regard to
hijacking.
...
I think it is by design. Lookup first tries to find members of the
type, and only if they don't exist applies UFCS lookup. Therefore, if
members are added to the type or made visible, this may hijack
existing UFCS usages.
It may have been done that way to avoid breaking existing code.
I think so. It can break new code though. ;)
The way to fix it is to do UFCS lookup always and then error out if
both UFCS and member lookup match, but there is probably quite some
code relying on the fact that you can provide a custom implementation
of a general UFCS function by just adding a member. Also, with the
hijacking error if you actually meant the member function the only way
out I see is to use __traits(getMember, ...) for disambiguation.
(BTW: Local imports allow hijacking too. Maybe this one could be fixed?)
I thought that was taken care of when the whole import lookup mechanism
was redone a year or two ago.
...
https://issues.dlang.org/show_bug.cgi?id=17589
I think the best fix is what I quickly outline at the end of the issue.
It is originally a proposal of deadalnix:
https://issues.dlang.org/show_bug.cgi?id=10378#c9
...
D's name lookup rules were quite simple, and deliberately set up that
way. Unfortunately, most people thought they were unintuitive. It
turns out that simple algorithms are not intuitive, and we now have a
fairly complex lookup system. Martin and I implemented it, and
probably neither of us completely understands it. I find it
regrettable that things have gotten to that state.
...
It might make sense to sit down at some point and see what goals the
complex rules try to achieve and then come up with simpler rules that
achieve the same (or better) goals.
There wasn't a lack of discussion about the import lookup rules :-)
...
The only related issue of which I was aware was visibility of private
symbols. (I.e. private symbols should not cause conflicts with public
symbols in other modules.)
... >>> Doing this kind of wrapper doesn't work for operator overloading,
which brings us back to ADL is for operator overloading.
Why does it not work for operator overloading?
3+s
typeof(s) could overload opBinaryRight, no?
