Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 22:13:05 -0700 schrieb Walter Bright: > On 8/1/2018 12:01 PM, Manu wrote: >> You've never justified the design complexity and the baggage it >> carries. > Don't confuse you not agreeing with it with I never justified it. > > And please don't confuse me not listening to you with me not agreeing > with you. > > It *is* possible for reasonable people to disagree, especially when any > solution will involve many tradeoffs and compromises. In your most recent posts you provided some rationale for this, but nowhere as much as would have been necessary if anybody else proposed this feature and had to write a DIP for it. Introducing c++ namespace scopes added quite some complexity to the language and so far, you seem to be the only proponent of this, whereas we have many opponents. In the DIP process, such a change would have required quite a solid justification, examples, comparison to alternative solutions etc. Such a detailed rationale has never been given for this feature. -- Johannes
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 1 Aug 2018 at 22:15, Walter Bright via Digitalmars-d wrote: > > On 8/1/2018 12:01 PM, Manu wrote: > > You've never justified the design > > complexity and the baggage it carries. > Don't confuse you not agreeing with it with I never justified it. > > And please don't confuse me not listening to you with me not agreeing with > you. > > It *is* possible for reasonable people to disagree, especially when any > solution > will involve many tradeoffs and compromises. We have demonstrated consistent ongoing issues and frustration for 6 years. Your counter-argument is hypothetical at best, and has never demonstrated an advantage. Can you agree on that? I don't think that's a subjective quantity where reasonable people may disagree. If the namespace is useful in a minor subset of cases in the way you argue, then it should be a secondary feature which can be deployed independently as appropriate. It should not be conflated into a basic mangling request which we can't opt-out of. We are yet to observe a case where it was useful, and we have to do ongoing work to try and un-do the effect on our code. I also want to stress, I'm not trying to change the existing code. I'm not for a breaking change. I think implementing the string alternative is the only robust way forward, because that also solves the additional problem of being able to name C++ namespaces that are invalid D keywords, which has bitten me in at least 2 particularly noteworthy occasions. Your hypothetical scenario may continue to be served if you like.
Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 16:04:01 -0700 schrieb Walter Bright: > > Now, with D: > > extern (C++, ab) void foo(long); > foo(0);// works! > --- > extern (C++, ab) void foo(long); > extern (C++, ab) void foo(int); // error! > --- > extern (C++, ab) void foo(long); > extern (C++, cd) void foo(int); > foo(0);// error! > > I juxtaposed the lines so it's obvious. It's not so obvious when there's > a thousand lines of code between each of those lines. It's even worse > when foo(long) sends a birthday card to your daughter, and foo(int) > launches nuclear missiles. You probably didn't completely think this through: Earlier you suggested to use aliases to avoid explicitly specifying the c++ scopes. Then you suggested to use mixins or translator tools to automate alias generation and avoiding manually writing that boiler plate code. But if you do that: - extern (C++, ab) void foo(long); extern (C++, cd) void foo(int); alias foo = ab.foo; alias foo = cd.foo; - You've now got exactly the same problem with hijacking... So the benefit of explicit c++ namespace scoping is only a benefit if you do not use this alias trick. But then you face all other problems mentioned earlier... As a result, everybody now has to use the aliasing trick, the hijacking problem still exists and we have to write lots of useless boilerplate. -- Johannes
Re: Interested in participating SAOC 2018
On Wednesday, 1 August 2018 at 22:00:17 UTC, Seb wrote: On Wednesday, 1 August 2018 at 20:32:10 UTC, Venu Vardhan Reddy Tekula wrote: Hello! Myself, Venu. I am in the second year of my Computer Science and Engineering at Amrita School of Engineering, Kerala, India. I heard about SAoC and had a look at the projects list and one thing got my attention was this one, https://wiki.dlang.org/SAOC_2018_ideas#Automate_the_collection_and_publishing_of_data_for_monitoring_D.27s_progress_as_a_software_development_project. [...] Great to hear that you are interested in helping out! Yes, vibe.d is a popular web framework in D. I recommend you try it out as projects who plan to mainly use D mainly will for obvious reasons be preferred. I thought of implementing the project first using python and get familiar with D later and then completely shift to D. I am thinking of getting this project into existence first and later on develop it. Any Suggestions for my view?
Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 16:04:01 -0700 schrieb Walter Bright: >> Certainly, it does come across like you didn't trust the D module >> system to do its job for some reason. > > Reorganizing the code into modules means potentially forcing users to > split code from one C++ file into multiple D files. How's that really > going to work if you have a translation tool? One of the aspects of Java > I didn't care for was forcing each class into its own file. Why would that not work with a translation tool? Just establish a fixed C+ + namespace / D module mapping, then whenever processing something in a C+ + namespace append the declaration to the corresponding file. > > So while Manu is clearly happy with cutting up a C++ file into multiple > D files, > I doubt that is universal. His proposal would pretty much require that > for anyone trying to work with C++ namespaces who ever has a name > collision/hijack or wants to make the code robust against > collision/hijacking. > > An example of silent hijacking: > > extern (C++, "ab") void foo(long); // original code ... lots of code > ... > extern (C++, "cd") void foo(int); // added later by intern, should > have been > // placed in another module > ... a thousand lines later ... > foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux > > You might say "nobody would ever write code like that." But that's like > the C folks saying real C programmers won't write: > > int a[10]; > for (int i = 0; i <= 10; ++i) > ...a[i]... > > But we both know they do just often enough for it to be a disaster. > > Now, with D: > > extern (C++, ab) void foo(long); > foo(0);// works! > --- > extern (C++, ab) void foo(long); > extern (C++, ab) void foo(int); // error! > --- > extern (C++, ab) void foo(long); > extern (C++, cd) void foo(int); > foo(0);// error! > > I juxtaposed the lines so it's obvious. It's not so obvious when there's > a thousand lines of code between each of those lines. It's even worse > when foo(long) sends a birthday card to your daughter, and foo(int) > launches nuclear missiles. If you insist on using a 'translator' tool anyway, it's trivial to detect this problem automatically in such a tool. -- Johannes
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 12:01 PM, Manu wrote: You've never justified the design complexity and the baggage it carries. Don't confuse you not agreeing with it with I never justified it. And please don't confuse me not listening to you with me not agreeing with you. It *is* possible for reasonable people to disagree, especially when any solution will involve many tradeoffs and compromises.
Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 16:31:57 -0700 schrieb Walter Bright: > On 7/31/2018 1:47 AM, Atila Neves wrote: >> The only good way (I don't think the mixin template and struct >> solutions count) >> to link to any of that today would be to have one enormous D file with >> _everything_ in it, including nested namespaces. > > Why doesn't it count? The user doesn't need to write that code, the > translator does. I remember a time when people here were joking about all the boilerplate you have to write when using java and that it's only usable with an IDE. Now we've got a C++ interfacing which requires lots of boilerplate and is only usable with an external translater tool... I guess that would be acceptable if there is a real benefit, but I have not seen a single argument for the current behavior in this thread. It's great that we can workaround the scoping with lots of boilerplate, but when is C++ namespaces introducing a scope in D actually useful? Can you give an example where this scoping is necessary? So far I have not seen a single person happily using that scoping feature. -- Johannes
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright wrote:
An example of silent hijacking:
extern (C++, "ab") void foo(long); // original code
... lots of code ...
extern (C++, "cd") void foo(int); // added later by intern, should have been
// placed in another module
... a thousand lines later ...
foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux
You might say "nobody would ever write code like that." But that's like the C
folks saying real C programmers won't write:
You can do that today, just remove the "extern(C++, ...)" part and you have the
same issue. Why should C++ with namespaces be safer than just regular D ? I
don't understand, if it is such a huge gigantic problem why didn't you do
anything to solve this problem in regards to D then ?
The difference is those names are supposedly in different namespaces, given that
the code is converted from C++:
namespace ab { void foo(long); }
... lots of code ...
namespace cd { void foo(int); }
where the foo()'s do not conflict with each other, and a user would reasonably
expect that same behavior when translated to D.
If you *want* them in the same scope in D, you can do that with alias.
Re: Interested in participating SAOC 2018
On Wednesday, 1 August 2018 at 21:13:34 UTC, Ali Çehreli wrote: Please don't forget to write to soc...@dlang.org as described here: https://dlang.org/blog/symmetry-autumn-of-code/#students Ali Sure, I will.
Re: Is there any hope for "lazy" and @nogc?
On 01/08/18 17:13, Steven Schveighoffer wrote: The lazy variadic thing is a distinction between specifying variadic lazy parameters and a lazy variadic array. I have now read that sentence 4 times, and I still have no idea what it means. Can you give examples of both? Shachar
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright wrote: An example of silent hijacking: extern (C++, "ab") void foo(long); // original code ... lots of code ... extern (C++, "cd") void foo(int); // added later by intern, should have been // placed in another module ... a thousand lines later ... foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux You might say "nobody would ever write code like that." But that's like the C folks saying real C programmers won't write: You can do that today, just remove the "extern(C++, ...)" part and you have the same issue. Why should C++ with namespaces be safer than just regular D ? I don't understand, if it is such a huge gigantic problem why didn't you do anything to solve this problem in regards to D then ?
Re: When did gdc and ldc start?
Thanks!
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/31/2018 1:47 AM, Atila Neves wrote:
The only good way (I don't think the mixin template and struct solutions count)
to link to any of that today would be to have one enormous D file with
_everything_ in it, including nested namespaces.
Why doesn't it count? The user doesn't need to write that code, the translator
does. It achieves what you ask for - a declaration of foo() in the current
scope, with the mangling in the C++ namespace.
All it requires from the translator is putting a boilerplate prefix and suffix
onto what it already does.
I.e.,
extern (C++, ns) int foo();
becomes:
mixin template X() { // boilerplate prefix
extern (C++, ns) int foo(); // original line
} mixin X!() x; alias foo = x.ns.foo; // boilerplate suffix
Of course, you'd also need to write X and x as X with __LINE__ appended so
unique symbols are generated. (I know you've had trouble with generating unique
names in another post, but that's an independent problem we should find a way to
fix. Maybe instead of __LINE__, use a checksum of the original line?)
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 10:24 AM, Jonathan M Davis wrote: Not to say that that can't work, but I have to say that it seems pretty ugly if using extern(C++, NS) requires a bunch of aliases just to use symbols normally. What is normal is a slippery concept, especially when one is comparing different lookup rules between languages. D modules do not a 1:1 correspondence with C++ namespaces, either (not even close). Aliases are a normal and highly useful D tool to copy names from one scope to another. Certainly, it does come across like you didn't trust the D module system to do its job for some reason. Reorganizing the code into modules means potentially forcing users to split code from one C++ file into multiple D files. How's that really going to work if you have a translation tool? One of the aspects of Java I didn't care for was forcing each class into its own file. So while Manu is clearly happy with cutting up a C++ file into multiple D files, I doubt that is universal. His proposal would pretty much require that for anyone trying to work with C++ namespaces who ever has a name collision/hijack or wants to make the code robust against collision/hijacking. An example of silent hijacking: extern (C++, "ab") void foo(long); // original code ... lots of code ... extern (C++, "cd") void foo(int); // added later by intern, should have been // placed in another module ... a thousand lines later ... foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux You might say "nobody would ever write code like that." But that's like the C folks saying real C programmers won't write: int a[10]; for (int i = 0; i <= 10; ++i) ...a[i]... But we both know they do just often enough for it to be a disaster. Now, with D: extern (C++, ab) void foo(long); foo(0);// works! --- extern (C++, ab) void foo(long); extern (C++, ab) void foo(int); // error! --- extern (C++, ab) void foo(long); extern (C++, cd) void foo(int); foo(0);// error! I juxtaposed the lines so it's obvious. It's not so obvious when there's a thousand lines of code between each of those lines. It's even worse when foo(long) sends a birthday card to your daughter, and foo(int) launches nuclear missiles. Yes, this extra protection comes at a cost - you'll have to type a bit more. Just like D doesn't allow implicit declaration of variables, requires static typing, and variables are always initialized unless you explicitly use `= void`. The protection is worth it, and is part of D's philosophy. I hope that adequately answers the "for some reason" :-)
Re: Interested in participating SAOC 2018
On Wednesday, 1 August 2018 at 20:32:10 UTC, Venu Vardhan Reddy Tekula wrote: Hello! Myself, Venu. I am in the second year of my Computer Science and Engineering at Amrita School of Engineering, Kerala, India. I heard about SAoC and had a look at the projects list and one thing got my attention was this one, https://wiki.dlang.org/SAOC_2018_ideas#Automate_the_collection_and_publishing_of_data_for_monitoring_D.27s_progress_as_a_software_development_project. [...] Great to hear that you are interested in helping out! Yes, vibe.d is a popular web framework in D. I recommend you try it out as projects who plan to mainly use D mainly will for obvious reasons be preferred.
Re: Interested in participating SAOC 2018
Please don't forget to write to soc...@dlang.org as described here: https://dlang.org/blog/symmetry-autumn-of-code/#students Ali
Interested in participating SAOC 2018
Hello! Myself, Venu. I am in the second year of my Computer Science and Engineering at Amrita School of Engineering, Kerala, India. I heard about SAoC and had a look at the projects list and one thing got my attention was this one, https://wiki.dlang.org/SAOC_2018_ideas#Automate_the_collection_and_publishing_of_data_for_monitoring_D.27s_progress_as_a_software_development_project. The main crux of this project lies in scraping the data using the required API's and generating a web app, which can actually show a clear graph of what all things are happening to everyone. The graph thing can be done using some libraries in python. The web app can also be made using Python and Django. I am very much comfortable with C++ and Python. I have been into Web Development and worked on few projects. Now I am actually learning data science as I am quite interested in the field. I want to apply for this project as it covers both of my interests, Web Development and Data Science. But, I saw in the https://dlang.org/areas-of-d-usage.html, that web applications and data science can also be done with D. I would like to try out new things and I am very much excited to participate in this programme.
Re: Is there any hope for "lazy" and @nogc?
On 1 August 2018 at 18:52, Shachar Shemesh via Digitalmars-d
wrote:
> On 01/08/18 17:13, Steven Schveighoffer wrote:
>>
>> On 8/1/18 3:59 AM, Shachar Shemesh wrote:
>>>
>>> Thank you! Finally!
>>>
>>> Let me just state, for the record, that having *yet another* syntax
>>> special case is just appalling.
>>
>>
>> The lazy variadic thing is a distinction between specifying variadic lazy
>> parameters and a lazy variadic array. The distinction is so miniscule, but
>> necessary to have a disambiguous syntax.
>>
>> But I had actually thought for a while, that you could simply specify a
>> delegate, and it would be treated as a lazy parameter, which would probably
>> solve your problem. I really think this syntax should be available.
>>
>>> With that said, I was hoping that specifying it explicitly as a delegate
>>> would allow me to scope it. Apparently, that doesn't work :-(
>>>
>>
>> I guess you mean you can't scope the delegates? I'm surprised if that
>> doesn't work.
>>
>> -Steve
>
>
>
>
> import std.string;
>
> alias Dg = string delegate() @nogc nothrow;
>
> void myAssert(bool cond, scope Dg[1] msg_dg ...) @nogc nothrow
> {
> import core.stdc.stdio;
> if (!cond)
> {
> string msg = msg_dg[0]();
> printf("%*s\n", msg.length, msg.ptr);
> }
> }
>
> void main() @nogc {
> string msg = "Hello";
> myAssert(true, msg); // <- errors on this line
> }
>
> It errors out: complains it needs to allocate main's frame on the GC, but
> main is @nogc. The same happens if I move the scope to the alias.
My first thought was to have a look at enforce(), but on closer
observation it is neither @nogc or nothrow.
Maybe you should raise a bug report?
It's certainly worth an attempt to bridge these two features together.
I think it makes sense enough that lazy parameters should infer
attributes from the function, and that it should be an error to pass a
parameter that does not meet those constraints.
i.e:
---
// Signatures.
void myAssert(bool cond, lazy string msg) @nogc nothrow;
string mayAlloc() nothrow;
string mayThrow() @nogc;
// Code
myAssert(cond, mayAlloc());// violates @nogc
myAssert(cond, mayThrow());// violates nothrow
---
Iain.
Re: When did gdc and ldc start?
On Wednesday, 1 August 2018 at 13:49:30 UTC, bioinfornatics wrote: On Tuesday, 31 July 2018 at 02:30:12 UTC, Walter Bright wrote: I'm trying to pin down an accurate timeline of D ldc2 compiler and D environnment language was introduce in fedora 16 (2011) https://fedoraproject.org/wiki/Features/D2_programming and ldc 1 in 2010 with fedora 14 https://fedoraproject.org/wiki/Features/D_Programming
Re: Constructing a class in-place
On 7/26/18 8:45 AM, Johan Engelen wrote: On Wednesday, 25 July 2018 at 08:11:59 UTC, rikki cattermole wrote: Standard solution[0]. [0] https://dlang.org/phobos/std_conv.html#.emplace.4 Thanks for pointing to D's placement new. This is bad news for my devirtualization work; before, I thought D is in a better situation than C++, but now it seems we may be worse off. Before I continue the work, I'll have to look closer at this (perhaps write an article about the situation in D, so more ppl can help and see what is going on). In short: C++'s placement new can change the dynamic type of an object, which is problematic for devirtualization. However, in C++ the pointer passed to placement new may not be used afterwards (it'd be UB). This means that the code `A* a = new A(); a->foo(); a->foo();` is guaranteed to call the same function `A::foo` twice, because if the first call to `foo` would do a placement new on `a` (e.g. through `this`), the second call would be UB. In D, we don't have placement new, great! And now, I learn that the _standard library_ _does_ have something that looks like placement new, but without extra guarantees of the spec that C++ has. For some more info: https://stackoverflow.com/a/49569305 https://stackoverflow.com/a/48164192 Reading those items, though, doesn't emplace effectively do what std::launder does in C++, since it's crossing a function boundary? Is std::launder a special part of the spec, or does it just return its parameter to remove the potential for UB? -Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 1 Aug 2018 at 03:05, Walter Bright via Digitalmars-d wrote: > > > Was that a deliberate > > strategy? I feel like that strategy's been used before. > > You repeatedly impugn my motives and/or my mental stability. While that > doesn't > bother me, it really does not help your case. I'm not quite sure this is a fair connection... or certainly that's not my intent. But I do struggle to understand how our arguments about the pointlessness of this complexity are so easy to dismiss, without providing any substance at all, ever, in support of the design as is. I can't accept workarounds involving manual intervention when the problem shouldn't exist in the first place. This is busy-work which we will continue to do ad-infinitum, and every time it occurs I just get more upset and unreasonable. > Please just stick to the technical issue. That ball's in your court. You've never justified the design complexity and the baggage it carries. I've prompted such justification maybe 5 times in this thread already. This isn't a technical debate. It never has been. If it was, we would have arrived at "C++ namespaces are just for mangling" 6 years ago. The evidence can't lead to any other conclusion. > Believe it or not, I really want to help you (and Laeeth and Atila) be > successful with this. Then listen to us. There's a blindingly obvious and ultimately simplifying solution. It will literally resolve _every single case_ of issue or friction or complaint i'm aware of that that has ever emerged regarding C++ namespace mangling. It has never demonstrated to be useful, and we have never identified a single issue that would be created in the process. This entire class of problem will instantly disappear. And it's not even a breaking change (ie, allow string, and then we can even solve the additional problem where we can't refer to D reserved names/keywords). Unless there are actually technical reasons to wear this complexity, recommendations including "use alias everywhere", or "put everything in one file" will never satisfy.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 1 Aug 2018 at 10:25, Jonathan M Davis via Digitalmars-d wrote: > > On Wednesday, August 1, 2018 4:02:39 AM MDT Walter Bright via Digitalmars-d > wrote: > > On 7/31/2018 1:12 AM, Manu wrote: > > > Given your favourite example: > > > > > > module a; > > > extern(C++, ns) void foo(); > > > > > > module b; > > > extern(C++, ns) void foo(); > > > - > > > module c; > > > import a, b; > > > foo(); // error: ambiguous > > > ns.foo(); // error, ambiguous (obviously) > > > a.ns.foo(); // naturally, this works... it's the D module that > > > correctly organises the symbol. 'ns' is worthless here > > > > You can write it like this: > > > > > > module a; > > extern(C++, ns) void foo(); > > alias foo = ns.foo; > > > > module b; > > extern(C++, ns) void foo(); > > alias foo = ns.foo; > > - > > > > import a,b; > > a.foo(); // calls a.ns.foo() > > b.foo(); // calls b.ns.foo() > > Not to say that that can't work, but I have to say that it seems pretty ugly > if using extern(C++, NS) requires a bunch of aliases just to use symbols > normally. If the namespace were just part of the mangling, none of those > aliases would be necessary. All in all, it just seems like having the > namespaces add scoping just gets in the way - especially when they would > normally get the necessary scoping from being put into separate D modules. > > Reading through this thread, and thinking about the issue, I don't see any > advantage to the current behavior over having it just affect mangling other > than the fact that that's how it currently works. All of the potential > complaints that you talk about seem like they at least _should_ be a > non-issue given that folks don't complain that way about D's module system > for non-C++ functions - but it's certainly true that even engineers aren't > always logical or reasonable. > > However, if we were discussing a DIP for implementing namespaces for C++, > based on my current understanding of the matter, I'd definitely argue that > extern(C++) with namespaces should just affect mangling, since that approach > seems much more straightforward and much more in line with how other > languages are handled, particularly since the scoping aspect is already > going to be handled by D's module system anyway. As it stands, it just seems > like the language is forcing that all C++ functions be put inside of structs > to namespace them on top of them being put into a module. And that's > downright awkward, even if it can work. Certainly, it does come across like > you didn't trust the D module system to do its job for some reason. Thank you Jonathan.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wednesday, August 1, 2018 4:02:39 AM MDT Walter Bright via Digitalmars-d wrote: > On 7/31/2018 1:12 AM, Manu wrote: > > Given your favourite example: > > > > module a; > > extern(C++, ns) void foo(); > > > > module b; > > extern(C++, ns) void foo(); > > - > > module c; > > import a, b; > > foo(); // error: ambiguous > > ns.foo(); // error, ambiguous (obviously) > > a.ns.foo(); // naturally, this works... it's the D module that > > correctly organises the symbol. 'ns' is worthless here > > You can write it like this: > > > module a; > extern(C++, ns) void foo(); > alias foo = ns.foo; > > module b; > extern(C++, ns) void foo(); > alias foo = ns.foo; > - > > import a,b; > a.foo(); // calls a.ns.foo() > b.foo(); // calls b.ns.foo() Not to say that that can't work, but I have to say that it seems pretty ugly if using extern(C++, NS) requires a bunch of aliases just to use symbols normally. If the namespace were just part of the mangling, none of those aliases would be necessary. All in all, it just seems like having the namespaces add scoping just gets in the way - especially when they would normally get the necessary scoping from being put into separate D modules. Reading through this thread, and thinking about the issue, I don't see any advantage to the current behavior over having it just affect mangling other than the fact that that's how it currently works. All of the potential complaints that you talk about seem like they at least _should_ be a non-issue given that folks don't complain that way about D's module system for non-C++ functions - but it's certainly true that even engineers aren't always logical or reasonable. However, if we were discussing a DIP for implementing namespaces for C++, based on my current understanding of the matter, I'd definitely argue that extern(C++) with namespaces should just affect mangling, since that approach seems much more straightforward and much more in line with how other languages are handled, particularly since the scoping aspect is already going to be handled by D's module system anyway. As it stands, it just seems like the language is forcing that all C++ functions be put inside of structs to namespace them on top of them being put into a module. And that's downright awkward, even if it can work. Certainly, it does come across like you didn't trust the D module system to do its job for some reason. - Jonathan M Davis
Re: Is there any hope for "lazy" and @nogc?
On 01/08/18 17:13, Steven Schveighoffer wrote:
On 8/1/18 3:59 AM, Shachar Shemesh wrote:
Thank you! Finally!
Let me just state, for the record, that having *yet another* syntax
special case is just appalling.
The lazy variadic thing is a distinction between specifying variadic
lazy parameters and a lazy variadic array. The distinction is so
miniscule, but necessary to have a disambiguous syntax.
But I had actually thought for a while, that you could simply specify a
delegate, and it would be treated as a lazy parameter, which would
probably solve your problem. I really think this syntax should be
available.
With that said, I was hoping that specifying it explicitly as a
delegate would allow me to scope it. Apparently, that doesn't work :-(
I guess you mean you can't scope the delegates? I'm surprised if that
doesn't work.
-Steve
import std.string;
alias Dg = string delegate() @nogc nothrow;
void myAssert(bool cond, scope Dg[1] msg_dg ...) @nogc nothrow
{
import core.stdc.stdio;
if (!cond)
{
string msg = msg_dg[0]();
printf("%*s\n", msg.length, msg.ptr);
}
}
void main() @nogc {
string msg = "Hello";
myAssert(true, msg); // <- errors on this line
}
It errors out: complains it needs to allocate main's frame on the GC,
but main is @nogc. The same happens if I move the scope to the alias.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 1 Aug 2018 at 02:10, Walter Bright via Digitalmars-d wrote: > > On 7/31/2018 3:34 PM, Laeeth Isharc wrote: > > On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote: > >> On 7/27/2018 4:15 PM, Laeeth Isharc wrote: > >>> Can you think of a pragmatic solution to Atila's problem? > >> > >> One way is for the C++ => D translator to gather all the members of a > >> namespace before trying to emit them. Since D does not impose an order on > >> declarations (unlike C++) it is not constrained to follow the same order. > > > > So a new post preprocessor stage that parses the produced D code and > > regroups to > > group the declarations in the same namespace together ? Using DMD as a > > library > > or libdparse or something? > > I don't know how Atila's translator works. > > The htod one that I wrote would read and do the semantic processing on the > entire file before walking the data structures and emitting the corresponding > D > code, so grouping the namespace declarations would be trivial. In fact, due to > the nature of semantic processing, they would already be grouped together. None of this nuisance for Atila is necessary. You're just making busy-work for him at someone else's expense. Justify the design, and why it's worth the material cost to the users.
Re: Is there any hope for "lazy" and @nogc?
On 8/1/18 3:59 AM, Shachar Shemesh wrote: Thank you! Finally! Let me just state, for the record, that having *yet another* syntax special case is just appalling. The lazy variadic thing is a distinction between specifying variadic lazy parameters and a lazy variadic array. The distinction is so miniscule, but necessary to have a disambiguous syntax. But I had actually thought for a while, that you could simply specify a delegate, and it would be treated as a lazy parameter, which would probably solve your problem. I really think this syntax should be available. With that said, I was hoping that specifying it explicitly as a delegate would allow me to scope it. Apparently, that doesn't work :-( I guess you mean you can't scope the delegates? I'm surprised if that doesn't work. -Steve
Re: When did gdc and ldc start?
On Tuesday, 31 July 2018 at 02:30:12 UTC, Walter Bright wrote: I'm trying to pin down an accurate timeline of D ldc2 compiler and D environnment language was introduce in fedora 16 (2011) https://fedoraproject.org/wiki/Features/D2_programming
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/31/2018 1:12 AM, Manu wrote: Given your favourite example: module a; extern(C++, ns) void foo(); module b; extern(C++, ns) void foo(); - module c; import a, b; foo(); // error: ambiguous ns.foo(); // error, ambiguous (obviously) a.ns.foo(); // naturally, this works... it's the D module that correctly organises the symbol. 'ns' is worthless here You can write it like this: module a; extern(C++, ns) void foo(); alias foo = ns.foo; module b; extern(C++, ns) void foo(); alias foo = ns.foo; - import a,b; a.foo(); // calls a.ns.foo() b.foo(); // calls b.ns.foo() When a C++ namespace spans modules (ie, the C++ namespace encloses the whole library's api), translation to D looks like this: module ns.submodule; extern(C++, ns) void foo(); The name is: ns.submodule.ns.foo(); // <- ns is already present at the head of the qualified name, there's no point repeating it. So don't repeat it. There is no particular reason to use that naming convention for an ns namespace. As I wrote to Atila, using 'std' as a package name isn't going to work very well anyway because it's already used as a root package in Phobos. The converse case where modules are divided by their namespace (which naturally maps to D modules): module cpplib.ns; extern(C++, ns) void foo(); Now the name is: cpplib.ns.ns.foo(); // <- why would anyone want that? Why indeed. Don't do that. I don't see any reason to. We've put things like string.h in core.stdc.string, and nobody has complained they cannot just type "import string;". It works fine. Allow me to refer to: https://github.com/dlang/druntime/blob/master/src/core/stdcpp/exception.d It's where std::exception goes -> core.stdcpp.exception In it, you'll find some extern(C++,std) declarations. The file can be imported as: import core.stdcpp.exception; or: import core.stdcpp.exception : std; or any of a number of other ways to import it and set up aliases (if one prefers) to use as shortcuts to the name. But the redundancy is more than a nuisance in certain forms of scanning meta. As I mentioned, you can use alias to refer to names in other scopes. And got forbid the case where C++ namespaces are embedded (namespace for lib name, another for the module), and we have this: module lib_ns.module_ns; extrern(C++, lib_ns) extern(C++, module_ns) void foo(); The name is: lib_ns.module_ns.lib_ns.module_ns.foo(); // <- words can't even I have no idea why it would be necessary to write such. I suspect you are unfamiliar with the uses of 'alias' to refer from one scope to names in another. Was that a deliberate strategy? I feel like that strategy's been used before. You repeatedly impugn my motives and/or my mental stability. While that doesn't bother me, it really does not help your case. Please just stick to the technical issue. Believe it or not, I really want to help you (and Laeeth and Atila) be successful with this.
Re: When did gdc and ldc start?
On 1 August 2018 at 03:04, Walter Bright via Digitalmars-d wrote: > On 7/31/2018 12:07 PM, Iain Buclaw wrote: >> >> On 31 July 2018 at 20:40, Walter Bright via Digitalmars-d >> wrote: >>> >>> What's the difference between: >>> >>> DLI >>> GDMD >>> DGCC >>> >>> ? >> >> >> DLI: From what I recall, an independent project that just simply >> ported DMD front-end to Linux. I don't remember the details how but >> it had its own backend. >> GDMD: One failed attempt at getting a GCC back-end working with DMD. >> DGCC: The first successful GCC based compiler, to which GDC is derived >> from. >> >> You could call DGCC the LUCA of GDC >> (https://en.wikipedia.org/wiki/Last_universal_common_ancestor :-) >> >> Iain >> > > Was DGCC started from the GDMD sources? > As far as I can tell, they were independent attempts.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/31/2018 1:43 AM, Atila Neves wrote: It's not the same - if I want to link to std::vector and std::string, I'd expect them to be used in D as std.vector and std.string, not std.vector and HackyDThing0.std.string. Calling them std.string will already cause problems, because there's an std.string in Phobos. You could call it core.stdcpp.string, analogously to core.stdc.string for string.h. Keep in mind that with 'alias' names can behave as if they are moved to another scope.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/31/2018 3:34 PM, Laeeth Isharc wrote: On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote: On 7/27/2018 4:15 PM, Laeeth Isharc wrote: Can you think of a pragmatic solution to Atila's problem? One way is for the C++ => D translator to gather all the members of a namespace before trying to emit them. Since D does not impose an order on declarations (unlike C++) it is not constrained to follow the same order. So a new post preprocessor stage that parses the produced D code and regroups to group the declarations in the same namespace together ? Using DMD as a library or libdparse or something? I don't know how Atila's translator works. The htod one that I wrote would read and do the semantic processing on the entire file before walking the data structures and emitting the corresponding D code, so grouping the namespace declarations would be trivial. In fact, due to the nature of semantic processing, they would already be grouped together.
Re: Is there any hope for "lazy" and @nogc?
Thank you! Finally!
Let me just state, for the record, that having *yet another* syntax
special case is just appalling.
With that said, I was hoping that specifying it explicitly as a delegate
would allow me to scope it. Apparently, that doesn't work :-(
Shachar
On 31/07/18 23:03, ag0aep6g wrote:
On 07/31/2018 09:17 AM, Shachar Shemesh wrote:
I'm trying to figure out what's the signature of the built-in assert.
It does not seem that I can define a similar function myself.
Looks like you can do it with a "lazy variadic function" [1], but it's
not pretty:
alias Dg = string delegate() @nogc nothrow;
void myAssert(bool cond, Dg[1] msg_dg ...) @nogc nothrow
{
import core.stdc.stdio;
if (!cond)
{
string msg = msg_dg[0]();
printf("%*s\n", msg.length, msg.ptr);
}
}
[1] https://dlang.org/spec/function.html#lazy_variadic_functions
