On 8/7/2018 3:49 AM, Atila Neves wrote:
Yes, I've already implemented it.
Wonderful!
I'm not sure what the impact will be with nested namespaces in real headers. I
guess we'll have to see.
Yes.
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Yes,
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
On 8/7/2018 1:13 AM, Walter Bright wrote:
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
BTW, the
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Almost.
On Tuesday, 7 August 2018 at 05:58:17 UTC, Walter Bright wrote:
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to not have a namespace, I don't see what making an alias to a
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Yes,
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate working code that
behaves "as if" the namespace scope is not there, even for nested namespaces.
Is this correct?
On 8/5/2018 9:53 PM, Manu wrote:
If we produce a DIP to fix this, will you reject it in principle?
Producing a DIP is a good idea, it provides an anchor point for any future
discussion of the topic, rather than the tangle and noise that is this thread.
It is an ample opportunity to put the
On 8/6/2018 3:19 PM, tide wrote:
That's just a deflection,
1. I'm only here to help, and am not interested in scoring debate points.
2. To bring up other topics, please start a new thread. Especially since this
one is quite voluminous.
On Monday, 6 August 2018 at 20:35:37 UTC, Walter Bright wrote:
On 8/6/2018 11:26 AM, tide wrote:
What's your crossplatform workaround if I have a namespace
named "version" or "package" ?
See my reply to Rick Cattermole.
On 8/6/2018 11:26 AM, tide wrote:
What's your crossplatform workaround if I have a namespace named "version" or
"package" ?
See my reply to Rick Cattermole.
https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507
You also
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
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
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
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
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
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;
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
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
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
On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d
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,
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 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
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
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
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
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
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.
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
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
On Wed, 1 Aug 2018 at 16:05, Walter Bright via Digitalmars-d
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.
>
>
On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
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
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
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
On 8/2/2018 2:26 AM, Daniel N wrote:
Personally I would never *bind* to two different namespaces in
a single file,
You'd be amazed at what people do and then set their entire
store based on it. If the language spec allows it,
On 8/3/2018 3:58 AM, Atila Neves wrote:
With your mixin template technique everything ends up in the global namespace of
the moduel making the C++ declarations.
Right, but that's what you wanted!
I would only be able to alias a nested
namespace once, since the code below obviously won't
On 8/2/2018 2:26 AM, Daniel N wrote:
Personally I would never *bind* to two different namespaces in a single file,
You'd be amazed at what people do and then set their entire store based on it.
If the language spec allows it, people will do it. People will even design their
code to require
On Friday, 27 July 2018 at 23:15:44 UTC, Laeeth Isharc wrote:
Because it's getting in the way of a decent prize - to be able
just to #include CPP headers and link with C++.
Just wanted to +100 on this one
Having this feature, and if marketed well, can be huge for D
This is 10 times a
On Friday, 3 August 2018 at 10:58:18 UTC, Atila Neves wrote:
On Wednesday, 1 August 2018 at 23:31:57 UTC, Walter Bright
wrote:
[...]
Good point.
[...]
We can also just keep the current behaviour and implement
something like extern(C++, "std::chrono") in addition (as manu
pointed out
On Friday, 3 August 2018 at 10:58:18 UTC, Atila Neves wrote:
I thought about it some more and managed to make it work. It's
definitely a hack, but since in my case the user won't usually
see the generated code anyway it's not too bad. It's far from
ideal, though, because I can't alias an
On Wednesday, 1 August 2018 at 23:31:57 UTC, Walter Bright wrote:
On 7/31/2018 1:47 AM, Atila Neves wrote:
The only good way (I don't think the mixin template and struct
solutions count) to link to any of that today would be to have
one enormous D file with _everything_ in it, including nested
On 03/08/2018 9:12 AM, Walter Bright wrote:
On 8/2/2018 2:05 AM, rikki cattermole wrote:
8. if any identifier starts with a keyword and ends with at minimum
one _, one _ from the end of the identifier will be removed for
mangling (but not e.g. lookup).
This will break existing code. A double
On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright
wrote:
An example of silent hijacking:
extern (C++, "ab") void foo(long); // original code
... lots of code ...
extern (C++,
On 8/2/2018 9:58 AM, Manu wrote:
Have you ever tried the alias method I proposed?
Of course, it's the only tool we have here, and a major source of my
frustration!
Why is it frustrating?
On 8/2/2018 2:05 AM, rikki cattermole wrote:
8. if any identifier starts with a keyword and ends with at minimum one _, one _
from the end of the identifier will be removed for mangling (but not e.g. lookup).
This will break existing code. A double underscore prefix is reserved for the
On Thu, 2 Aug 2018 at 02:05, Walter Bright via Digitalmars-d
wrote:
>
> On 8/1/2018 11:08 PM, Manu wrote:
> > We have demonstrated consistent ongoing issues and frustration for 6
> > years.
>
> Have you ever tried the alias method I proposed?
Of course, it's the only tool we have here, and a
On Thursday, 2 August 2018 at 12:30:14 UTC, rikki cattermole
wrote:
On 03/08/2018 12:24 AM, Steven Schveighoffer wrote:
I've never seen it, but it's certainly valid C++ and in the
realm of possibility.
-Steve
I see, thanks.
That's easy to solve.
Split into a package, public import
On 03/08/2018 12:24 AM, Steven Schveighoffer wrote:
The example that Walter keeps bringing up is one where the C++ code has
2 namespaces in the same header file. Not only that, but then
identically named functions in those namespaces. In that case, a direct
translation would cause problems
On 8/2/18 5:26 AM, Daniel N wrote:
On Thursday, 2 August 2018 at 08:31:28 UTC, Walter Bright wrote:
On 8/1/2018 10:06 PM, Johannes Pfau wrote:
I guess that would be acceptable if there is a real benefit, but I have
not seen a single argument for the current behavior in this thread.
Please
On 8/1/18 7:04 PM, Walter Bright 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,
On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
The difference is those names are supposedly in different
namespaces, given that the code is converted from C++:
namespace ab { void foo(long); }
... lots of code ...
namespace cd { void foo(int); }
where the
On Wed, 01 Aug 2018 16:04:01 -0700, Walter Bright 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
On Thursday, 2 August 2018 at 08:31:28 UTC, Walter Bright wrote:
On 8/1/2018 10:06 PM, Johannes Pfau wrote:
I guess that would be acceptable if there is a real benefit,
but I have
not seen a single argument for the current behavior in this
thread.
Please read my postings in this thread,
On 02/08/2018 8:59 PM, Walter Bright wrote:
If this problem were to be solved, it should be solved, not hacked for
one case only. There are many ways of dealing with it:
1. pragma(mangle)
2. change the names in the C/C++ side
3. use a macro -Dwith=with_ when compiling the C/C++ code
4.
On 8/1/2018 11:08 PM, Manu wrote:
We have demonstrated consistent ongoing issues and frustration for 6
years.
Have you ever tried the alias method I proposed?
On 8/1/2018 11:08 PM, Manu wrote:
I think implementing the string alternative is the only robust way
forward, because that also solves the additional problem of being able
to name C++ namespaces that are invalid D keywords, which has bitten
me in at least 2 particularly noteworthy occasions.
On 8/1/2018 10:06 PM, Johannes Pfau wrote:
I guess that would be acceptable if there is a real benefit, but I have
not seen a single argument for the current behavior in this thread.
Please read my postings in this thread, then.
Am Wed, 01 Aug 2018 22:13:05 -0700 schrieb Walter Bright:
> On 8/1/2018 12:01 PM, Manu wrote:
>> You've never justified the design complexity and the baggage it
>> carries.
> Don't confuse you not agreeing with it with I never justified it.
>
> And please don't confuse me not listening to you
On Wed, 1 Aug 2018 at 22:15, Walter Bright via Digitalmars-d
wrote:
>
> On 8/1/2018 12:01 PM, Manu wrote:
> > You've never justified the design
> > complexity and the baggage it carries.
> Don't confuse you not agreeing with it with I never justified it.
>
> And please don't confuse me not
Am Wed, 01 Aug 2018 16:04:01 -0700 schrieb Walter Bright:
>
> 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
Am Wed, 01 Aug 2018 16:04:01 -0700 schrieb Walter Bright:
>> 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.
On 8/1/2018 12:01 PM, Manu wrote:
You've never justified the design
complexity and the baggage it carries.
Don't confuse you not agreeing with it with I never justified it.
And please don't confuse me not listening to you with me not agreeing with you.
It *is* possible for reasonable people
Am Wed, 01 Aug 2018 16:31:57 -0700 schrieb Walter Bright:
> On 7/31/2018 1:47 AM, Atila Neves wrote:
>> The only good way (I don't think the mixin template and struct
>> solutions count)
>> to link to any of that today would be to have one enormous D file with
>> _everything_ in it, including
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright wrote:
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
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright wrote:
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
On 7/31/2018 1:47 AM, Atila Neves wrote:
The only good way (I don't think the mixin template and struct solutions count)
to link to any of that today would be to have one enormous D file with
_everything_ in it, including nested namespaces.
Why doesn't it count? The user doesn't need to write
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
On Wed, 1 Aug 2018 at 03:05, Walter Bright via Digitalmars-d
wrote:
>
> > Was that a deliberate
> > strategy? I feel like that strategy's been used before.
>
> You repeatedly impugn my motives and/or my mental stability. While that
> doesn't
> bother me, it really does not help your case.
I'm
On Wed, 1 Aug 2018 at 10:25, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Wednesday, August 1, 2018 4:02:39 AM MDT Walter Bright via Digitalmars-d
> wrote:
> > On 7/31/2018 1:12 AM, Manu wrote:
> > > Given your favourite example:
> > >
> > > module a;
> > > extern(C++, ns) void foo();
>
On Wednesday, August 1, 2018 4:02:39 AM MDT Walter Bright via Digitalmars-d
wrote:
> On 7/31/2018 1:12 AM, Manu wrote:
> > Given your favourite example:
> >
> > module a;
> > extern(C++, ns) void foo();
> >
> > module b;
> > extern(C++, ns) void foo();
> > -
> > module c;
> > import
On Wed, 1 Aug 2018 at 02:10, Walter Bright via Digitalmars-d
wrote:
>
> On 7/31/2018 3:34 PM, Laeeth Isharc wrote:
> > On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote:
> >> On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
> >>> Can you think of a pragmatic solution to Atila's problem?
>
On 7/31/2018 1:12 AM, Manu wrote:
Given your favourite example:
module a;
extern(C++, ns) void foo();
module b;
extern(C++, ns) void foo();
-
module c;
import a, b;
foo(); // error: ambiguous
ns.foo(); // error, ambiguous (obviously)
a.ns.foo(); // naturally, this works... it's the
On 7/31/2018 1:43 AM, Atila Neves wrote:
It's not the same - if I want to link to std::vector and std::string, I'd expect
them to be used in D as std.vector and std.string, not std.vector and
HackyDThing0.std.string.
Calling them std.string will already cause problems, because there's an
On 7/31/2018 3:34 PM, Laeeth Isharc wrote:
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote:
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the members of a
namespace
On Tuesday, 31 July 2018 at 23:02:16 UTC, Rubn wrote:
One thing I don't like is that the C++ namespaces takes the
name. So if you try to import a module that has C++ namespace
of the same with the existing module, then you'll get an error.
For effectively no reason, because as you say that
On Tuesday, 31 July 2018 at 16:23:55 UTC, Manu wrote:
On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via
Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
On 2018-07-31 10:12, Manu wrote:
> Given your favourite example:
>
> module a;
> extern(C++, ns) void foo();
>
> module b;
>
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote:
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the
members of a namespace before trying to emit them. Since D does
not
On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 2018-07-31 10:12, Manu wrote:
>
> > Given your favourite example:
> >
> > module a;
> > extern(C++, ns) void foo();
> >
> > module b;
> > extern(C++, ns) void foo();
> > -
> >
On 2018-07-31 10:12, Manu wrote:
Given your favourite example:
module a;
extern(C++, ns) void foo();
module b;
extern(C++, ns) void foo();
-
module c;
import a, b;
foo(); // error: ambiguous
ns.foo(); // error, ambiguous (obviously)
a.ns.foo(); // naturally, this works... it's the
On Tuesday, 31 July 2018 at 08:33:52 UTC, Daniel N wrote:
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will
use that fork of D
On Tuesday, 31 July 2018 at 08:33:52 UTC, Daniel N wrote:
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will
use that fork of D
On Monday, 30 July 2018 at 20:23:25 UTC, Walter Bright wrote:
On 7/30/2018 9:45 AM, Manu wrote:
Sure it 'works', but it's an annoying point of friction, and it
doesn't need to be that way.
You can reduce it to:
mixin(cppNamespace("ns", "void foo();"));
You haven't explained why you
On Monday, 30 July 2018 at 19:51:09 UTC, Walter Bright wrote:
On 7/30/2018 6:45 AM, Atila Neves wrote:
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
On Tuesday, 31 July 2018 at 06:12:40 UTC, Walter Bright wrote:
Thirdly, C and C++ are loaded to the gills with
seemed-like-a-good-idea-at-the-time solutions that turned out
to have bad unintended consequences that bork up the language
for everyone down the line. D has some of those, too.
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will use
that fork of D forever.
1. Look how it is mangled on the C++ side. (Use
On Mon, 30 Jul 2018 at 23:15, Walter Bright via Digitalmars-d
wrote:
>
> My issue is you're presenting solutions. But I have no idea what the problem
> is,
> because every time I present a solution to the examples you give, you say it's
> no good, because your problem is something else.
I'm not
My issue is you're presenting solutions. But I have no idea what the problem is,
because every time I present a solution to the examples you give, you say it's
no good, because your problem is something else.
I cannot reverse engineer what the issue is from your proposed solution.
My second
On 7/30/2018 2:12 PM, Manu wrote:
We're all happy with the D
module system, that's how we want to organise our code. Please let us
organise our code using the D module system.
I have literally no idea what you mean. That's why I suggest you show what your
C++ code looks like, and what you
On 29.07.2018 09:37, Walter Bright wrote:
On 7/28/2018 11:06 PM, Nicholas Wilson wrote:
Then again I don't see any (non philosophical/compiler front end
internal) issue why you can't reopen a namespace. D is supposed to be
pragmatic, after all.
Consider if a template reopens a namespace and
On Mon, 30 Jul 2018 at 13:25, Walter Bright via Digitalmars-d
wrote:
>
> On 7/30/2018 9:45 AM, Manu wrote:
> > Sure it 'works', but it's an annoying point of friction, and it
> > doesn't need to be that way.
>
> You can reduce it to:
>
> mixin(cppNamespace("ns", "void foo();"));
>
>
> >> You
On 7/30/2018 9:45 AM, Manu wrote:
Sure it 'works', but it's an annoying point of friction, and it
doesn't need to be that way.
You can reduce it to:
mixin(cppNamespace("ns", "void foo();"));
You haven't explained why you can't just move the namespace ns declarations in
one file
On 7/30/2018 6:48 AM, Atila Neves wrote:
This doesn't work for templates. If it did I wouldn't have an issue since
libclang tells me what the mangling is.
You're right.
On 7/30/2018 5:07 AM, Daniel N wrote:
I tried that but it mangles wrong.. it includes "S1" which is not what you want,
You're right, and I fixed that in a reply to Atila.
On 7/30/2018 7:20 AM, Atila Neves wrote:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
{
extern (C++, ns) { int bar() { return 2; } }
}
mixin X!() x;
---
void main() {
pragma(msg, __traits(allMembers, ns));
foo;
bar;
}
$ dmd foo.d
tuple("foo")
On 7/30/2018 1:05 PM, Walter Bright wrote:
I'll look into this.
Check this:
---
extern (C++, ns) { int foo(); }
mixin template X() { extern (C++, ns) int bar(); }
mixin X!() x;
alias bar = x.ns.bar;
void main() {
foo();
bar();
pragma(msg, foo.mangleof);
On 7/30/2018 6:45 AM, Atila Neves wrote:
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to mangle symbols.
Namespaces have semantic implications, too, such as overload
On 7/30/18 12:45 PM, Manu wrote:
On Mon, 30 Jul 2018 at 01:45, Walter Bright via Digitalmars-d
wrote:
On 7/29/2018 8:05 PM, Manu wrote:
ab.d
--
module ab;
extern(C++, "ab") void foo();
cd.d
--
module cd;
extern(C++, "cd") void foo();
Perfect!
extern(C++, ab) void foo();
On 7/30/2018 6:47 AM, Atila Neves wrote:
As mentioned in the original post, the gathering is going to be incredibly
annoying
If you did it manually, sure. But altering the translator to do it?
and I suspect I'll run into problems with macros.
I thought you were running the preprocessor
On Mon, 30 Jul 2018 at 01:45, Walter Bright via Digitalmars-d
wrote:
>
> On 7/29/2018 8:05 PM, Manu wrote:
> > ab.d
> > --
> > module ab;
> > extern(C++, "ab") void foo();
> >
> >
> > cd.d
> > --
> > module cd;
> > extern(C++, "cd") void foo();
> >
> > Perfect!
>
>extern(C++, ab) void
On Sunday, 29 July 2018 at 07:45:35 UTC, Walter Bright wrote:
On 7/28/2018 9:23 PM, Manu wrote:
Don't troll me on this one, this is a very sensitive topic!
I could have a legit mental breakdown ;)
Here's another method:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote:
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the
members of a namespace before trying to emit them. Since D does
not
1 - 100 of 143 matches
Mail list logo
