Re: DIP61: Add namespaces to D
On 27/04/14 21:39, Walter Bright wrote: std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way. It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :) -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
On 4/27/2014 11:17 PM, Jacob Carlborg wrote: On 27/04/14 21:39, Walter Bright wrote: std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way. It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :) We've known it for a long time, but nobody has done anything about it. For example, the new package.d feature was specifically designed so that long modules can be broken up without breaking user code. Nobody has yet modified any Phobos code to actually do this.
Re: DIP61: Add namespaces to D
On 4/27/14, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
When you find yourself doing things like that, seriously consider creating a
new
module to do it, called clock.
That's not reliable, because static imports are not enforced. It means
anyone importing a module clock will automatically have all symbols
in clock imported into the current module, meaning this will work:
-
import clock;
void main()
{
auto time = currTime(); // note the lack of full qualification
}
-
std.datetime rightly tries to discourage symbol pollution by default
(it has a lot of symbols to begin with). So you're forced to write:
-
import std.datetime;
void main()
{
auto time = Clock.currTime();
}
-
Using smaller modules under packages is a much better way.
Sorry, but this is currently impossible. Programmers will always use
the feature that actually works over a feature that might work some
day. Modules have too many open bugs right now, such as leaking
selective imports, private visibility, non-propagating package access,
etc etc.
If you ever try to build a larger library you'll immediately become
aware of these issues.
Re: DIP61: Add namespaces to D
On 4/28/14, Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote: It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :) Really? I've seen everyone complain about it from day 1.
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljjmi6$16nk$1...@digitalmars.com...
Ok, I saw that, and replied to it earlier this thread.
Yes, but you seemed to miss the point.
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We have MODULES to deal with conflicts. We do NOT need to add a new type of
scope to D just for C++ namespaces.
You deal with conflicts the SAME WAY you do with normal symbols - put them
in different modules.
This is more powerful, because it doesn't force you to match the namespace
layout in your D code.
Re: DIP61: Add namespaces to D
On Sun, 27 Apr 2014 23:49:41 -0700 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/27/2014 11:17 PM, Jacob Carlborg wrote: On 27/04/14 21:39, Walter Bright wrote: std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way. It's taken an amazingly long time for the core developers to realize this. I'm glad it's happened tough :) We've known it for a long time, but nobody has done anything about it. For example, the new package.d feature was specifically designed so that long modules can be broken up without breaking user code. Nobody has yet modified any Phobos code to actually do this. It's my fault as far as std.datetime goes. I had it mostly done last summer but then didn't have time to finish it, and enough has changed since then that I'm going to have to start over. And life has been quite hectic for me, making it so that I'm not getting to stuff like this as soon as I'd like. I hope to get back to it soon though. It's long past time that it get done. - Jonathan M Davis
Re: DIP61: Add namespaces to D
On 4/28/14, Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: It's my fault as far as std.datetime goes. I had it mostly done last summer but then didn't have time to finish it, and enough has changed since then that I'm going to have to start over. And life has been quite hectic for me, making it so that I'm not getting to stuff like this as soon as I'd like. I hope to get back to it soon though. It's long past time that it get done. Hey if you're out of time, let us know. Maybe give us just a small guide on where to move things around, and we'll take it from there and split it up into packages.
Re: DIP61: Add namespaces to D
On 28/04/14 10:14, Andrej Mitrovic via Digitalmars-d wrote: Really? I've seen everyone complain about it from day 1. When I started to complain about having too big modules nobody agreed. -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
On 28/04/14 08:49, Walter Bright wrote: We've known it for a long time, but nobody has done anything about it. For example, the new package.d feature was specifically designed so that long modules can be broken up without breaking user code. Nobody has yet modified any Phobos code to actually do this. I've been complaining about it long before people even started to thinking about package.d. Nobody agreed. -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
On 4/28/14, Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote: When I started to complain about having too big modules nobody agreed. Just join #d and issue the command: !quote datetime :P
Re: DIP61: Add namespaces to D
On Mon, 28 Apr 2014 10:45:40 +0200 Andrej Mitrovic via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/28/14, Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: It's my fault as far as std.datetime goes. I had it mostly done last summer but then didn't have time to finish it, and enough has changed since then that I'm going to have to start over. And life has been quite hectic for me, making it so that I'm not getting to stuff like this as soon as I'd like. I hope to get back to it soon though. It's long past time that it get done. Hey if you're out of time, let us know. Maybe give us just a small guide on where to move things around, and we'll take it from there and split it up into packages. I think that I can get to it soon (though unfortunately, I've thought that for a while now and still haven't reached that point). My current plan is to make a number of smaller pull requests to clean it up a bit first. I started with https://github.com/D-Programming-Language/phobos/pull/2088 but it's blocked by a compiler bug. And since it could be a while before that's fixed, I should probably just do some other pull requests to do more of the cleanup and deal with the merge conflicts that it causes. At least Andrei already removed _assertPred, so I don't have to deal with that (and that made splitting std.datetime more of a pain from what I recall - particularly since I was trying to remove it at the same time, which wasn't a good idea). - Jonathan M Davis
Re: DIP61: Add namespaces to D
On Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/27/14, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
When you find yourself doing things like that, seriously consider
creating a
new
module to do it, called clock.
That's not reliable, because static imports are not enforced. It means
anyone importing a module clock will automatically have all symbols
in clock imported into the current module, meaning this will work:
-
import clock;
void main()
{
auto time = currTime(); // note the lack of full qualification
}
-
And actually, this would have to be std.clock.currTime
(std.datetime.clock.currTime?)
What you are looking for is renamed imports.
import std.datetime.clock = clock;
Which cannot be enforced. and that is really the problem.
-Steve
Re: DIP61: Add namespaces to D
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On 4/27/14, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
When you find yourself doing things like that, seriously
consider creating a
new
module to do it, called clock.
That's not reliable, because static imports are not enforced.
It means
anyone importing a module clock will automatically have all
symbols
in clock imported into the current module, meaning this will
work:
-
import clock;
void main()
{
auto time = currTime(); // note the lack of full
qualification
}
-
And actually, this would have to be std.clock.currTime
(std.datetime.clock.currTime?)
What you are looking for is renamed imports.
import std.datetime.clock = clock;
Which cannot be enforced. and that is really the problem.
-Steve
static module?
Re: DIP61: Add namespaces to D
On Sat, 26 Apr 2014 05:31:51 -0400, Walter Bright
newshou...@digitalmars.com wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't match. Need a simple and straightforward method of indicating
namespaces.
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach
would be better.
As more and more people are attempting to call C++ libraries from D,
this is getting to be a more and more important issue.
Just reviewed the DIP, I've been following the discussion.
One possible issue, to which I think I know the answer but it should be
explicit, is conflicting top-level functions and namespace functions:
extern(C++, N) { void foo();}
extern(C++) void foo();
Clearly, calling N.foo would be unambiguous, but there is no namespace to
qualify the global foo. I'm assuming .foo() would work, but this should be
explicit in the DIP. Right now it says use the namespace to qualify
ambiguous calls.
I think the proposal looks good to me.
-Steve
Re: DIP61: Add namespaces to D
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot pub...@dicebot.lv wrote: On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer wrote: And actually, this would have to be std.clock.currTime (std.datetime.clock.currTime?) What you are looking for is renamed imports. import std.datetime.clock = clock; Which cannot be enforced. and that is really the problem. -Steve static module? I haven't heard of that feature, is that a proposal? doesn't seem to work in the latest release. BTW, I got my syntax wrong, it should be: import clock = std.datetime.clock; -Steve
Re: DIP61: Add namespaces to D
On Monday, 28 April 2014 at 13:54:05 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot pub...@dicebot.lv
wrote:
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
And actually, this would have to be std.clock.currTime
(std.datetime.clock.currTime?)
What you are looking for is renamed imports.
import std.datetime.clock = clock;
Which cannot be enforced. and that is really the problem.
-Steve
static module?
I haven't heard of that feature, is that a proposal? doesn't
seem to work in the latest release.
BTW, I got my syntax wrong, it should be:
import clock = std.datetime.clock;
-Steve
Yeah, it is just a random idea I have just had. Something like
this:
// a.d
static module a;
void foo() {}
// b.d
import a; // error
import a = a; // ok
static import a; // ok
import a : foo; // error
import a : a_foo = foo; // ok
Re: DIP61: Add namespaces to D
On Mon, 28 Apr 2014 09:24:59 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sat, 26 Apr 2014 05:31:51 -0400, Walter Bright
newshou...@digitalmars.com wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name
mangling doesn't match. Need a simple and straightforward method of
indicating namespaces.
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach
would be better.
As more and more people are attempting to call C++ libraries from D,
this is getting to be a more and more important issue.
Just reviewed the DIP, I've been following the discussion.
One possible issue, to which I think I know the answer but it should be
explicit, is conflicting top-level functions and namespace functions:
extern(C++, N) { void foo();}
extern(C++) void foo();
Clearly, calling N.foo would be unambiguous, but there is no namespace
to qualify the global foo. I'm assuming .foo() would work, but this
should be explicit in the DIP. Right now it says use the namespace to
qualify ambiguous calls.
I think the proposal looks good to me.
I have to rescind this endorsement. I think there is an issue with name
lookup. I will explain in a reply to the other thread.
-Steve
Re: DIP61: Add namespaces to D
On 4/28/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Yeah, it is just a random idea I have just had. I'm afraid you're 7 years too late for that patent. :P https://issues.dlang.org/show_bug.cgi?id=1297
Re: DIP61: Add namespaces to D
On Monday, 28 April 2014 at 15:19:26 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/28/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Yeah, it is just a random idea I have just had. I'm afraid you're 7 years too late for that patent. :P https://issues.dlang.org/show_bug.cgi?id=1297 I was even going to write an objection to my own idea precisely quoting your comment in that thread but got too lazy :) Well, this stuff is really obvious, no wonders here.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote: On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, though I could be surprised. If namespaces would give some astounding advantage, we would have already seen it in C++. We don't want D to become another C++ with millions of ways of doing the same thing, do we? Modules have served us well enough. Put another way, we don't need namespaces in the D language, but we do need the ability to call C++ as easily as if they were in the D language. From the above comments, it looks like it would be trivial.
Re: DIP61: Add namespaces to D
On 4/28/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: I was even going to write an objection to my own idea precisely quoting your comment in that thread but got too lazy :) Well, this stuff is really obvious, no wonders here. I don't know, I'm reconsidering right now that maybe forcing static imports could be a good thing in some contexts.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 20:16:34 UTC, Walter Bright wrote: On 4/26/2014 12:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem. extern(C++, facebook::folly) as bigcorp.whim;
Re: DIP61: Add namespaces to D
On 4/28/14, 1:15 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljjmi6$16nk$1...@digitalmars.com...
Ok, I saw that, and replied to it earlier this thread.
Yes, but you seemed to miss the point.
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We have MODULES to deal with conflicts. We do NOT need to add a new
type of scope to D just for C++ namespaces.
You deal with conflicts the SAME WAY you do with normal symbols - put
them in different modules.
This is more powerful, because it doesn't force you to match the
namespace layout in your D code.
I've missed that proposal, and couldn't find browsing through your
recent posts. Could you please send a link, thanks. -- Andrei
Re: DIP61: Add namespaces to D
On Mon, 28 Apr 2014 17:19:16 +0200 Andrej Mitrovic via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/28/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Yeah, it is just a random idea I have just had. I'm afraid you're 7 years too late for that patent. :P https://issues.dlang.org/show_bug.cgi?id=1297 I find it rather funny that bugzilla still labels it as new. :) But that's bugzilla for you. - Jonathan M Davis
Re: DIP61: Add namespaces to D
Andrei Alexandrescu wrote in message news:ljm022$575$1...@digitalmars.com... I've missed that proposal, and couldn't find browsing through your recent posts. Could you please send a link, thanks. -- Andrei Pretty sure you saw it. http://forum.dlang.org/post/lhjg4o$k82$1...@digitalmars.com
Re: DIP61: Add namespaces to D
On 4/28/14, 10:56 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:ljm022$575$1...@digitalmars.com... I've missed that proposal, and couldn't find browsing through your recent posts. Could you please send a link, thanks. -- Andrei Pretty sure you saw it. http://forum.dlang.org/post/lhjg4o$k82$1...@digitalmars.com Thanks. Isn't it unprecedented for pragmas to introduce scopes and to be un-ignorable? -- Andrei
Re: DIP61: Add namespaces to D
Andrei Alexandrescu wrote in message news:ljm83i$d6i$1...@digitalmars.com...
Thanks. Isn't it unprecedented for pragmas to introduce scopes and to be
un-ignorable? -- Andrei
(I'll assume you mean introduce scopes as in the {} syntax, not the way
Walter's proposal introduces scopes)
No, pragma(mangle) works in a very similar way, so there is a precedent. It
also serves a very similar purpose and can actually accomplish the same
things, cpp_mangle would just be a more specialized tool.
Pragmas can be used with all three attribute syntaxes:
Single declaration:
pragma(blah)
int x;
Block:
pragma(blah)
{
int x;
}
Label:
pragma(blah):
int x;
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljh472$2233$1...@digitalmars.com... True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem. I think you've misunderstood me. Modules should be used for the same exact thing they currently are - organising symbols. If you want function 'foo' to be inside module 'bar' you put 'foo' inside 'bar'. Once you have the symbol layout you want, you then annotate the declarations to specify which C++ namespace they are inside, so the mangling matches. I am NOT suggesting module name and namespace mangling should be tied together. Use D modules for symbol organisation, and add a simple feature for specifying a C++ namespace when required.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:22 PM, Daniel Murphy wrote: I am NOT suggesting module name and namespace mangling should be tied together. Use D modules for symbol organisation, and add a simple feature for specifying a C++ namespace when required. The 'namespace' feature actually does work analogously to modules.
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljiadl$4uq$1...@digitalmars.com... The 'namespace' feature actually does work analogously to modules. And it shouldn't. We have modules that work like modules. We don't need another.
Re: DIP61: Add namespaces to D
On 4/27/2014 12:19 AM, Daniel Murphy wrote: Walter Bright wrote in message news:ljiadl$4uq$1...@digitalmars.com... The 'namespace' feature actually does work analogously to modules. And it shouldn't. We have modules that work like modules. We don't need another. I am not seeing an actual proposal. If I missed it, please point me at it.
Re: DIP61: Add namespaces to D
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
Using named mixin templates for pure scope resolution is side
effect and should be discouraged in any reasonable code.
There's also the un-instantiable class trick:
-
final abstract class Scope
{
static:
}
-
A struct-based version is also possible. It's used in Phobos and other
libraries. There's a need for scoping symbols other than in modules,
but I'm not a fan of pushing C++ features in D. Not unless we have a
really solid DIP.
Idealism aside, modules have some implementation issues right now
which force people to use workarounds like named mixins or the above
trick, e.g. package access not being propagated up/down a hierarchy.
Re: DIP61: Add namespaces to D
On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote: There's a need for scoping symbols other than in modules, What is that need? Not unless we have a really solid DIP. What's wrong with the DIP? Idealism aside, modules have some implementation issues right now which force people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy. ??
Re: DIP61: Add namespaces to D
Walter Bright newshou...@digitalmars.com wrote: On 4/26/2014 12:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem. But C++ namespaces and D modules don't have to match at all. You can import any C++ function from an arbitrary namespace into any D module, just as you like. Also, I guess there is a reason, why D doesn't have a global module. Tobi
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljie28$7ei$1...@digitalmars.com... I am not seeing an actual proposal. If I missed it, please point me at it. You missed it. `pragma(cpp_namespace, ...)` and all enclosed C++ declarations are mangled accordingly. No other changes.
Re: DIP61: Add namespaces to D
On 4/27/14, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote: There's a need for scoping symbols other than in modules, What is that need? Here's some examples from Phobos: std.uni.unicode is a lowercase-named struct because it's supposed to be used as a namespace: - auto ascii = unicode.ASCII; - And here's std.datetime using a similar trick: - /++ Effectively a namespace to make it clear that the methods it contains are getting the time from the system clock. It cannot be instantiated. +/ final class Clock - I've seen other libraries use this sort of trick. E.g. the D1 Harmonia GUI library, but I'm pretty sure I saw it in some D2 libraries. Not unless we have a really solid DIP. What's wrong with the DIP? It's barely 10 sentences long, I've seen forum posts longer than this. It's supposed to be solid, with lots of example code, and also any drawbacks or potential conflicts being listed (you list none at all). It doesn't have a FAQ, links to other competing proposals, etc. And arbitrary decisions are listed in that DIP without any rationale whatsoever, e.g.: - Unlike C++, namespaces in D will be 'closed' meaning that new declarations cannot be inserted into a namespace after the closing } = rationale? - C++ Argument Dependent Lookup (aka Koenig Lookup) will not be supported. = rationale? There are other well-written DIPs in there for reference. Idealism aside, modules have some implementation issues right now which force people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy. ?? Here's the report: https://issues.dlang.org/show_bug.cgi?id=2529 Don's conclusion is what I agree with: https://issues.dlang.org/show_bug.cgi?id=2529#c1 Quote: the existing 'package' semantics force you to a flat hierarchy. Also, package access can be worked around in user-code: https://issues.dlang.org/show_bug.cgi?id=9381
Re: DIP61: Add namespaces to D
Walter Bright newshou...@digitalmars.com wrote:
On 4/26/2014 4:01 AM, Mike wrote:
pragma(cpp_namespace, A.B)
extern(C++) void f() {}
This implies that it only affects the name mangling. There needs to be a
scope created, too.
I think that's the crucial point here. Most people that disagree with your
proposal disagree exactly with that.
Scope should be created by modules and only modules.
Tobi
Re: DIP61: Add namespaces to D
27-Apr-2014 13:04, Andrej Mitrovic via Digitalmars-d пишет: On 4/27/14, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote: There's a need for scoping symbols other than in modules, What is that need? Here's some examples from Phobos: std.uni.unicode is a lowercase-named struct because it's supposed to be used as a namespace: - auto ascii = unicode.ASCII; - Technically it's a functor that works like this: auto ascii = unicode(ASCII); Then opDispatch is just a nice bonus to go with it, and struct is the only shop to offer such goodies. -- Dmitry Olshansky
Re: DIP61: Add namespaces to D
On Sunday, 27 April 2014 at 00:21:19 UTC, Aleksandar Ruzicic
wrote:
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Or maybe reuse existing keywords:
extern (C++) scope N.M { void foo(); }
or
extern (C++) module interface N.M { void foo(); }
or something along those lines.. but maybe it should look a bit
ugly :)
extern (C++)!(N.M) { void foo(); }
;)
Re: DIP61: Add namespaces to D
On Sunday, 27 April 2014 at 08:16:58 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Using named mixin templates for pure scope resolution is side
effect and should be discouraged in any reasonable code.
There's also the un-instantiable class trick:
-
final abstract class Scope
{
static:
}
-
A struct-based version is also possible. It's used in Phobos
and other
libraries. There's a need for scoping symbols other than in
modules,
but I'm not a fan of pushing C++ features in D. Not unless we
have a
really solid DIP.
I believe this is a temporary workaround. Once bugs and
deficiencies of existing module system will be taken care of,
there won't be any need in using namespace emulation.
Idealism aside, modules have some implementation issues right
now
which force people to use workarounds like named mixins or the
above
trick, e.g. package access not being propagated up/down a
hierarchy.
This pops up very often so I have just went and implemented proof
of concept for package(pkg1.pkg2.pkg3) protection attribute
syntax. Was relatively straightforward, will do a PR soon-ish
after some cleanup.
Re: DIP61: Add namespaces to D
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: I believe this is a temporary workaround. Once bugs and deficiencies of existing module system will be taken care of, there won't be any need in using namespace emulation. That's not true. Remember that when you're importing into a module you're import all symbols from that module into the current namespace. With symbols in aggregates you're forced to qualify the symbol with the name of the scope it's located in. One exception is the with() statement, but that can only be used in limited contexts (and is buggy as hell anyway).
Re: DIP61: Add namespaces to D
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: This pops up very often so I have just went and implemented proof of concept for package(pkg1.pkg2.pkg3) protection attribute syntax. Was relatively straightforward, will do a PR soon-ish after some cleanup. Yeah. It's not so difficult to implement this stuff, the problem is agreeing to something (and getting a green light from WA).
Re: DIP61: Add namespaces to D
On Sunday, 27 April 2014 at 13:43:13 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: I believe this is a temporary workaround. Once bugs and deficiencies of existing module system will be taken care of, there won't be any need in using namespace emulation. That's not true. Remember that when you're importing into a module you're import all symbols from that module into the current namespace. With symbols in aggregates you're forced to qualify the symbol with the name of the scope it's located in. One exception is the with() statement, but that can only be used in limited contexts (and is buggy as hell anyway). This is why fixing selective / renamed imports is so important. Once those are polished I'd consider using plain import anywhere but in quick scripts to be a bad style.
Re: DIP61: Add namespaces to D
On Sunday, 27 April 2014 at 13:49:15 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: This pops up very often so I have just went and implemented proof of concept for package(pkg1.pkg2.pkg3) protection attribute syntax. Was relatively straightforward, will do a PR soon-ish after some cleanup. Yeah. It's not so difficult to implement this stuff, the problem is agreeing to something (and getting a green light from WA). Hey, I am trying to be an optimist here for a minute! And you are not helping ;)
Re: DIP61: Add namespaces to D
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
LGTM.
Re: DIP61: Add namespaces to D
Jason King wrote in message news:cgcqomgrrtujzckvu...@forum.dlang.org...
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
It adds a new scoping rule, and new syntax. Neither of those things are
necessary.
Re: DIP61: Add namespaces to D
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Hey, I am trying to be an optimist here for a minute! And you are not helping ;) You must be new around here! I've had plenty of pulls being stuck in the tarpit and then rejected. :) But actually, package(foo.bar) is something I've seen mentioned before in some bug report. Or maybe we just had the same idea at some point. Good luck! :P
Re: DIP61: Add namespaces to D
Am Sun, 27 Apr 2014 00:08:17 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 4/26/2014 11:22 PM, Daniel Murphy wrote: I am NOT suggesting module name and namespace mangling should be tied together. Use D modules for symbol organisation, and add a simple feature for specifying a C++ namespace when required. The 'namespace' feature actually does work analogously to modules. Does that mean the full name in D would become something like this?: [D module ] [C++ namespace] company.project.company.project.func -- Marco
Re: DIP61: Add namespaces to D
On 4/27/2014 2:08 AM, Dmitry Olshansky wrote: Technically it's a functor that works like this: auto ascii = unicode(ASCII); Then opDispatch is just a nice bonus to go with it, and struct is the only shop to offer such goodies. So it's not just a namespace!
Re: DIP61: Add namespaces to D
On 4/27/2014 2:04 AM, Andrej Mitrovic via Digitalmars-d wrote: And here's std.datetime using a similar trick: - /++ Effectively a namespace to make it clear that the methods it contains are getting the time from the system clock. It cannot be instantiated. +/ final class Clock - When you find yourself doing things like that, seriously consider creating a new module to do it, called clock. std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way.
Re: DIP61: Add namespaces to D
On 4/27/2014 1:55 AM, Daniel Murphy wrote: Walter Bright wrote in message news:ljie28$7ei$1...@digitalmars.com... I am not seeing an actual proposal. If I missed it, please point me at it. You missed it. `pragma(cpp_namespace, ...)` and all enclosed C++ declarations are mangled accordingly. No other changes. Ok, I saw that, and replied to it earlier this thread.
Re: DIP61: Add namespaces to D
On 2014-04-26 11:31, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I don't think it's worth adding a completely new keyword for this feature. Even though many here will hate it I'll say it anyway, yet another feature that could be implemented with AST macros. There's even an example for just C++ namespaces [1]. [1] http://wiki.dlang.org/DIP50#C.2B.2B_Namespaces_.28issue_7961.29 -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
Walter Bright: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. In understand that in some cases it could be important to interface C++ code with D. But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++. Bye, bearophile
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
[2]
pragma(cpp_namespace, A.B)
extern(C++) void f() {}
[3]
@namespace(A)
{
@namespace(B) {}
}
[4]
extern (C++) template A()
{
extern (C++) template B() {}
}
[5]
DIP61 a 'namespace' keyword
Would you be willing to summarize the merits/shortcomings of each
of these in your opinion?
Mike
[1] http://forum.dlang.org/post/lhpq51$3st$1...@digitalmars.com
[2] https://issues.dlang.org/show_bug.cgi?id=7961#c6
[3] https://github.com/D-Programming-Language/dmd/pull/2767
[4] http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
[5] http://forum.dlang.org/post/ljfue4$11dk$1...@digitalmars.com
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 10:20:30 UTC, bearophile wrote: But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++. There is an advantage to keeping the D/C++ identifier namespaces separate, with a dedicated C++ syntax. I also don't mind having uglier C++ call syntax, if that makes it possible to visually determine if an identifier is either C/C++ or D at the call site (cpp_ns::identifier). Does the proposal resolve namespace conflicts between C++ and D? E.g. std:: etc?
Re: DIP61: Add namespaces to D
Am Sat, 26 Apr 2014 02:31:51 -0700
schrieb Walter Bright newshou...@digitalmars.com:
http://wiki.dlang.org/DIP61
but it seems to me that the simplest, most straightforward approach
would be better.
As more and more people are attempting to call C++ libraries from D,
this is getting to be a more and more important issue.
As the namespace keyword only makes sense for c++ interfacing code it
could make sense to implement this as a compiler-recognized UDA:
Benefits:
* No new keyword, so absolutely no code breakage for old code
(namespace is likely used in some parser code as an identifier)
* @namespace is only available when explicitly importing core.cpp
which makes sense imho
* No new syntax / parser changes
The rest of the DIP wouldn't be affected in any way.
-
module core.cpp; //core.attribute, or any clever name
struct namespace
{
string ns;
}
-
In user code:
-
import core.cpp;
@namespace(N)
{
int foo(); int bar();
}
-
Example:
http://dpaste.dzfl.pl/4d583dac89dc
Another small nitpick:
The DIP does not restrict namespaces to C++ interfacing code.
I think we should avoid having namespaces and modules in D, this will
only confuse new users and lead to bad code. We should at least state
this in the DIP or only allow the namespace keyword in extern(C++)
blocks.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code.
Re: DIP61: Add namespaces to D
On 04/26/2014 11:31 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't match. Need a simple and straightforward method of indicating
namespaces.
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach
would be better.
...
I agree.
As more and more people are attempting to call C++ libraries from D,
this is getting to be a more and more important issue.
Looks good to me, but I think that the current limited lookup rules for
template mixins are not really good enough to accommodate for common
usage patterns of namespaces.
I think the following should both just work:
import std.stdio;
mixin template Foo(T){
T foo(T a){ return a; }
}
mixin Foo!int g;
mixin Foo!string g;
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
writeln(g.foo(a));
}
// -
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
writeln(g.foo(a));
}
Both examples should still work if the two mixins/namespaces occur in
(possibly different) imported modules. I think this would be in line
with how lookup is generally handled in D. (Note that I am not
suggesting to make namespaces extensible, but rather to make them
overloadable.) How do you think about this?
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljfue4$11dk$1...@digitalmars.com... There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. So, people didn't like the proposal last time you made the thread, so you made it again? My objections from the last thread still stand. Mangling is all we need, just add a pragma or attribute to add mangling and don't tie it to other language elements. For more details go back and read the old thread.
Re: DIP61: Add namespaces to D
Is there some reason why
extern(c++, std::printf);
is rejected?
If the purpose here is to map c++ code and we are only worried
about namespaces in the c++ context, why not just make it
identical to the c++ declaration?
A pragma to indicate the name mangling scheme since MS and GCC
use different algorithms and possibly a block element to say
everything under here is in this namespace, may
extern(c++namespace, std) {
extern(c++,printf);
extern(c++,open);
}
I know my examples in real code would be extern(c) but this is
just for example purposes.
Having both namespaces and modules available in general D code is
needless complexity IMHO.
Re: DIP61: Add namespaces to D
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of pure D code.
Well, the proposed feature does not add any new capabilities except
proper mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
which is available today. I guess namespaces will occur in pure D code
as sparsely as the above construction, because they are not particularly
useful.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote: On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. I agree. No need for a new keyword, and certainly no need to introduce new D language features. I couldn't care less what the syntax is, but please minimise impact.
Re: DIP61: Add namespaces to D
On 4/26/14, 7:38 AM, Daniel Murphy wrote: Walter Bright wrote in message news:ljfue4$11dk$1...@digitalmars.com... There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. So, people didn't like the proposal last time you made the thread, so you made it again? My objections from the last thread still stand. Mangling is all we need, just add a pragma or attribute to add mangling and don't tie it to other language elements. For more details go back and read the old thread. I agree. -- Andrei
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote: I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. I agree, please just add a way of calling C++ and not a brand new feature that will change the way D code should be written. I do not want or need namespaces in D code!
Re: DIP61: Add namespaces to D
On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, though I could be surprised.
Re: DIP61: Add namespaces to D
On 4/26/2014 8:19 AM, Timon Gehr wrote:
Well, the proposed feature does not add any new capabilities except proper
mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
That's right.
which is available today. I guess namespaces will occur in pure D code as
sparsely as the above construction, because they are not particularly useful.
Yeah, template mixins turned out to be a solution looking for a problem.
Re: DIP61: Add namespaces to D
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
writeln(g.foo(a));
}
Both examples should still work if the two mixins/namespaces occur in (possibly
different) imported modules. I think this would be in line with how lookup is
generally handled in D. (Note that I am not suggesting to make namespaces
extensible, but rather to make them overloadable.) How do you think about this?
Yes, that's how I anticipate it working. That's just following existing rules.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. template mixins rock, I use them for a bunch of things.
Re: DIP61: Add namespaces to D
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the thread, so you made
it again? My objections from the last thread still stand. Mangling is all we
need, just add a pragma or attribute to add mangling and don't tie it to other
language elements.
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes, too.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote: On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, though I could be surprised. Because using namespaces is considered good practice in C++. Those coming from languages with natural namespace support will see feature with same name and semantics in D code and will proceed with using it casually, resulting in lot of unidiomatic D libraries and applications out there. Namespaces are also much more familiar and simple thing to grasp compared to original D module system. Providing those will doom D modules because of path of least resistance - lack of good practices here makes situation rather bad already, no need to make it even worse. Namespaces also don't solve any problem for that can't be already elegantly solved. We are very reluctant to add new useful features because of implied implementation, documentation and learning overhead. Abandoning that principle to add a useless feature instead is just horrible.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 15:19:55 UTC, Timon Gehr wrote:
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define
namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Well, the proposed feature does not add any new capabilities
except proper mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
which is available today. I guess namespaces will occur in pure
D code as sparsely as the above construction, because they are
not particularly useful.
This is side effect of an advanced D feature that is unlikely to
be used by newbies and is less tempting to use in practice
because it involves some boilerplate. Providing it as simple
stand-alone feature is akin to saying hey, use me!.
I don't want that in D.
I would have also strongly objected to usage of template mixins
for namespace during any code review.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:18:39 UTC, Walter Bright wrote:
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the
thread, so you made
it again? My objections from the last thread still stand.
Mangling is all we
need, just add a pragma or attribute to add mangling and don't
tie it to other
language elements.
Having a pragma to just add mangling doesn't deal with problems
like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual
scopes, too.
Ideally - use usual D tools of disambugation. Modules, static
structs etc.
Compromise - consider namespace definition from extern(C++)
during name resolution. But still keep actual feature tied to
extern(C++) to keep its use case clear.
Re: DIP61: Add namespaces to D
On 4/26/2014 4:01 AM, Mike wrote:
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
Technically, this can work, and I was initially in favor of it. But it just
strikes me as awkward. It may be one of the first things C++ programmers wanting
to use D may have to see, and I don't think it would leave a good impression.
Worse, it implies this will work:
extern (C++, namespace = A.B) { ... declarations ... }
extern (C++, namespace = A.B) { ... more declarations ... }
Which would be very, very awkward to try to make work with D's scope lookup
rules.
[2]
pragma(cpp_namespace, A.B)
extern(C++) void f() {}
This implies that it only affects the name mangling. There needs to be a scope
created, too.
[3]
@namespace(A)
{
@namespace(B) {}
}
I find nothing to recommend that over:
namespace A
{
namespace B { }
}
The object isn't to flagellate programmers wanting to call their existing C++
library code, which (realistically) is simply not going to be translated to D.
[4]
extern (C++) template A()
{
extern (C++) template B() {}
}
The trouble with that is C++ mangles templates differently than namespaces, and
this would make it impractical to then support calling C++ template functions
with no template arguments.
[5]
DIP61 a 'namespace' keyword
Would you be willing to summarize the merits/shortcomings of each of these in
your opinion?
Thanks for creating this list, it is very helpful.
The big problem with many proposals is they only address name mangling. The
scope lookup must be part of it, else it will not scale.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:17 AM, Adam D. Ruppe wrote: On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. template mixins rock, I use them for a bunch of things. I stand corrected :-)
Re: DIP61: Add namespaces to D
On 4/26/2014 11:30 AM, Dicebot wrote: Compromise - consider namespace definition from extern(C++) during name resolution. But still keep actual feature tied to extern(C++) to keep its use case clear. I mentioned something similar in a previous reply to you. Hope that means we can reach a consensus.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:21 AM, Dicebot wrote: Namespaces also don't solve any problem for that can't be already elegantly solved. There isn't any existing elegant solution to calling a C++ function in a namespace. See Mike's post. We are very reluctant to add new useful features because of implied implementation, documentation and learning overhead. Abandoning that principle to add a useless feature instead is just horrible. It has occurred to me to make namespaces only valid inside of an extern(C++) block. That at least would make it clear what it is for, and prevent casual use in D code.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:51:16 UTC, Walter Bright wrote: On 4/26/2014 11:21 AM, Dicebot wrote: Namespaces also don't solve any problem for that can't be already elegantly solved. There isn't any existing elegant solution to calling a C++ function in a namespace. Can I make a note about something? The C++ committee keeps adding new features to C++, libraries are probably going to start using those features. So when C++ gets feature X and D has to have link compatibility with C++, will we be forced to invent even more syntax just to be able to link with the latest C++1x**? I just really doubt C++ and D will be able to seamlessly interoperate because you can now match namespaces. That's the freakin' tip of the iceberg. There's so much more that you can't do, such as: - Use class objects by value in D - Manage memory in a reliable way across language boundaries (and in a usable way, meaning D users shouldn't have to call new/delete) - Handle exceptions being thrown across language boundaries I fear like we're trying to accomplish with C++ what C++ has tried to accomplish with C, meaning it wants to become a superset and wrap another language. Shoehorning stuff into D just to make linking with C++ easier looks like the wrong approach to me.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:57 AM, Andrej Mitrovic wrote: Can I make a note about something? The C++ committee keeps adding new features to C++, libraries are probably going to start using those features. So when C++ gets feature X and D has to have link compatibility with C++, will we be forced to invent even more syntax just to be able to link with the latest C++1x**? All I can say is we have to use our best judgement on a case by case basis. I just really doubt C++ and D will be able to seamlessly interoperate because you can now match namespaces. Of course that's correct. But it turns out there's a lot of low-hanging fruit this will enable us to be compatible with. I fear like we're trying to accomplish with C++ what C++ has tried to accomplish with C, meaning it wants to become a superset and wrap another language. Shoehorning stuff into D just to make linking with C++ easier looks like the wrong approach to me. I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces.
Re: DIP61: Add namespaces to D
Walter Bright wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We already have a feature to manage conflicts and organisation in D code -
modules! There is no need to add namespaces to do that, and if that's
really what you want it belongs in a completely different discussion.
The thing we can't (easily) do is mangle C++ namespaces, so a feature that
only affects mangling is perfect.
i.e. We don't need namespaces in D, because modules cover that. We only
need namespace mangling.
Re: DIP61: Add namespaces to D
On 4/26/14, 2:31 AM, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I'm anchoring a response to this although it refers to the ensuing conversation. I think this is not a good proposal from a proportional response standpoint: it squanders a keyword for a minor feature. I also think the preexisting suggestions are each wanting in various ways. That's why we should guide the discussion not in the direction of ranking existing proposals, but instead to acknowledge we have a collection of bad proposals on the table and we need to define a better one. Andrei
Re: DIP61: Add namespaces to D
On 4/26/14, 12:27 PM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We already have a feature to manage conflicts and organisation in D code
- modules! There is no need to add namespaces to do that, and if that's
really what you want it belongs in a completely different discussion.
The thing we can't (easily) do is mangle C++ namespaces, so a feature
that only affects mangling is perfect.
i.e. We don't need namespaces in D, because modules cover that. We only
need namespace mangling.
Yah, that's why something along the lines of
extern(C++) module facebook.folly;
comes to mind. Following such a module declaration, stuff inside of it
is considered inside C++ namespace facebook::folly.
The disadvantage of this is that it forces one .di file per namespace,
whereas in C++ people frequently use different namespaces within the
same file.
Andrei
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ?
Re: DIP61: Add namespaces to D
On 2014-04-26 09:31:51 +, Walter Bright newshou...@digitalmars.com said: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. ... As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. My opinion is that one shouldn't use namespaces in D. But I do like this namespace concept. It sends the following message: you're welcome to use a namespace if you like -- it'll work -- but 99% of the time it'll only be some decoration in your source code that users of your API can ignore at will because everything is still available at module scope. (The 1% is when there is a name clash.) I think it's a practical thing to do to avoid fake namespace substitutes in D (look at std.datetime.Clock), even if it's a little dirty. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: DIP61: Add namespaces to D
On 4/26/2014 12:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 20:07:25 UTC, Andrei Alexandrescu wrote: Yah, that's why something along the lines of extern(C++) module facebook.folly; comes to mind. Following such a module declaration, stuff inside of it is considered inside C++ namespace facebook::folly. The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, one would anyway likely use a tool such as DSTEP to create the bindings. I suppose the greatest benefit would be for people which doesn't use IDE:s, but also compilation time could benefit.
Re: DIP61: Add namespaces to D
On 2014-04-26 19:13:52 +, Walter Bright newshou...@digitalmars.com said: I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces. I'd argue that templates aren't the difficult part. Having struct/class semantics ABI-compatible with C++ is the hard part (constructors, destructors, exceptions). Once you have that, the difference between vector_of_int and vectorint just becomes mangling. Same thing for template functions. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: DIP61: Add namespaces to D
On 04/26/2014 08:13 PM, Walter Bright wrote:
private mixin template Foo(){
// declarations
}
mixin Foo foo;
... I guess namespaces will occur in pure D code as
sparsely as the above construction, because they are not particularly
useful.
Yeah, template mixins turned out to be a solution looking for a problem.
I was actually referring to the exact pattern above. I.e. a
parameter-less mixin template that is mixed in immediately exactly one
time for the named scope alone. :)
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote: On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ? By putting first foo in A/B.d and second foo in C/D.d
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:52:41 UTC, Walter Bright wrote: On 4/26/2014 11:30 AM, Dicebot wrote: Compromise - consider namespace definition from extern(C++) during name resolution. But still keep actual feature tied to extern(C++) to keep its use case clear. I mentioned something similar in a previous reply to you. Hope that means we can reach a consensus. Well this corrected version shifts my negative attitude to just I don't like it from I tremble in despair reading it :) In that sense, it is a breakthrough! I like Andrei's proposal much-much more though. There needs to be a good tool to interface to C++ namespaces, no doubt. But it should not impact pure D code and it does not need to follow exact C++ code style. Forcing module separation sounds awesome and can be trivially done by binding generator, i.e. dstep.
Re: DIP61: Add namespaces to D
On 04/26/2014 08:15 PM, Walter Bright wrote:
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo(a));
writeln(g.foo(2));
writeln(g.foo(a));
}
Both examples should still work if the two mixins/namespaces occur in
(possibly
different) imported modules. I think this would be in line with how
lookup is
generally handled in D. (Note that I am not suggesting to make namespaces
extensible, but rather to make them overloadable.) How do you think
about this?
Yes, that's how I anticipate it working.
Nice.
That's just following existing rules.
The example with the mixins does not actually compile. I have filed this:
https://issues.dlang.org/show_bug.cgi?id=12659
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote: On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, […] This is exactly why we shouldn't add them to the language. It complicates the language considerably (just imagine having to explain all the C++ programmers why namespaces are not what they think they are) for a slightly easier implementation of a rather niche feature. David
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. I disagree, a recent project I'm completing simply wouldn't of been possible without them. On the surface they look superfluous but in the right situation they are a very elegant solution. I'll be announcing my project soon.
Re: DIP61: Add namespaces to D
On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. There is no need to add namespaces to do that, and if that's really what you want it belongs in a completely different discussion. ... Why? Every name resolution rule added is already in D. The thing we can't (easily) do is mangle C++ namespaces, so a feature that only affects mangling is perfect. i.e. We don't need namespaces in D, because modules cover that. We only need namespace mangling. Which is all the DIP adds. I do not really understand the objections.
Re: DIP61: Add namespaces to D
On 04/26/2014 10:32 PM, Daniel N wrote: The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, Why on earth would precluding an organisation of the binding in the file system mirroring the C++ side be a benefit?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: Which is all the DIP adds. I do not really understand the objections. It adds a new language feature, which is not just used only in a rather specific situation, but also very likely to be confused with the eponymous feature from other languages. Just add the C++ mangling functionality to mixin templates using a pragma/attribute and be done, no need to add a whole new language primitive. David
Re: DIP61: Add namespaces to D
On 04/26/2014 09:56 PM, Andrei Alexandrescu wrote: I think this is not a good proposal from a proportional response standpoint: it squanders a keyword for a minor feature. I also think the preexisting suggestions are each wanting in various ways. That's why we should guide the discussion not in the direction of ranking existing proposals, but instead to acknowledge we have a collection of bad proposals on the table and we need to define a better one. I.e. your only objection to this is its syntax?
Re: DIP61: Add namespaces to D
On 04/27/2014 12:03 AM, David Nadlinger wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
Which is all the DIP adds. I do not really understand the objections.
It adds a new language feature, which is not just used only in a rather
specific situation, but also very likely to be confused with the
eponymous feature from other languages. Just add the C++ mangling
functionality to mixin templates using a pragma/attribute and be done,
no need to add a whole new language primitive.
David
I.e.
mixin template SpareIdentifier(){
// ...
}
extern(C++) pragma(namespace) mixin SpareIdentifier foo;
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code. There are specific D tools designed for that from the very beginning and we should use and/or fix those.
