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
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: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 Mon, 28 Apr 2014 17:19:16 +0200 Andrej Mitrovic via Digitalmars-d wrote: > On 4/28/14, Dicebot via Digitalmars-d > 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
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 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, Dicebot via Digitalmars-d 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 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 Monday, 28 April 2014 at 15:19:26 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/28/14, Dicebot via Digitalmars-d 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 4/28/14, Dicebot via Digitalmars-d 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 Mon, 28 Apr 2014 09:24:59 -0400, Steven Schveighoffer wrote: On Sat, 26 Apr 2014 05:31:51 -0400, 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. 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 Monday, 28 April 2014 at 13:54:05 UTC, Steven Schveighoffer wrote: On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot 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:23:17 -0400, Dicebot 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 Sat, 26 Apr 2014 05:31:51 -0400, 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. 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 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 wrote: On 4/27/14, Walter Bright via Digitalmars-d 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 Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via Digitalmars-d wrote: On 4/27/14, Walter Bright via Digitalmars-d 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 Mon, 28 Apr 2014 10:45:40 +0200 Andrej Mitrovic via Digitalmars-d wrote: > On 4/28/14, Jonathan M Davis via Digitalmars-d > 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 4/28/14, Jacob Carlborg via Digitalmars-d 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 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 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 4/28/14, Jonathan M Davis via Digitalmars-d 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 Sun, 27 Apr 2014 23:49:41 -0700 Walter Bright via Digitalmars-d 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
"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 4/28/14, Jacob Carlborg via Digitalmars-d 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
On 4/27/14, Walter Bright via Digitalmars-d 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/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 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 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 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 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
Am Sun, 27 Apr 2014 00:08:17 -0700 schrieb Walter Bright : > 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/14, Dicebot via Digitalmars-d 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
"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 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
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 Sunday, 27 April 2014 at 13:49:15 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/27/14, Dicebot via Digitalmars-d 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 W&A). Hey, I am trying to be an optimist here for a minute! And you are not helping ;)
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 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 4/27/14, Dicebot via Digitalmars-d 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 W&A).
Re: DIP61: Add namespaces to D
On 4/27/14, Dicebot via Digitalmars-d 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 Sunday, 27 April 2014 at 08:16:58 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 4/27/14, Dicebot via Digitalmars-d 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 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
27-Apr-2014 13:04, Andrej Mitrovic via Digitalmars-d пишет: On 4/27/14, Walter Bright via Digitalmars-d 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
Walter Bright 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
On 4/27/14, Walter Bright via Digitalmars-d 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" 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
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. 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
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
On 4/27/14, Dicebot via Digitalmars-d 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 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
"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/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: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 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 :)
Re: DIP61: Add namespaces to D
On 4/26/2014 4:35 PM, Dicebot wrote: Much better. And global C++ namespace will be plain extern(C++), right? Right.
Re: DIP61: Add namespaces to D
On 4/26/2014 4:59 PM, Andrei Alexandrescu wrote: On 4/26/14, 4:32 PM, 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(); }} Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei Either. The former if there is more than one foo() found by name lookup. Just like for imports.
Re: DIP61: Add namespaces to D
On Sat, Apr 26, 2014 at 04:32:29PM -0700, Walter Bright via Digitalmars-d 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(); }} Much better! This clearly ties it to C++ compatibility, so there's no chance of unintentional misuse in native D code. And it doesn't waste a D keyword on C++ compatibility. T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: DIP61: Add namespaces to D
On 04/27/2014 01:59 AM, Andrei Alexandrescu wrote: On 4/26/14, 4:32 PM, 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(); }} Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei foo(), N.foo() or N.M.foo(). (Name clashes may increase the required granularity.)
Re: DIP61: Add namespaces to D
On 4/26/14, 4:32 PM, 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(); }} Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei
Re: DIP61: Add namespaces to D
On 4/26/2014 3:01 PM, Timon Gehr wrote: 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? I've also been arguing that the druntime import hierarchy for imports of C system headers should match the layout of how a C user typically #include's them. I.e. we should not be trying to fix the hierarchy of C include's, and we shouldn't for C++, either.
Re: DIP61: Add namespaces to D
On 4/26/2014 2:45 PM, Dicebot wrote: 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 Unfortunately, C++ programmers don't use namespaces in a way that corresponds to the .h file names. By forcing them to lay out their D interface files quite differently than their .h files, it puts a large burden on them.
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(); }} Much better. And global C++ namespace will be plain extern(C++), right?
Re: DIP61: Add namespaces to D
Walter Bright: 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(); }} It looks worse, so it looks better :-) Bye, bearophile
Re: DIP61: Add namespaces to D
On 4/26/2014 2:58 PM, Gary Willoughby wrote: 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. Cool. I'm looking forward to it!
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:35:44 UTC, Walter Bright wrote: On 4/26/2014 2:45 PM, Dicebot wrote: 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 Unfortunately, C++ programmers don't use namespaces in a way that corresponds to the .h file names. By forcing them to lay out their D interface files quite differently than their .h files, it puts a large burden on them. Well this is only reason why I am not adamant about this and eager to compromise ;) Still, providing tool that does C++ .h to .di conversion but does idiomatic adaptation to D module system sounds like a better long-term solution which will benefit both existing D infrastructure and interests of C++ programmers.
Re: DIP61: Add namespaces to D
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(); }}
Re: DIP61: Add namespaces to D
On 04/27/2014 01:11 AM, Dicebot wrote: On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote: On 04/27/2014 12:43 AM, Dicebot wrote: 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. I don't really advocate using named mixin templates directly as much as just the same lookup rules. Well that wasn't clear from your comments at all, quite the contrary ;) ... Wtf? There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file. I don't see any problem with having lot of files. It is natural way organizing D code if you consider protection attributes that define module as minimal encapsulation unit. I don't see the point of requiring replication of the namespace structure in directories just for the sake of conflating modules and namespaces, even though #includes bear a closer resemblance in usage to imports than using directives and doing better is basically free because the required lookup semantics are already there. Why discuss anything but syntax at this point?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote: On 04/27/2014 12:43 AM, Dicebot wrote: 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. I don't really advocate using named mixin templates directly as much as just the same lookup rules. Well that wasn't clear from your comments at all, quite the contrary ;) There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file. I don't see any problem with having lot of files. It is natural way organizing D code if you consider protection attributes that define module as minimal encapsulation unit.
Re: DIP61: Add namespaces to D
On 04/27/2014 12:43 AM, Dicebot wrote: 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. I don't really advocate using named mixin templates directly as much as just the same lookup rules. There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: 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. template mixins are great. Nitpick: If they could (optionally) truly inject themselves in a scope (useful for automatically generating function overloads / constructors) then they would be even better.
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.
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 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 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 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 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 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 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: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 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 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 2014-04-26 19:13:52 +, Walter Bright 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 vector just becomes mangling. Same thing for template functions. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
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 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 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 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/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
"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/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
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: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 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: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 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 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 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: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 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.