Bug 4525 – Regression(2.020) Array member call syntax can't find matches in current class

This works fine in 1.062, but fails in 2.047 (has also been tested to fail in 2.042, 2.046): module mymodule; class Foo { void bar(string s) {} void foo() { string str = "hello"; str.bar(); } } Compiler output for 2.047: mymodule.d(9): Error: undefined identifier module mymodule.bar

Don has reported that "It worked in 2.012 and earlier, but failed in 2.020. I don't have any intermediate versions installed."

I've investigated a little further: 2.019 works and 2.020 fails. So the regression was introduced in 2.020. Maybe it's related to fix for this?: http://d.puremagic.com/issues/show_bug.cgi?id=2344

I can confirm it works in D1 and fails on D2.

This was introduced quite intentionally in https://github.com/D-Programming-Language/dmd/commit/f87c229d74e02f7f6d9522068ce80b1bbcd1c3db in order to fix issue 2344. I tried to fix it, but got a lot of weird crashes in the glue layer.

Further investigation shows that this is not a bug. array.func(arguments) is rewritten to be: .func(array, arguments) Note the leading ., which means look for func() at module scope. Foo.bar() in the example is not at module scope, hence it is not found. Note that the error message gives the clue in referring to "mymodule.bar", not just "bar". This was a deliberate design choice, as universal function call syntax is a feature meant to be used with global functions, not local ones.

(In reply to comment #5) > Further investigation shows that this is not a bug. > > array.func(arguments) > > is rewritten to be: > > .func(array, arguments) > > Note the leading ., which means look for func() at module scope. Foo.bar() in > the example is not at module scope, hence it is not found. Note that the error > message gives the clue in referring to "mymodule.bar", not just "bar". > > This was a deliberate design choice, as universal function call syntax is a > feature meant to be used with global functions, not local ones. The original bug issue against paired the change is bug 2344. But finding UFCS property/member function from global scope causes problems like this issue. And the finding rule is not work against function local import, see bug 6185. My suggestion is here: http://d.puremagic.com/issues/show_bug.cgi?id=6185#c6 - The UFCS lookup should start *from most inside scope*, not module scope. - Until reaching to module scope, UFCS lookup should not raise errors against mismatches of invalid function call, instead *ignore* them silently. - Finally, if there is no match in all scopes, raise an error.

Since the current behavior matches the spec, redesigning the behavior would be an enhancement request. This makes it a duplicate of bug 6185. *** This issue has been marked as a duplicate of issue 6185 ***

*** Issue 5567 has been marked as a duplicate of this issue. ***