On Friday, 2 May 2014 at 00:22:14 UTC, deadalnix wrote:
2. Creating a new name lookup mechanism is the kind of idea
that sound good but ends up horribly backfiring. There is all
kind of implications and it affect every single identifier
resolution. You don't want to mess with that (especially
On 5/2/2014 12:34 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
The implications with this DIP is that all library authors will have to follow a
convention of having all C++ dependencies in a module named cpp in order to
have a fake way of specifying fully qualified C++
On Friday, 2 May 2014 at 07:44:50 UTC, Walter Bright wrote:
Not at all, any more than you have to do that for C names.
The difference is that C names tend to have their namespace
embedded:
framework_structname_function()
On Fri, 02 May 2014 01:22:12 +0100, deadalnix deadal...@gmail.com wrote:
On Thursday, 1 May 2014 at 10:03:21 UTC, Regan Heath wrote:
On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr timon.g...@gmx.ch
wrote:
If this is a problem, I guess the most obvious alternatives are to:
1. Get rid of
On Thu, 01 May 2014 21:44:10 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/1/2014 5:33 PM, deadalnix wrote:
On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
On 4/27/2014 12:54 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Now with pull request:
On Friday, 2 May 2014 at 09:25:34 UTC, Ola Fosheim Grøstad wrote:
On Friday, 2 May 2014 at 07:44:50 UTC, Walter Bright wrote:
Not at all, any more than you have to do that for C names.
The difference is that C names tend to have their namespace
embedded:
framework_structname_function()
On Friday, 2 May 2014 at 17:34:49 UTC, deadalnix wrote:
framework_structname_function()
You are only proving that you are missing the point completely.
Then I ask you to be graceful and explain it to me.
On Fri, 02 May 2014 15:06:13 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
Can you explain to people who don't understand DMD code, does this
exactly
implement the DIP?
Yes.
The two questions above imply that the DIP isn't
On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
Can you explain to people who don't understand DMD code, does this exactly
implement the DIP?
Yes.
The two questions above imply that the DIP isn't enough to
answer those questions...
It follows the scoping and name resolution rules used for
On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr timon.g...@gmx.ch wrote:
If this is a problem, I guess the most obvious alternatives are to:
1. Get rid of namespace scopes. Require workarounds in the case of
conflicting definitions in different namespaces in the same file. (Eg.
use a mixin
On Thu, 01 May 2014 11:03:21 +0100, Regan Heath re...@netmail.co.nz
wrote:
On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr timon.g...@gmx.ch wrote:
If this is a problem, I guess the most obvious alternatives are to:
1. Get rid of namespace scopes. Require workarounds in the case of
On 4/27/2014 12:54 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Now with pull request: https://github.com/D-Programming-Language/dmd/pull/3517
On Thursday, 1 May 2014 at 10:03:21 UTC, Regan Heath wrote:
On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr
timon.g...@gmx.ch wrote:
If this is a problem, I guess the most obvious alternatives
are to:
1. Get rid of namespace scopes. Require workarounds in the
case of conflicting definitions
On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
On 4/27/2014 12:54 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Now with pull request:
https://github.com/D-Programming-Language/dmd/pull/3517
Does that create a new named scope ? And regular D identifier
resolution
On 5/1/2014 5:33 PM, deadalnix wrote:
On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
On 4/27/2014 12:54 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Now with pull request: https://github.com/D-Programming-Language/dmd/pull/3517
Does that create a new named scope ?
On Wed, 30 Apr 2014 05:03:58 +0100, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Wrong KISS: compiler internals over specification
Indeed.
I've been a C/C++ developer for ~16 years and I was confused several times
reading this thread.
The mix of D modules and C++
On Wed, 30 Apr 2014 10:20:22 +0100, Regan Heath re...@netmail.co.nz
wrote:
Something else to think about.
C# has the same problem and has solved it the following way..
[main.cs]
using ..
using CSTest_Test1;
using CSTest_Test2;
namespace CSTest
{
class Program
{
static void
On 04/30/2014 02:41 AM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
...
Maybe he didn't notice that you changed the 'main' function relative
to my post. If you don't mention 'foo' explicitly, then obviously it
cannot be hidden by the
On Wed, 30 Apr 2014 15:56:15 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/30/2014 02:41 AM, Steven Schveighoffer wrote:
Wouldn't a similar test be to create a struct for a namespace?
...
Yes, and this behaves the same in this specific case.
Just a note of friendly advice, most people
On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
First off, I expect std to be put in core.stdcpp.std, and
then imported. So this issue would only happen if 3rd party A
and 4th party B each imported 5th party C. Yeah, it'll happen,
and it'll still work, as the import system
On 4/28/2014 11:06 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
First off, I expect std to be put in core.stdcpp.std, and then imported. So
this issue would only happen if 3rd party A and 4th party B each
On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote:
No, it'll happen if they use the same vector library an
#include the same
vector3D and independently specify their own binding? But if
they cooperate
and use the same binding, then you are ok? That makes no sense.
I simply don't
On 4/29/2014 12:10 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote:
No, it'll happen if they use the same vector library an #include the same
vector3D and independently specify their own binding? But if they
Basically, Ola, if you could write a piece of sample D code that you feel will
not work, please do so.
On Tuesday, 29 April 2014 at 07:50:41 UTC, Walter Bright wrote:
Basically, Ola, if you could write a piece of sample D code
that you feel will not work, please do so.
But I did?
framework1.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
On 2014-04-28 21:06, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
I believe Steven expects things to work this way:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // Calls bar.func (or
On Mon, 28 Apr 2014 17:00:11 -0400, Simen Kjærås via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C)
On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote:
Building on this knowledge:
module foo;
void func();
module bar;
extern(C++, foo) void func();
module prog;
import foo;
import bar;
void main()
{
// Seems like it's ambiguous between foo.func and bar.foo.func.
On 04/29/2014 02:01 PM, Steven Schveighoffer wrote:
That is what the DIP says:
Declarations in the namespace can be accessed without qualification in
the enclosing scope if there is no ambiguity. Ambiguity issues can be
resolved by adding the namespace qualifier
Which then proceeds to show
On Tue, 29 Apr 2014 11:47:28 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 02:01 PM, Steven Schveighoffer wrote:
That is what the DIP says:
Declarations in the namespace can be accessed without qualification in
the enclosing scope if there is no ambiguity. Ambiguity issues can be
On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
I am not familiar with the rules.
Perhaps you can just outline for me:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // works?
}
If this works, then we have a problem.
It does work.
On Tue, 29 Apr 2014 12:03:02 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
I am not familiar with the rules.
Perhaps you can just outline for me:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
On 4/29/2014 2:01 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
framework1.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
extern(C++,veclib){ struct … vec4 …; }
extern(C++,graphics){ void g(vec4 …) … }
application1.d:
import
On 4/29/2014 8:43 AM, Timon Gehr wrote:
as the DIP _does not actually introduce any new lookup rules_
[...]
In particular, any problems you find with symbol lookup are actually orthogonal
to the DIP.
Yes!
On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
But what happens when you add another import that conflicts?
module foo;
void func() {}
module prog; // updated
import bar;
import foo;
void main(){
foo.func(); // now calls foo.func, and not bar.func as it originally did,
right?
}
So by
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
But what happens when you add another import that conflicts?
module foo;
void func() {}
module prog; // updated
import bar;
import foo;
void main(){
On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
I'd do your example as:
vec.d:
extern(C++,veclib){ struct … vec4 …; }
framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }
framework2.d:
import vec;
extern(C++,graphics){ void g(vec4 …) … }
Yes, but that requires
On 4/29/2014 1:23 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
I'd do your example as:
vec.d:
extern(C++,veclib){ struct … vec4 …; }
framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }
On 4/29/2014 1:33 PM, Walter Bright wrote:
On 4/29/2014 1:23 PM, Ola Fosheim Grøstad
With graphics::g(physics::f(…)) this would not have been an issue.
It does occur to me that two C++ symbols in the same namespace may be regarded
as the same by the lookup code. That may be a reasonable
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Because the compiler would now issue an error for that, it's its
anti-hijacking feature.
Try it and see!
I agree!
On Tuesday, 29 April 2014 at 20:33:07 UTC, Walter Bright wrote:
Not really. It is reasonable to expect that when Framework1 and
Framework2 each import 4th party Vec, that they do it with an
import rather than inlining Vec's declarations.
Vectors are not the best example since one library
On 04/29/2014 10:49 PM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Because the compiler would now issue an error for that, it's its
On 4/29/14, 12:49 PM, Walter Bright wrote:
On 4/29/2014 8:43 AM, Timon Gehr wrote:
as the DIP _does not actually introduce any new lookup rules_
[...]
In particular, any problems you find with symbol lookup are actually
orthogonal
to the DIP.
Yes!
This is a biggie. KISS etc. -- Andrei
On Monday, 28 April 2014 at 01:18:04 UTC, Walter Bright wrote:
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
You can also have N.M
I've updated the DIP page to include documentation of the change
to the language grammar.
On 4/29/2014 4:08 PM, Brian Schott wrote:
I've updated the DIP page to include documentation of the change to the language
grammar.
thanks!
On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/29/2014 10:49 PM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On Tuesday, 29 April 2014 at 22:51:42 UTC, Andrei Alexandrescu
wrote:
On 4/29/14, 12:49 PM, Walter Bright wrote:
On 4/29/2014 8:43 AM, Timon Gehr wrote:
as the DIP _does not actually introduce any new lookup rules_
[...]
In particular, any problems you find with symbol lookup are
actually
On 4/27/2014 7:53 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 27 April 2014 at 20:53:31 UTC, Walter Bright wrote:
Example of what you mean, please.
If the c++ library is std:: and then later either D or C++ is expanded with a
name clash, and the externs are
On 4/27/2014 11:01 PM, Walter Bright wrote:
On 4/27/2014 7:53 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 27 April 2014 at 20:53:31 UTC, Walter Bright wrote:
Example of what you mean, please.
If the c++ library is std:: and then later either D or C++ is
On Monday, 28 April 2014 at 06:18:01 UTC, Walter Bright wrote:
What I mean is I need a specific code example of what you're
talking about, as I cannot deduce it from your statement.
I assume that the type is structural for the extern so that won't
be a problem, but if std:: is extern in
On 4/27/2014 11:30 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 28 April 2014 at 06:18:01 UTC, Walter Bright wrote:
What I mean is I need a specific code example of what you're talking about, as
I cannot deduce it from your statement.
I assume that the type is
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new
declarations cannot be inserted into a namespace after the
closing }. C++ Argument Dependent Lookup (aka Koenig Lookup)
will not
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
void main() {
A.foo(); // which foo will be called ? how to call d version or
c++ ?
}
There's no linker problem because D and C++ has different name
mangling.
On Monday, 28 April 2014 at 06:47:08 UTC, Walter Bright wrote:
I have no idea what a type being structural for the extern
means.
structural is the wrong word. I meant that if two D frameworks
bind the same c++ library you want the two externs to be
interchangable in user code. However if D
On Monday, 28 April 2014 at 07:45:20 UTC, Temtaime wrote:
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
void main() {
A.foo(); // which foo will be called ? how to call d version or
c++ ?
}
This is close.
This is close. Forgive inaccurate syntax, but I see at least these
issues that will make namespaces/module-system broken in terms of
maintenance:
YEAR 2014:
framework1.d:
extern (C++, std){ void something(); }
framework2.d:
extern (C++,std){void something(); void anything();}
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
http://wiki.dlang.org/DIP61
I really like this. I think it is clean simple and a better approach then
adding the namespace keyword. Plus when people come to D from C++ they
wont misuse namespace.
Since D has awesome module aliasing
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer
wrote:
Not ok. This is like having 2 definitions for the same
function, linker will not accept that.
No. It is like having 2 matching type declarations. The
implementation is defined in the C++ source code and is
represented as
On Mon, 28 Apr 2014 10:00:56 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer wrote:
Not ok. This is like having 2 definitions for the same function, linker
will not accept that.
No. It is like having 2
On Monday, 28 April 2014 at 14:08:56 UTC, Steven Schveighoffer
wrote:
I see now where your objection is. I think either the rule
needs to be better explained, or that it is incorrect.
I think so too, because if my undestanding is correct then it
will discourage writing libs in mixed D/C++ and
On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright
newshou...@digitalmars.com wrote:
http://wiki.dlang.org/DIP61
I think there is a big problem with name lookup here.
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
On Mon, 28 Apr 2014 10:27:19 -0400, Steven Schveighoffer wrote:
On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright
newshou...@digitalmars.com wrote:
http://wiki.dlang.org/DIP61
I think there is a big problem with name lookup here.
Consider this code:
module foo;
void func() {}
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Would nesting imported namespaces work?
lib/package.d
public
export(C++, a) {
public import lib.b;
}
lib/b.d
export(C++, b) {
void foo();
}
main.d
import lib;
a.b.foo();
On Mon, 28 Apr 2014 10:37:36 -0400, Byron byron.he...@gmail.com wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous. With this proposal, you
have hijacked the meaning of namespace lookup. When I say x.y.z, it
doesn't just mean look for symbol z in
On Mon, 28 Apr 2014 10:50:09 -0400, Byron byron.he...@gmail.com wrote:
On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 10:37:36 -0400, Byron byron.he...@gmail.com wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous.
On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 10:37:36 -0400, Byron byron.he...@gmail.com wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous. With this proposal,
you have hijacked the meaning of namespace lookup.
On Mon, 28 Apr 2014 10:46:33 -0400, Byron byron.he...@gmail.com wrote:
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Would nesting imported namespaces work?
lib/package.d
public
export(C++, a) {
public import lib.b;
}
lib/b.d
export(C++, b) {
On Mon, 28 Apr 2014 10:56:24 -0400, Steven Schveighoffer wrote:
Most definitely no. When the compiler builds b.d, he has no idea it's
imported from inside another namespace! We don't want #include-style
issues.
-Steve
So we would have to include the entire namespace in a single d file
or
On Mon, 28 Apr 2014 10:54:17 -0400, Steven Schveighoffer wrote:
That doesn't help. foo.func() is still ambiguous. With this proposal,
you have hijacked the meaning of namespace lookup. When I say x.y.z,
it doesn't just mean look for symbol z in module x/y.d, it can also
mean to look for
On Monday, 28 April 2014 at 14:54:17 UTC, Steven Schveighoffer
wrote:
Adding a mechanism that is possibly ugly, but that does NOT
conflict with module lookup, in order to disambiguate C++
symbols is fine.
Requiring C++ identifiers to be fully qualified with :: would
solve that and encourage
On Mon, 28 Apr 2014 11:05:25 -0400, Byron byron.he...@gmail.com wrote:
On Mon, 28 Apr 2014 10:56:24 -0400, Steven Schveighoffer wrote:
Most definitely no. When the compiler builds b.d, he has no idea it's
imported from inside another namespace! We don't want #include-style
issues.
-Steve
On Mon, 28 Apr 2014 11:09:38 -0400, Byron byron.he...@gmail.com wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d
extern(C++, std) { ... class string ... }
class string now has two fully-qualified names. a.string, and std.string
(assuming the current DIP is
On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 11:09:38 -0400, Byron byron.he...@gmail.com wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d extern(C++, std) { ... class string ... }
class string now has two fully-qualified
On Mon, 28 Apr 2014 11:32:50 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 28 April 2014 at 14:27:19 UTC, Steven Schveighoffer wrote:
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling foo::func from
C++ land!
}
I
On Monday, 28 April 2014 at 14:27:19 UTC, Steven Schveighoffer
wrote:
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling
foo::func from C++ land!
}
I don't see any fundamental issue here because you can still use
renamed
On Mon, 28 Apr 2014 11:29:53 -0400, Byron byron.he...@gmail.com wrote:
On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 11:09:38 -0400, Byron byron.he...@gmail.com wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d extern(C++,
On 4/28/2014 12:45 AM, Temtaime wrote:
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
Error, A is defined twice.
On 4/28/2014 4:29 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
This is close. Forgive inaccurate syntax, but I see at least these issues that
will make namespaces/module-system broken in terms of maintenance:
YEAR 2014:
framework1.d:
extern (C++, std){ void something(); }
On 4/28/2014 1:31 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
So recompiling with updated libraries may cause failure?
No more than if you violate the ODR in C++, or if you do this entirely in D.
Ambiguities for the latter will cause compile time errors (which is a
On Monday, 28 April 2014 at 14:00:58 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer
wrote:
Not ok. This is like having 2 definitions for the same
function, linker will not accept that.
No. It is like having 2 matching type declarations. The
On 4/28/2014 6:55 AM, Byron wrote:
With the current DIP you have to combine the d/di files to merge the
extern namespaces.
No, you will not have to, for the same reason that all extern(C) declarations
don't have to be in the same module.
Also is there any plans on dealing with newing c++
On 4/28/2014 12:18 AM, Sergei Nosov wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new declarations
cannot be inserted into a namespace after the closing }. C++ Argument
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
bar.func(); // ok, uses C binding (no name mangling)
}
In this
On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
I believe Steven expects things to work this way:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // Calls bar.func (or is that bar.foo.func?)
}
It would call bar.foo.func(). But
On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
On 4/28/2014 4:29 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
No. Even though they are the same function as far as the
signatures are concerned, they are different functions as far
as the D type system is
On 4/28/2014 4:30 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
On 4/28/2014 4:29 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
No. Even though they are the same function as far as the
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Sounds awesome.
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Without aliasing and with a unified scope operator you will get
name clashes between D and C++. You should address why this is
not an issue (e.g. practical and not tedious).
On 4/27/2014 1:44 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Without aliasing and with a unified scope operator you will get name clashes
between D and C++. You should address
On Sun, Apr 27, 2014 at 2:54 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
http://wiki.dlang.org/DIP61
What happens if you try to interface with two different C++ libraries that
use the same exact namespaces?
On 4/27/2014 3:07 PM, Caligo via Digitalmars-d wrote:
On Sun, Apr 27, 2014 at 2:54 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
http://wiki.dlang.org/DIP61
What happens if you try to interface with two different C++ libraries
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
On 4/27/2014 5:58 PM, Brian Schott wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
You can also have N.M
On Sunday, 27 April 2014 at 20:53:31 UTC, Walter Bright wrote:
Example of what you mean, please.
If the c++ library is std:: and then later either D or C++ is
expanded with a name clash, and the externs are auto generated,
e.g. std.something appears on both sides, what happens then
when you
95 matches
Mail list logo
