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.

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.

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?

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

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?

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.

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

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!

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.

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.