On 8/2/2018 5:23 PM, rikki cattermole wrote:
> Because it will affect mangling only, do we have any examples of c/c++ code that appends _'s to it that is used by the D community?

The __ scheme won't break existing code, and we don't need a survey to show that.

On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 8/4/2018 12:45 AM, Manu wrote:
> > [...]
> I get it, Manu, you don't find my arguments compelling. You've put these forth before, and I could repeat myself rebutting each. I expect we're at a dead end with that.

So, what you're saying is "I hear you, and I will never change it
because I subjectively prefer it the way it is in spite of every users
experience".
Will you commit to that position officially, so we can refer back to
it in future?

Just support the string namespace? It won't hurt you, our code will be better, and you'll make us all that actually link to C++ so much happier for it.

If we produce a DIP to fix this, will you reject it in principle?

Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of  that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing?

On Mon, Aug 6, 2018, 14:53 Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On 8/4/2018 12:45 AM, Manu wrote:
> > > [...]
> > I get it, Manu, you don't find my arguments compelling. You've put these
> forth
> > before, and I could repeat myself rebutting each. I expect we're at a
> dead end
> > with that.
>
> So, what you're saying is "I hear you, and I will never change it
> because I subjectively prefer it the way it is in spite of every users
> experience".
> Will you commit to that position officially, so we can refer back to
> it in future?
>
> Just support the string namespace? It won't hurt you, our code will be better, and you'll make us all that actually link to C++ so much happier for it.
>
> If we produce a DIP to fix this, will you reject it in principle?
>

On Monday, 6 August 2018 at 04:53:05 UTC, Manu wrote:

> If we produce a DIP to fix this, will you reject it in principle?

I think you and Walter Bright made good points and I think a creation of a DIP that addresses his concerns would be a best course of action IMO.
-Alexander

On Monday, 6 August 2018 at 09:48:30 UTC, Danni Coy wrote:
> Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of  that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing?

I haven't read all of the posts in this thread, but my understanding of Walter's argument is that he believes there is only one correct way to work with C++ code. If that's the case, there's no need for warnings, because the language should prevent you from doing it wrong in the first place. The first step will be to convince him that the "mangle only" approach is valid.

On Friday, 3 August 2018 at 21:49:53 UTC, Walter Bright wrote:
> On 8/3/2018 3:58 AM, Atila Neves wrote:
>> I would only be able to alias a nested namespace once, since the code below obviously won't work:
>> 
>>     mixin CppNamespace0!() x;
>>     alias chrono = x.std.chrono;
>>     mixin CppNamespace1!() y;
>>     alias chrono = y.std.chrono;
>
> Try this:
>
>
>      mixin template X() {         // boilerplate prefix
>
>          extern (C++, std) extern(C++, chrono) int foo();   // original line
>
>      } mixin X!() x; alias foo = x.std.chrono.foo;  // boilerplate suffix

That doesn't solve the problem at all. I was toying with being able to have a nested namespace be an alias in a module. I can't realias chrono after the first `alias chrono = `, nor can I alias it to the different `chrono`s in all the different template mixins.


>> I considered for a while whether or not this would be truly bad, and the more I think about it the more convinced I am that Manu is right and there should be _no_ scoping whatsoever in D regarding C++ namespaces. We have packages and modules, we can use those to put the C++ functions we declare in whatever hierarchy we want.
>
> I am puzzled. With:
>
>   namespace std {
>      namespace chrono {
>          void foo();
>      }
>   }
>
>   namespace std {
>     namespace chrono {
>          void bar();
>     }
>   }
>
> you have stated that it is impractical for your translator to rewrite this as:
>
>    namespace std {
>      namespace chrono {
>          void foo();
>          void bar();
>      }
>   }
>
> Ok, I get that. But it is practical to rewrite it as:
>
>    module std.chrono;
>    void foo();
>    void bar();
>
> ?

I don't understand what your question has to do with what you quoted. What I'm trying to say is that I think `extern(C++, foo.bar)` should NOT introduce a scope in D in any way, shape, or form. The D module/import/overload system should have no idea of what `foo` or `foo.bar` are - they don't exist.

