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?

That's the idea behind DPP.  You can just #include C headers and they will be translated before compile time.  This is very helpful with projects like HDF5 that consider it acceptable in a minor release to replace a function with a macro.

Wrappers are a bit different.

In time C++ will follow.

> Not only that, who do you think even writes bindings for libraries? Most bindings are done by the community for libraries to other languages. How many companies do you know have bindings for their C/C++ libraries for D, that maintains them?

We do for a few things - for other peoples' libraries not our own.  But it would be better not to have to write bindings at all.

> damn hell no. That's what modules are for. So why are you trying to implement namespaces in D under the guise of C++ name mangling.

I don't think either Manu or Atila want to be able to sneak in namespaces by the backdoor.  They just want to be able easily to control namespace mangling of C++ linkage symbols.

What extern(C++) should be used for is allowing you
> to call C++ code from D, not to be able to format C++ code into D. The only problem you have with breaking code up into multiple files is that it isn't 1:1. That's not a technical problem, it's a problem of conflicting personal opinion. If it's not 1:1, who cares? If some some odd reason you have two namespaces in one file in C++, odds are they are probably separated in that one file anyway. If not and for some reason the the code has multiple namespace definitions smashed together into one file, flip-floping between namespaces. That's not D's problem to fix the project's poor organization method.

For automatically translated bindings I think that the request is not unreasonable because there's considerable value in being able to just #include C++ headers as you can already with C headers and just call the C++ code from D.  D doesn't have libraries?  Well it's got 1500 on code.dlang.org plus C and C++ libraries.  What is it you think is missing?  That's a good retort!

I understand from Atila present choice just makes it a lot more complicated, not impossible.

On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d <digitalmars-d@puremagic.com> 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?

Faster and consistently, sure. But I don't think 'better' is possible.

>From my experience, in many cases, C++ really doesn't express well in
D by direct translation. I tend to do significant massaging of the C++
helper material to improve the experience from D.
Usually C++ libs have a lot of helper material in the form of macros,
little template utilities, inline wrappers, and they can almost always
be expressed more nicely in D with some tweaking.
I often also insert some additional inline D helpers/wrappers nearby
the externs, which help adapt the signatures; ie, apply some
attributes, or make a slice-based API that transforms to ptr+len args,
maybe implement a range helper, that sort of thing.
The goal is to make the API attractive such that a user is compelled
to prefer interacting with the lib from D than from C++.
C++ namespaces interfere with overload resolution in particular, and
that makes this goal harder.

It probably depends on your use. If you're just calling a C++ lib, and
wrap it up in a box for use in your local code, a machine translation
for the API might be fine. I'd call that 'making use of a feature
lib'.
If you are linking to a lib that is a fundamental part of your
application infrastructure, you absolutely must do significant manual
work to make the C++ code express nicely to D, otherwise the
user-experience interacting with the C++ api from D will be worse than
just using C++.
If the C++ experience is better than from D, then D experience ceases
to exist as no case can be made to prefer D over C++, the project is
moot, and I have wasted my time.
The D experience must not just be equal to the C++ experience, it must
typically be substantially better in a variety of ways, and I have
never been able to have such an experience interacting with C++
without making some manual effort towards quality bindings.
The current namespace mechanics put SOOO much more strain on that goal
than is necessary.

One other important feature of quality bindings, is that the binding
itself must be readable and maintainable. The binding itself is the
very first showcase to C++ programmers of how their API's could be
better in D. It must be well organised (like normal D code), and the
current situation with boilerplate invading the works is destructive
toward that end.
Of course, thanks to this namespace situation, when involving with
these hideous workarounds, they are usually objectively NOT better in
D, and C++ programmers do indeed recognise that immediately.

