On Friday, 8 January 2016 at 13:50:56 UTC, Walter Bright wrote:
On 1/8/2016 12:11 AM, Jacob Carlborg wrote:
Walter, should "ns.a()" work in the above example?

No:

1. first "ns.a" looks up "ns". Finds it in the current module, "main.ns".
2. Looks "a" up in "main.ns". "a" is not there. Error.

"a()" works because:

1. Look up "a" in current module. Doesn't find it.
2. Look up "a" in import "foo".
1. doesn't find it. Look in imported scope "foo.ns". finds it.
3. Look up "a" in import "bar".
1. doesn't find it. Look in imported scope "bar.ns". Doesn't find it.

Found only one "a" in the imports. We have da winnah!

I think name lookup rules are straightforward in D. I explain them over and over, for years, and nobody but me understands them. I find it very frustrating.

Lol, that either tells you that you've got it wrong or that your just too smart!

How bout this, add compiler functionality where one can contribute patches to dmd, and then experimentally use them?

If Manu has such capabilities, he could check his "theory" about quite easily(his code would just work)... at leas then everyone would know what the real issue is.

As much time that has been wasted arguing over this stuff, the feature and fix could have been implemented already.

e.g.,
dmd ... -expermental-nsmodule ....




Not that it matters, my own personal logic tells me that namespace resolution should be consistent with D module name resolution. To treat all namespaces sort of coming from a global chunk of symbols just seems wrong. The whole point in the first place was to get around that. Reverting back to C like scope resolution for something that was suppose to get away from it doesn't make sense logically.

Basically there are two choices,

D Namespaces are module bound(moduleA.ns2 is different than moduleB.ns2) or they are not(moduleA.ns2 is the same as moduleB.ns2).

How bout this for a solution?

Create a new namespace keyword, _namspace or inline namespace or whatever, it behaves one way and the other behaves the other way?? This way, everyone wins!!!! Who cares about people that "might abuse" something... that's trying to solve a problem that doesn't exist yet. If people want to shoot themselves in the foot, let them, they will learn, and like everything else, one will become deprecated over time, it's nothing new.

It's like trying to prevent people from walking because someone once fell in a man-hole. 99.9% of people are good at walking. Punish them for the edge case? Maybe the issue is the man hole instead?

I imagine it would be easier to write a utility that parses the C++ code and does some magic to make it work in D than getting D to support something that it already does differently.






Reply via email to