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.

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.

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

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!

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.

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.

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.

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.

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.

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.