>
> > I mean `std` should never be part of the fully qualified name
> of, for
> > instance, `core.stdcpp.exception.std.bad_exception`. It
> should just
> > be `core.stdcpp.exception.bad_exception` instead.
>
> C++ recognizes that, too, which is why it has "using" declarations. D has the equivalent thing, "alias".
>
> You can do things like:
>
>     import std = core.stdcpp.exception;
>
> and then refer to:
>
>     std.bad_exception
>
> or:
>
>     import exception = core.stdcpp.exception;
>
>     exception.bad_exception;
>
> or whatever works best for one's project. Aliasing and import renaming (which are really just more aliasing) is very capable, and was designed for just these sorts of issues.

I think we're talking past each other. I know how to alias in D, and how to use `using` in C++. What I'm saying is that, with the file we have now (core.stdcpp.exception):

extern(C++, std) {
   class exception { /* ... */ }
}

Currently the fully qualified name of `exception` is `core.stdcpp.exception.std.exception`. I'm arguing that this is a mistake, and the the FQN should instead be `core.stdcpp.exception.exception`.

Yes, namespaces introduce scope in C++. Yes, lookup rules in C++ are crazy. The main points I'm (and, I think, Manu) arguing are:

1. We already have D packages, modules, and overload rules. We don't need to import any from C++
2. That namespaces introduce a scope in C++ does not mean that `extern(C++, ns)` should introduce one in D

i.e. Keep everything about D as-is, _except_ for no scoping for `extern(C++, ns)`.

On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote:
> On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> Faster and consistently, sure. But I don't think 'better' is possible.
>
> [...]

Bindings != wrappers. I agree that wrappers will nearly always need to be written, I'm trying to automate the writing of the declarations needed to link.

It should be possible to automate translating everything, but some things will be tricky in C++. std::vector is quite clearly a value type, yet the GNU implementation declares it as a class with protected inheritance from _Vector_base. That's going to be fun...

On Saturday, 4 August 2018 at 12:18:21 UTC, tide wrote:
> On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote:
>> On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
>>>
>>> The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility.
>>
>> Why would you write bindings if the computer can do it for you, better, faster and consistently?
>
> With the current tools the ones that generate D files to be used aren't very good. They evaluate Macros based on the current implementation, so if there's a define MACHINE_X86 or MACHINE_x64, those macro and #if's will be evaluated based on the current system running the tool instead of generating equivalent version() statements.

If the D files are to be checked in, then yes, that'd be a problem. If they're not, as is the case with dpp, then... that's actually what you want.

dpp: I fought the preprocessor and the preprocessor won.

> It would be, but I don't think it'll ever be 100% and will require manual intervention.

If manual intervention is required, dpp has failed. Some problems will be tricky, especially where the preprocessor is concerned. But a lot of real-life production code works.

On Sunday, 5 August 2018 at 23:28:06 UTC, Walter Bright wrote:
> On 8/4/2018 12:45 AM, Manu wrote:
>> [...]
> I get it, Manu, you don't find my arguments compelling. You've put these forth before, and I could repeat myself rebutting each. I expect we're at a dead end with that.
>
> But the fact remains, I've shown both you and Atila how to make things work for you, in a hygienic manner, with the language as it is now. For you, it's adding an alias declaration. For Atila, it's a couple lines of boilerplate dpp can add, without disrupting dpp's internal design.

What's your crossplatform workaround if I have a namespace named "version" or "package" ?

extern(C++, version) // error
{
    void foo();
}

extern(C++, package) // error
{
    void bar();
}

You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. The only workaround that exists currently is to rewrite C++ code, which you stated wasn't a valid solution you considered for extern(C++).

> I understand you don't want to type in the alias declaration. May I suggest using Atila's dpp? Then you won't have to even look at the output. I also expect that your use cases can help make dpp better, and that would be good for all of us.
>
> ---
>
> P.S. I have no experience with dpp and how it is used. But my experience with translators is that nobody expects to nor wants to look at its output. They just want it to work. And it seems a fact of life that the output of machine translation resists being purty, because what's purty in A never looks purty in B.

How can you suggest DPP then go on to say you've never even used it or know how it is even used?

On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
> Yes. But then you'll have the people who want a 1:1 correspondence with their C++ files and the corresponding D files. I happen to be one of those people, for the ease of maintaining a translation (and for comparing it with the original C++ source code if it is not behaving correctly).

This would still be true if current behavior was kept and extern(C++, "ns") or extern(C++, ns, noscope) or something was added though no?

Though I do think the string is superior though because then this would actually compile:

extern(C++, "shared") {
    void f();
}

It feels the two preferences being mutually exclusive has somehow occupied a lot of this discussion when they are not.

Cheers,
- Ali