On Wed, 1 Aug 2018 at 16:05, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 8/1/2018 10:24 AM, Jonathan M Davis wrote:
> > Not to say that that can't work, but I have to say that it seems pretty ugly if using extern(C++, NS) requires a bunch of aliases just to use symbols normally.
>
> What is normal is a slippery concept, especially when one is comparing different lookup rules between languages. D modules do not a 1:1 correspondence with C++ namespaces, either (not even close).
>
> Aliases are a normal and highly useful D tool to copy names from one scope to another.
>
>
> > Certainly, it does come across like
> > you didn't trust the D module system to do its job for some reason.
>
> Reorganizing the code into modules means potentially forcing users to split code from one C++ file into multiple D files. How's that really going to work if you have a translation tool? One of the aspects of Java I didn't care for was forcing each class into its own file.
>
> So while Manu is clearly happy with cutting up a C++ file into multiple D files, I doubt that is universal. His proposal would pretty much require that for anyone trying to work with C++ namespaces who ever has a name collision/hijack or wants to make the code robust against collision/hijacking.
>
> An example of silent hijacking:
>
>     extern (C++, "ab") void foo(long); // original code
>     ... lots of code ...
>     extern (C++, "cd") void foo(int); // added later by intern, should have been
>                                       // placed in another module
>     ... a thousand lines later ...
>     foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux
>
> You might say "nobody would ever write code like that." But that's like the C folks saying real C programmers won't write:
>
>      int a[10];
>      for (int i = 0; i <= 10; ++i)
>         ...a[i]...
>
> But we both know they do just often enough for it to be a disaster.
>
> Now, with D:
>
>      extern (C++, ab) void foo(long);
>      foo(0);    // works!
>      ---
>      extern (C++, ab) void foo(long);
>      extern (C++, ab) void foo(int);   // error!
>      ---
>      extern (C++, ab) void foo(long);
>      extern (C++, cd) void foo(int);
>      foo(0);    // error!
>
> I juxtaposed the lines so it's obvious. It's not so obvious when there's a thousand lines of code between each of those lines. It's even worse when foo(long) sends a birthday card to your daughter, and foo(int) launches nuclear missiles.
>
> Yes, this extra protection comes at a cost - you'll have to type a bit more. Just like D doesn't allow implicit declaration of variables, requires static typing, and variables are always initialized unless you explicitly use `= void`. The protection is worth it, and is part of D's philosophy.
>
> I hope that adequately answers the "for some reason" :-)

I'm sorry, that doesn't come remotely close justifying the imbalance.

Firstly, it remains entirely hypothetical, whereas our criticisms are evidence based, over more than half a decade.

"D modules do not a 1:1 correspondence with C++ namespaces, either (not even close)." - exactly. So don't even try to emulate C++'s broken feature in D. We can't win; equivalent semantics are impossible, we only get the *worst* of both worlds by trying.

"Reorganizing the code into modules means potentially forcing users to
split code from one C++ file into multiple D files" - Yes, that is
what people do when binding C++ code.
We're not writing C++ code, we're writing D code, intended to be
consumed by other D code, playing by D's rules. We just want to be
able to call functions that are in some C++ .obj file, and get on with
writing our D code.
To make a C++ API comfortable and natural to a D user, in all but the
simplest cases, it has required such human intervention in all
meaningful case I've attempted so far, if you want a quality result.
I'm not interested in mediocre results; that does nothing but damage
the impression D makes on C++ users, and thereby wasting my time and
effort, and undermining the potential advance of D to a target group
of interested new users.

"So while Manu is clearly happy with cutting up a C++ file into
multiple D files, I doubt that is universal" - support this claim? I'm
happy with doing what is necessary to make a C++ API express as
naturally as possible to D code. I would expect most people making
such an effort to feel the same way. Why would you suspect otherwise?
But then also take that in conjunction with the fact that I haven't
actually argued for the demolition of the C++ namespace scope (I don't
care either way). It can stay and resolve these hypotheticals if you
must, although my bias is that the namespace should be applicable by
some other opt-in mechanism. But I'm not interested in pushing that, I
have no horse in that race.
You can keep your namespace. But don't ruin C++ interaction for the rest of us!

"How's that really going to work if you have a translation tool?" -
that sounds like a job that's 100 times simpler for a tool than for a
human!
That said, I have dabbled with such machine translation, and it's
non-trivial in a whole variety of ways. This issue you describe is
trivial by comparison to the real challenges; C++ and D are not the
same language, and they express differently. Lots of C++ constructs
don't have a perfect translation and need user intervention of one
kind or another.
Purely tool translated API's are likely to be poor-quality API's in D.
Lots of supporting machinery (macros, helper templates, etc) outside
of the hard symbols that you link against need to be massaged by hand
for natural D consumption.
Atila has done much more work on this, and this thread is evidence
that he's also been aggravated by this issue. He may have been able to
work-around, but we have wasted his time here, and nobody is any
better-off for it.
Your machine translation argument does not appear to track reality.

"Yes, this extra protection comes at a cost - you'll have to type a bit more." - ignoring that this is 100% dismissive of every complaint ever arisen... this isn't always possible. "Typing" isn't a feature of generative programming, where the case must be detected and manually accounted in the generational logic, which I do heaps of. A mixin placed inside a namespace scope is incapable of also introducing a matching alias outside of the scope. The acrobatics requires to make this work undermine the value.

And this claim "The protection is worth it" - that is so much more subjective than anything you've ever criticised me for saying, because it flies in the face of all the evidence we've ever collected.

