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.

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.

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.

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

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.

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.

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.

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.

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

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