April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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.
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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() ?
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. :)
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
April 26, 2014 Re: DIP61: Add namespaces to D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
Copyright © 1999-2021 by the D Language Foundation