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

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

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.

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.

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?

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

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?

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;

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.

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.