www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP61: Add namespaces to D

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 26 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
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
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 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
Apr 27 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?
Apr 26 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sat, 26 Apr 2014 02:31:51 -0700
schrieb Walter Bright <newshound2 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.
Apr 26 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Apr 26 2014
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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. :)
Apr 26 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 26 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-04-26 19:13:52 +0000, Walter Bright <newshound2 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 vector<int> just becomes mangling. Same thing for template functions. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Apr 26 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
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
Apr 26 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 26 2014
next sibling parent "Jason King" <jhking airmail.net> writes:
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.
Apr 26 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 26 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 26 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 26 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
Apr 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 27 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 27 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 27 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 28 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 28 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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
Apr 28 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 28 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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;
Apr 28 2014
prev sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 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
Apr 27 2014
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Apr 26 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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;
Apr 26 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Apr 26 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
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?
Apr 26 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.

??
Apr 27 2014
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Apr 27 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 27 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 27 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 27 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 27 2014
parent Jacob Carlborg <doob me.com> writes:
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
Apr 28 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Daniel N" <ufo orbiting.us> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
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
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 27 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.


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
Apr 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 27 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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).
Apr 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 27 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 W&A).
Apr 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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 W&A).

Hey, I am trying to be an optimist here for a minute! And you are not helping ;)
Apr 27 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 27 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 28 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 28 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 28 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 28 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 28 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 28 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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"?
Apr 28 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot <public 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
Apr 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 28 April 2014 at 13:54:05 UTC, Steven Schveighoffer 
wrote:
 On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot <public 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
Apr 28 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 28 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 28 2014
prev sibling next sibling parent "justme" <justme example.com> writes:
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;
Apr 28 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Apr 28 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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

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.
Apr 26 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
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!
Apr 26 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 26 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
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?
Apr 26 2014
prev sibling next sibling parent reply "Jacob Carlborg" <doob me.com> writes:
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
Apr 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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() ?
Apr 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-04-26 09:31:51 +0000, Walter Bright <newshound2 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.fortin michelf.ca http://michelf.ca
Apr 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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
Apr 26 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
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
Apr 26 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
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.
Apr 26 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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(); }}
Apr 26 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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?
Apr 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/26/2014 4:35 PM, Dicebot wrote:
 Much better. And global C++ namespace will be plain extern(C++), right?

Right.
Apr 26 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 26 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 26 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Apr 26 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2014
prev sibling next sibling parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
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 :)
Apr 26 2014
prev sibling next sibling parent "No" <no no.no> writes:
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(); } ;)
Apr 27 2014
prev sibling next sibling parent reply "Jason King" <jhking airmail.net> writes:
     extern (C++, N.M) { void foo(); }

     extern (C++) namespace N { namespace M { void foo(); }}

Apr 27 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jason King"  wrote in message news:cgcqomgrrtujzckvuvyv 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.
Apr 27 2014
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Apr 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 26 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Apr 26 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 27 Apr 2014 00:08:17 -0700
schrieb Walter Bright <newshound2 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
Apr 27 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 26 Apr 2014 05:31:51 -0400, Walter Bright  
<newshound2 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
Apr 28 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Apr 2014 09:24:59 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Sat, 26 Apr 2014 05:31:51 -0400, Walter Bright  
 <newshound2 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
Apr 28 2014
prev sibling parent "justme" <justme example.com> writes:
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.
Apr 28 2014