Your examples with multiple sibling namespaces in the same file are
borderline contrived. I've never seen sibling namespaces in a single
file. It's theoretically possible, but you can't balance the value
against the costs on the merit of that point with a straight face.
Occasionally there's some nested 'internal' namespace, and that maps
perfectly naturally to a submodule, or much better, lifted to private
or package protection at module scope. 'internal' or 'detail'
namespaces are a symptom of C++ not having such a feature, and it's
mostly not desirable to mirror them in D.
If you don't like that, you have previously suggested solutions where
we use an alternative construct like a struct for namespacing. But if
you genuinely feel a within-a-single-module namespace solution is
useful, then that should be a separate proposal that stands on its
own. It should also be opt-in.
I would still find no reason to deviate from the simplicity of
arranging namespaces via D modules, in a completely conventional,
consistent, and proven manner. The current design denies us this most
simple of options.

If that's the substance of the protective measures provided, then
that's a very poor balance against the problems.
Design should encourage maximum simplicity, not maximum complexity as it does.

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:
>>
>> 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?
>
> Faster and consistently, sure. But I don't think 'better' is possible.
>
>>From my experience, in many cases, C++ really doesn't express well in
> D by direct translation. I tend to do significant massaging of the C++
> helper material to improve the experience from D.
> Usually C++ libs have a lot of helper material in the form of macros,
> little template utilities, inline wrappers, and they can almost always
> be expressed more nicely in D with some tweaking.
> I often also insert some additional inline D helpers/wrappers nearby
> the externs, which help adapt the signatures; ie, apply some
> attributes, or make a slice-based API that transforms to ptr+len args,
> maybe implement a range helper, that sort of thing.
> The goal is to make the API attractive such that a user is compelled
> to prefer interacting with the lib from D than from C++.
> C++ namespaces interfere with overload resolution in particular, and
> that makes this goal harder.
>
> It probably depends on your use. If you're just calling a C++ lib, and
> wrap it up in a box for use in your local code, a machine translation
> for the API might be fine. I'd call that 'making use of a feature
> lib'.
> If you are linking to a lib that is a fundamental part of your
> application infrastructure, you absolutely must do significant manual
> work to make the C++ code express nicely to D, otherwise the
> user-experience interacting with the C++ api from D will be worse than
> just using C++.
> If the C++ experience is better than from D, then D experience ceases
> to exist as no case can be made to prefer D over C++, the project is
> moot, and I have wasted my time.
> The D experience must not just be equal to the C++ experience, it must
> typically be substantially better in a variety of ways, and I have
> never been able to have such an experience interacting with C++
> without making some manual effort towards quality bindings.
> The current namespace mechanics put SOOO much more strain on that goal
> than is necessary.
>
> One other important feature of quality bindings, is that the binding
> itself must be readable and maintainable. The binding itself is the
> very first showcase to C++ programmers of how their API's could be
> better in D. It must be well organised (like normal D code), and the
> current situation with boilerplate invading the works is destructive
> toward that end.
> Of course, thanks to this namespace situation, when involving with
> these hideous workarounds, they are usually objectively NOT better in
> D, and C++ programmers do indeed recognise that immediately.

Would it be inaccurate to make a distinction between bindings and wrappers ?  It's always going to be less pleasant to call even C bindings from D then an idiomatic D wrapper written on top.

But if you have automatically generated bindings then you can put the effort into the wrappers and it's easier to do the latter incrementally.

And being able to use a library at all even if slightly unpleasantly without having to pay a big price up front beats having no choice.  At least for us the sequencing of cost matters more than the total cost, and the calendar time element of cost to being able to write a passable and useful first version is more important than the pecuniary element.

We have many more people who are not C++ programmers but express their ideas in D then we do people who know C++ pretty well.

BTW I almost think the D Foundation should organise a library wrapping as a service marketplace ;). Lots of people in the community are open to remote work part or full time.  But the cost is in finding the right people and also to some extent supervising and organising the design and work.  That could be just another forum in the beginning.

On 8/3/18 5:20 PM, Walter Bright wrote:

> Telling them their code is **** and that they should rewrite it in order to work with D is never, ever going to work.

And that's OK with me. I'm OK with D saying it only supports reasonably written C++ code, and 99% of the C++ community would agree. If that means we lose one "customer" who doesn't use sane namespace practices, then I guess they can stick with C++.

>> are there any other additional benefits to the current design which I'm overlooking?
>>
>> With a non-scoped extern(c++) we could simply use two files.
> 
> 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).

