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 reply "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
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 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 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



 next sibling 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 reply "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



  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 next sibling parent reply "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



  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  "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  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  "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


 I think this is a very bad proposal. Necessity to define 
 namespaces for interfacing with C++ must not result in usage of 
 namespaces of pure D code.


I agree.

No need for a new keyword, and certainly no need to introduce new 
D language features.

I couldn't care less what the syntax is, but please minimise 
impact.



 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  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



 next sibling parent reply "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



  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 "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



  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  "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  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



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  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 reply "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



  parent reply 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



  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  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 "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



  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



 next sibling 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  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  =?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  "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 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 reply "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



  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  parent reply "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



 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 reply "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



  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 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



 next 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



  parent reply 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.


 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



 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



 next sibling 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



 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  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  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  parent reply 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



  parent reply 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



  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  parent reply 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



  parent reply "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



  parent reply "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



  parent reply "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



  parent reply "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



 next sibling parent reply 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



  parent reply "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



  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  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  parent reply "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



 next sibling parent reply 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



  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  parent reply 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



  parent reply "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



  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 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 reply "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



  parent reply 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



  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  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 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  "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 reply "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



  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(); }}


Excellent.  Solves the problem, doesn't add new language elements.



 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  parent reply "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



  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