On 13 January 2016 at 03:20, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 1/11/2016 8:02 PM, Manu via Digitalmars-d wrote: >> >> Surely the fact that people are implementing machinery to undo the >> damage done is a strong indication that they don't want the feature. >> Please, can anyone produce an argument in favour...? Otherwise just >> accept that it was a bad idea and eject it into space. >> Why could anyone be attached to it? > > > > I already did for your scheme: > > int a; > extern (C++,ns) { int a; } // error!
Of course that's an error, declaring 2 symbols with the same name at the top level of the same module is obviously an error. No D coder would expect otherwise. There's no realistic scenario that could lead to that case; why would you have an extern(C++) symbol in some module and also want to put a D symbol with the same name in the same place? The only case I can imagine is you might want an extern(D) overload which wraps an extern(C++) function, but that works fine so there's no issue there. > The whole point of namespaces in C++ is to introduce scoped names. But we already have scoped names in D, so implementing that semantic for that reason has no value in D. We just want to link to C++ code. We don't want C++ concepts invading D, especially when the problem is already solved. We have a well defined module system. There's no reason, and no desire to deviate from that in any way whatsoever. I suggest that, if you're convinced namespaces must exist to address the non-issue you present above, then it should be a separate opt-in feature. As far as I know, we're yet to hear from someone who wants that behaviour by default. > Not putting them in a scope might work for your project, but in general it > will > not, and the workarounds you suggested for it (putting them in separate > modules) are awkward. This seems to be the foundation of our disagreement. I can't understand how you can make this claim, please demonstrate how using modules is awkward? It's not awkward to put your code in a module, it's normal... infact, it's impossible to put D code anywhere other than in a module. All D code is in a module... so, how can that possibly be considered awkward or inconvenient? Organising modules *IS* coding in D, and a user of extern(C++) wouldn't expect that they are suddenly following a different set of patterns or rules. They will continue to organise their code in modules however they usually do, in whatever way best suits their project or API. > All (*) the specific examples you've posted about fundamental problems with > the current scheme have been adequately addressed (bugs were fixed, and > misunderstandings clarified). Nobody in this thread has been able to > determine, with an example, what all the other problems you talk about are. Sure, bugs have been fixed, and I'm certain we can further make this 'work' as the design intends, but that has come at great cost in time and energy so far; a cost which never needed to be spent, and further effort is required. But the point is, making this work as designed doesn't necessarily put us in a state we're happy with. Rainer presented a case for confusion; you're making an argument that the scope is to make it feel kinda like C++ code, but it doesn't really behave like C++ at all. You can re-open namespaces and add symbols into existing namespaces until the cows come home in C++, but in D you end out with multiple definitions of the same named namespaces in different modules, and then you need to use the full name (including the module) to disambiguate... which surely makes plain the reality of the situation, which is that the namespace **is the module**, not the C++ namespace. Requiring the full module name to disambiguate leaves the namespace redundant. I have never, not ever, seen a C++ program where the same namespace isn't used in basically every source file. After mapping those source files to D modules, you will have the same namespace defined in every module, at which point the namespace only acts against it's stated worth. Further, the namespace almost certainly collides with D's top level package name. Other problems like Daniel presented regarding reflection are just annoying work which doesn't need to happen. Reflection of the kind that scans scopes for symbols requires new logic which recurses into C++ namespaces, and no existing reflection code will have support for that. (Do we actually have __traits which can do that currently? Can we detect if symbol is a C++ namespace?) One workaround for that is to alias the symbols from the namespace into the outer scope, which is just a bunch of pointless work and noise in the code, but we then want to make the namespace itself private such that the aliases become the API. Since alias is unable to make private symbols visible by aliasing them into a public scope, that leads to effort to create awkward kludges like Daniel presented to hide the namespace, or the approach I used which involves static import of cascading modules, and putting all the aliases in the outer module, doubling the number of files and obscuring the code tree. > I want to deal with the problems you're having, and find a solution. But > without examples illustrating them, I am dead in the water and cannot help. I understand, and I've said I'll find the time to reduce my case and we can do that work. I just don't have any free time at work right now, I'll get to this as soon as I can. Regarding this discussion, as far as I'm concerned, this is a separate conversation regarding the validity of the features existence. I want to convince you that it's wrong. Fixing the existing design is a separate conversation, which I'll reopen as soon as I have more information for you. Of course, it would save a lot of effort if you agreed that the design is wrong, and none of us need to do anything further.