I have to take this to mean that you are someone who wants 1:1 correspondence, and not someone who puts 2 namespaces in the same file with identical symbol names.

In either case, I think it's forgivable for D to not be able to completely mimic C++ in every possible manner.

> Besides, I provided solutions for both Manu's case and Atila's (they are different), which are easier than "simply" breaking things up into multiple files.

But the solution is crazy backwards. You should be able to put in weird aliases and namespaces (or even split into multiple modules) if you have really crappy C++ code with namespace issues. Aliases and bizarre mixins shouldn't be the default *just in case* you have crappy code.

Note, I can do this to make namespaces if I want to mimic crappy C++ code in the same file (assuming extern(C++, ns) just affects mangling):

template _ns()
{
    extern(C++, ns) void foo(int) {}
}
alias ns = _ns!();
alias foo = ns.foo; // optional
template _ns2()
{
    extern(C++, ns2) void foo(int) {}
}
alias ns2 = _ns2!();
alias foo = ns2.foo; // optional

void main()
{
    // foo(1); // ERROR!
    ns.foo(1); // OK
    ns2.foo(1); // OK
}

Why can't we just tell C++ devs who have this horrible situation to do it this way, and leave all the reasonably named namespaces to use the awesome D module system as expected?

-Steve

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.

> That's the idea behind DPP.  You can just #include C headers and they will be translated before compile time.  This is very helpful with projects like HDF5 that consider it acceptable in a minor release to replace a function with a macro.
>
> Wrappers are a bit different.
>
> In time C++ will follow.

I wouldn't call that the same thing as what generally defines a wrapper. It's a different concept that does the work at compiler time. If I remember correctly Clang has something similar, where two languages can call each other once they have been compiled to Clang's intermediate format. Or at least it was something that was being worked on a while ago, never used it though.

>> Not only that, who do you think even writes bindings for libraries? Most bindings are done by the community for libraries to other languages. How many companies do you know have bindings for their C/C++ libraries for D, that maintains them?
>
> We do for a few things - for other peoples' libraries not our own.  But it would be better not to have to write bindings at all.

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

>> damn hell no. That's what modules are for. So why are you trying to implement namespaces in D under the guise of C++ name mangling.
>
> I don't think either Manu or Atila want to be able to sneak in namespaces by the backdoor.  They just want to be able easily to control namespace mangling of C++ linkage symbols.

Never said they did, but that's what Walter and the current implementation seem to indicate. I'd rather just have extern(C++) be what extern(C++) and extern(D) do, just change the name mangling, not try to emulate some features of namespaces like it currently does.

> What extern(C++) should be used for is allowing you
>> to call C++ code from D, not to be able to format C++ code into D. The only problem you have with breaking code up into multiple files is that it isn't 1:1. That's not a technical problem, it's a problem of conflicting personal opinion. If it's not 1:1, who cares? If some some odd reason you have two namespaces in one file in C++, odds are they are probably separated in that one file anyway. If not and for some reason the the code has multiple namespace definitions smashed together into one file, flip-floping between namespaces. That's not D's problem to fix the project's poor organization method.
>
> For automatically translated bindings I think that the request is not unreasonable because there's considerable value in being able to just #include C++ headers as you can already with C headers and just call the C++ code from D.  D doesn't have libraries?  Well it's got 1500 on code.dlang.org plus C and C++ libraries.  What is it you think is missing?  That's a good retort!
>
> I understand from Atila present choice just makes it a lot more complicated, not impossible.

The only person I've seen that wants this is Walter. I haven't seen anyone else show interest in wanting a 1:1 correlation. It's unreasonable, D isn't C++ nor should it be trying to strive to be C++.

Where are const pointers? Where are default constructors for structs that make structs not POD anymore, that changes the calling convention used in C++ (on Windows at least).

On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
> If we want to support interfacing with C++, we have to support badly written C++, because that is the NORMAL case. Telling them their code is **** and that they should rewrite it in order to work with D is never, ever going to work.

On another note, why aren't const pointers to mutable data supported then? Anytime I need to write a wrapper for a function that has a parameter "T* const" I have to rewrite the C++ code cause there's no cross-platform way to mangle and call that function from D.

Does this mean you are for const pointers in D now or is trying to make D into C++ unreasonable now ?

On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d wrote:
> The only person I've seen that wants this is Walter. I haven't seen anyone else show interest in wanting a 1:1 correlation. It's unreasonable, D isn't C++ nor should it be trying to strive to be C++.

In general, it's easier for maintenance if there's a 1:1 correlation between C/C++ headers and D headers. It makes it easier to update the D files, and it makes it easier to find where something is in the D translation if you're already familiar with the C/C++ version - or if you're reading documentation for the C/C++ version and trying to translate that into what you need to know to use the D version. For the most part, the C bindings in druntime follow the layout of the C headers that they correspond to precisely because doing so is more maintainable and easier to navigate than if the D modules were laid in a hierarchy that followed its own logic instead of trying to emulate the layout of the C headers being translated. In fact, some of the more annoying issues with the C header translations in druntime come from places where the layout of the C headers was not quite followed for one reason or another.

So, I'd fully expect most C/C++ binding projects to have a 1:1 correlation between C/C++ headers and D headers, and I don't think that Walter is at all misguided in that respect.

That being said, in most cases, such a 1:1 translation would work just fine
if we had extern(C++, "NS"), and it just affected name mangling. There would
be corner cases where it did not, but they could be worked around even if it
meant that in that particular case, you lost the 1:1 translation - but as
Steven pointed out, it actually would be pretty straightforward to manually
add the kind of namespace wrappers that the language currently forces on you
with extern(C++, NS) if we had extern(C++, "NS"). And of course, if we
actually ended up with both extern(C++, "NS"), and extern(C++, NS), then you
could just use the extern(C++, NS) construct in those corner cases, though
ultimately, I think that we'd be better off with just having
extern(C++, "NS").

So, I don't think that Walter is being misguided here in terms of how he expects folks to be translating C++ headers. I just think that his concern over some corner cases you get with bad C++ code has caused him to make the current solution for binding to C++ namespaces more complicated than it needs to be. And I don't think that his concerns are misguided either. I just think that he's just blowing them out of proportion given how easy it would be to work around those issues with the solution that Manu wants, whereas the common case suffers with the current solution.

- Jonathan M Davis

On Saturday, 4 August 2018 at 17:54:11 UTC, Jonathan M Davis wrote:
> On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d wrote:
>> The only person I've seen that wants this is Walter. I haven't seen anyone else show interest in wanting a 1:1 correlation. It's unreasonable, D isn't C++ nor should it be trying to strive to be C++.
>
> In general, it's easier for maintenance if there's a 1:1 correlation between C/C++ headers and D headers. It makes it easier to update the D files, and it makes it easier to find where something is in the D translation if you're already familiar with the C/C++ version - or if you're reading documentation for the C/C++ version and trying to translate that into what you need to know to use the D version. For the most part, the C bindings in druntime follow the layout of the C headers that they correspond to precisely because doing so is more maintainable and easier to navigate than if the D modules were laid in a hierarchy that followed its own logic instead of trying to emulate the layout of the C headers being translated. In fact, some of the more annoying issues with the C header translations in druntime come from places where the layout of the C headers was not quite followed for one reason or another.
>
> So, I'd fully expect most C/C++ binding projects to have a 1:1 correlation between C/C++ headers and D headers, and I don't think that Walter is at all misguided in that respect.
>
> That being said, in most cases, such a 1:1 translation would work just fine
> if we had extern(C++, "NS"), and it just affected name mangling. There would
> be corner cases where it did not, but they could be worked around even if it
> meant that in that particular case, you lost the 1:1 translation - but as
> Steven pointed out, it actually would be pretty straightforward to manually
> add the kind of namespace wrappers that the language currently forces on you
> with extern(C++, NS) if we had extern(C++, "NS"). And of course, if we
> actually ended up with both extern(C++, "NS"), and extern(C++, NS), then you
> could just use the extern(C++, NS) construct in those corner cases, though
> ultimately, I think that we'd be better off with just having
> extern(C++, "NS").
>
> So, I don't think that Walter is being misguided here in terms of how he expects folks to be translating C++ headers. I just think that his concern over some corner cases you get with bad C++ code has caused him to make the current solution for binding to C++ namespaces more complicated than it needs to be. And I don't think that his concerns are misguided either. I just think that he's just blowing them out of proportion given how easy it would be to work around those issues with the solution that Manu wants, whereas the common case suffers with the current solution.
>
> - Jonathan M Davis

Alright that's fair but it still isn't ever going to be 1:1. I've done some stuff with C++ that used the fact that including headers is just a copy and paste. So I had header files that didn't have structures defined in them. You would define the structures before the including the header file so that it could be used with multiple different headers. There's no way you are ever going to get a 1:1 mapping of that into D. Let alone remotely similar, it would have to be completely different.

It's nice to have but you are never going to achieve a complete 1:1 mapping unless you bring all of C++'s features. Even with the current implementation it doesn't allow multiple namespaces of the same name in the same D module. Yet Walter is hung up on that fact of that one edge case.

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.

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.