MD are C++ classes (both
LDC and GDC are written in C++ and need to use the AST). Without really
thinking of it I had put instance of C++ classes as keys in a D
associative array. This is, for some reason, calling
object.TypeInfo_Class.getHash which only expects to operate on D
classes. I
On Fri, Aug 17, 2018 at 03:39:44PM +, zabruk via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 14:11:24 UTC, H. S. Teoh wrote:
> > NoScript is your friend.
> >
>
> Yes.
> But i just wonder: site creators make secret war with us (users). They
> make we harder
On Friday, 17 August 2018 at 14:11:24 UTC, H. S. Teoh wrote:
NoScript is your friend.
Yes.
But i just wonder: site creators make secret war with us (users).
They make we harder and harder, we struggle by noscript and other
technics :)
Did you see sites, where links made with js, so i cant o
On Fri, Aug 17, 2018 at 11:29:46AM +, zabruk via Digitalmars-d wrote:
[...]
>
>
> Can anyone explain me the purpose of javascript on this page?
> Especialy various mouse click event handlers, those break common
> well-known handfull browser behaviour?
> I can't select
https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a
Can anyone explain me the purpose of javascript on this page?
Especialy various mouse click event handlers, those break common
well-known handfull browser behaviour?
I can't select text and
On Friday, 17 August 2018 at 06:38:59 UTC, Joakim wrote:
By our very own BBasile of Coedit fame:
https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a
I was surprised to see how well received was this reddit post.
Initially i've written it to t
the usage and adoption of the D language by the community paying
for more work on the language and libraries.
I think there should be a marketplace in such paid work on D, one
that largely doesn't exist right now. In your language of
economics, that market isn't clearing. Why is this
On Wednesday, 15 August 2018 at 22:12:55 UTC, Andrei Alexandrescu
wrote:
On 8/15/18 5:31 PM, Matheus wrote:
On Wednesday, 15 August 2018 at 20:45:34 UTC, Andrei
Alexandrescu wrote:
... We are in talks with a few more students from Romania and
Brazil...
I'm from Brazil and I use D for
On Friday, 17 August 2018 at 06:38:59 UTC, Joakim wrote:
By our very own BBasile of Coedit fame:
https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a
An interesting read. Nice to see that Pegged’s toHTML() method is
appreciated and put to good use
By our very own BBasile of Coedit fame:
https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a
with this new funding:
:jealous:
However, there are other ways to raise funds. Companies using
D could use the existing bountysource page to put up bounties
for features/fixes or projects they need, to which community
members who need some particular feature/fix could also
donate:
https
guage community is founded on its own unique
principles and trying to squash it onto a box that doesn't fit
isn't going to go anywhere.
D doesn't need a big corporate sponsor. It already has some
corporate sponsors and now there is a beginning made with the D
Foundation and e
In
https://www.youtube.com/watch?v=nVzgkepAg5Y
Andrei describes his proposal for STL `Expected` planned to be
included in C++20.
Have anybody converted the C++ proposal to idiomatic D, yet?
Hopefully without the pointer-legacy which unfortunately was
allowed into `std:optional`.
Andrei
On Wednesday, 15 August 2018 at 20:45:34 UTC, Andrei Alexandrescu
wrote:
On 8/13/18 5:50 AM, Joakim wrote:
[...]
Thanks for the info. That's good for Nim and something we could
definitely benefit from as well. Currently, Sebastian Wilzbach
and Razvan Nitu, both students, are working full tim
On Wednesday, 15 August 2018 at 22:12:55 UTC, Andrei Alexandrescu
wrote:
On 8/15/18 5:31 PM, Matheus wrote:
On Wednesday, 15 August 2018 at 20:45:34 UTC, Andrei
Alexandrescu wrote:
... We are in talks with a few more students from Romania and
Brazil...
I'm from Brazil and I use D for
On 8/15/18 5:31 PM, Matheus wrote:
On Wednesday, 15 August 2018 at 20:45:34 UTC, Andrei Alexandrescu wrote:
... We are in talks with a few more students from Romania and Brazil...
I'm from Brazil and I use D for hobby projects. It would be nice to
present them later, in fact I was inter
On Wednesday, 15 August 2018 at 20:45:34 UTC, Andrei Alexandrescu
wrote:
... We are in talks with a few more students from Romania and
Brazil...
I'm from Brazil and I use D for hobby projects. It would be nice
to present them later, in fact I was interested to create D group
around her
/08/07/nim-partners-with-status.html
D should also be trying to raise resources like this, though it doesn't
have to be corporate funding from one source. This company funding Nim
raised $100 million in an ICO last year to build some kind of
cryptocurrency-oriented mobile apps platform:
On Tuesday, 14 August 2018 at 07:05:12 UTC, Joakim wrote:
if you have a bug ...
This is not about me:
Sorry, I mean the plural "you", as in anyone reading this thread.
Mike
other ways to raise funds. Companies using
D could use the existing bountysource page to put up bounties
for features/fixes or projects they need, to which community
members who need some particular feature/fix could also donate:
https://www.bountysource.com/teams/d
I think bountysource would
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote:
Announced last week, the Nim team will be adding two full-time
paid devs and setting up grants for needed projects with this
new funding:
:jealous:
However, there are other ways to raise funds. Companies using D
could use the existing
) Linux runtime for D.
Probably I should go for it :)
In recent months, I've been thinking about something like that
as well.
I think it's a very promising idea. Why not start with DasBetterC
and build a Phobos like library from there?
On Monday, 13 August 2018 at 12:06:25 UTC, I Lindström wrote:
In that case things look decent enough for me to stop worrying
about this too much. And yeah, if it's a common occurance that
companies try to highjack things, then it's better to be
careful. Enough things have been run to the ground
-with-the-team-behind-the-programming-language-nim/
https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html
D should also be trying to raise resources like this, though
it doesn't have to be corporate funding from one source. This
company funding Nim raised $100 million in an ICO
://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html
D should also be trying to raise resources like this, though it
doesn't have to be corporate funding from one source. This
company funding Nim raised $100 million in an ICO last year to
build some kind of cryptocurrency-oriented m
://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html
D should also be trying to raise resources like this, though it
doesn't have to be corporate funding from one source. This
company funding Nim raised $100 million in an ICO last year to
build some kind of cryptocurrency-oriented m
D should also be trying to raise resources like this, though it
doesn't have to be corporate funding from one source. This
company funding Nim raised $100 million in an ICO last year to
build some kind of cryptocurrency-oriented mobile apps platform:
https://www.inc.com/brian-d-evans/s
On Sunday, 12 August 2018 at 06:35:17 UTC, Eugene Wissner wrote:
P.S. In the last weeks I had thoughts to split low-level stuff
from tanya and put it into a separate library, kind of native,
gc-free x86-64 (and maybe aarch64) Linux runtime for D.
Probably I should go for it :)
In recent
On Sunday, 12 August 2018 at 11:37:54 UTC, Mike Parker wrote:
On Sunday, 12 August 2018 at 11:23:55 UTC, Aruna Maurya wrote:
So I'll be taking Eugene's code as reference to try and
implement malloc free and realloc in dlang.
Be sure to send your proposal in by August 15!
Yes. Definitely!I
On Sunday, 12 August 2018 at 11:23:55 UTC, Aruna Maurya wrote:
So I'll be taking Eugene's code as reference to try and
implement malloc free and realloc in dlang.
Be sure to send your proposal in by August 15!
On Sunday, 12 August 2018 at 08:34:46 UTC, Mike Franklin wrote:
On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
[...]
Inline ASM is a feature of D, so "idiomatic D" includes
assembly implementations. Where D shines here is with it's
metaprogramming capab
On Sunday, 12 August 2018 at 06:44:37 UTC, Aruna Maurya wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
I don't know of any D implementations of these other than the
trivial and naive. I think it's a l
On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
These functions are still mostly implemented in asm, so I'm not
sure there is an "idiomatic D&quo
On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
These functions are still mostly implemented in asm, so I'm not
sure there is an "idiomatic D&quo
e` in idiomatic D without any dependencies
on other libraries from other languages.
[...]
Also what about other implementations like memset or memcmp.
Have they been implemented or require work from scratch?
These functions are still mostly implemented in asm, so I'm not
sure there is an "i
On Sunday, 12 August 2018 at 05:24:56 UTC, Mike Franklin wrote:
On Sunday, 12 August 2018 at 04:16:24 UTC, Aruna Maurya wrote:
[...]
I'd say there is only 1 requirement: implementing `malloc`,
`realloc`, and `free` in idiomatic D without any dependencies
on other libraries from
ed.
It depends only on internal libc-free syscalls that can be
replaced with mmap/munmap and on copy()/copyBackward() that are
just memcpy and memmove respectively.
But, how does it perform? In order to make the case for using
these D implementations in druntime, we'll have to gather some
On Sunday, 12 August 2018 at 04:16:24 UTC, Aruna Maurya wrote:
So there are essentially two requirements here. Building the
memory management functionalities from scratch in idiomatic D
and implementing the existing runtime hooks as templates. The
latter isn't quite a part of the id
On Saturday, 11 August 2018 at 20:15:06 UTC, Mike Franklin wrote:
On Saturday, 11 August 2018 at 18:59:00 UTC, Aruna Maurya wrote:
[...]
The compiler recognizes certain expressions and lowers them to
functions in the D runtime that we call runtime hooks. See
https://wiki.dlang.org
ntime hooks'.
The compiler recognizes certain expressions and lowers them to
functions in the D runtime that we call runtime hooks. See
https://wiki.dlang.org/Runtime_Hooks for an unmaintained, but
still relevant, list of some of them.
For example, the expression `cast(int[])a`, where
On Saturday, 11 August 2018 at 18:59:00 UTC, Aruna Maurya wrote:
Hello all! I am a Computer Science undergraduate student.
Currently a junior, I find the idea of 're-implementing
software building blocks like malloc and free in D' listed in
the wiki page of SAOC(Symmetry Autumn of C
own set of goals and
scope in the proposal. For example, you may choose to rewrite the memory
management stuff in libc in D and support it across Windows, Linux and
OSX. Instead of dealing with integration into druntime/dmd.
Hello all! I am a Computer Science undergraduate student.
Currently a junior, I find the idea of 're-implementing software
building blocks like malloc and free in D' listed in the wiki
page of SAOC(Symmetry Autumn of Code) quite interesting.
I don't have experience of coding
Can we stick this in the testimonials webpage? ;)
"Barely figuring out the #dlang design choices, and I'm already
perceiving C++ as a knapsack with stone picks of random sizes.."
https://mobile.twitter.com/nikos_maximus/status/1027519165937184768
On Saturday, 4 August 2018 at 11:38:39 UTC, Nick Treleaven wrote:
On Friday, 3 August 2018 at 21:27:50 UTC, dlangPupil2 wrote:
In lieu of a whole new edition maybe a web page listing major
changes to D since Andrei's book came out might be useful (and
help sales of his existing boo
On 8/7/2018 3:49 AM, Atila Neves wrote:
Yes, I've already implemented it.
Wonderful!
I'm not sure what the impact will be with nested namespaces in real headers. I
guess we'll have to see.
Yes.
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Yes, I'v
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
On 8/7/2018 1:13 AM, Walter Bright wrote:
On 8/7/2018 12:08 AM, Nicholas Wilson wrote:
I don't see what making an alias to a namespace has to do with it.
That was your suggested workaround, was it not?
No, it was not. It was about making an alias to the members of the namespace.
BTW, the mas
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Almost.
On Tuesday, 7 August 2018 at 05:58:17 UTC, Walter Bright wrote:
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to not
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to not have a namespace, I don't see what making an alias to a
namespa
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Yes, but
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate working code that
behaves "as if" the namespace scope is not there, even for nested namespaces.
Is this correct?
On 8/5/2018 9:53 PM, Manu wrote:
If we produce a DIP to fix this, will you reject it in principle?
Producing a DIP is a good idea, it provides an anchor point for any future
discussion of the topic, rather than the tangle and noise that is this thread.
It is an ample opportunity to put the be
On 8/6/2018 3:19 PM, tide wrote:
That's just a deflection,
1. I'm only here to help, and am not interested in scoring debate points.
2. To bring up other topics, please start a new thread. Especially since this
one is quite voluminous.
On Monday, 6 August 2018 at 20:35:37 UTC, Walter Bright wrote:
On 8/6/2018 11:26 AM, tide wrote:
What's your crossplatform workaround if I have a namespace
named "version" or "package" ?
See my reply to Rick Cattermole.
https://digitalmars.com
On 8/6/2018 11:26 AM, tide wrote:
What's your crossplatform workaround if I have a namespace named "version" or
"package" ?
See my reply to Rick Cattermole.
https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_31727
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
Yes. But then you'll have the people who want a 1:1
correspondence with their C++ files and the corresponding D
files. I happen to be one of those people, for the ease of
maintaining a translation (and for comparing it wit
On Sunday, 5 August 2018 at 23:28:06 UTC, Walter Bright wrote:
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've
put these forth before, and I could repeat myself rebutting
each. I expect we're at a dead end with that.
But the fact remains
On Saturday, 4 August 2018 at 12:18:21 UTC, tide wrote:
On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote:
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
The difference is they would have to rework their existing
code. If you are writing D source code bindings for your
On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote:
On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
wrote:
[...]
Faster and consistently, sure. But I don't think 'better' is
possible.
[...]
Bindings != wrappers. I agree that wrappers will nearly alw
truly
bad, and the more I think about it the more convinced I am
that Manu is right and there should be _no_ scoping whatsoever
in D regarding C++ namespaces. We have packages and modules,
we can use those to put the C++ functions we declare in
whatever hierarchy we want.
I am puzzled. Wit
On Monday, 6 August 2018 at 09:48:30 UTC, Danni Coy wrote:
Outside perspective here and possibly stupid question. Is there
any way we could have our cake and eat it too? One of the
thinks I like is that it tends to be much more readable than
C++, more code than necessary hurts readability of t
On Monday, 6 August 2018 at 04:53:05 UTC, Manu wrote:
If we produce a DIP to fix this, will you reject it in
principle?
I think you and Walter Bright made good points and I think a
creation of a DIP that addresses his concerns would be a best
course of action IMO.
-Alexander
is shadowed by another function in a different namespace. This to me
seems like the most sane solution, what am I missing?
On Mon, Aug 6, 2018, 14:53 Manu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d
> wrote:
On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d
wrote:
>
> On 8/4/2018 12:45 AM, Manu wrote:
> > [...]
> I get it, Manu, you don't find my arguments compelling. You've put these forth
> before, and I could repeat myself rebutting each. I expect we'
On 8/2/2018 5:23 PM, rikki cattermole wrote:
Because it will affect mangling only, do we have any examples of c/c++ code that
appends _'s to it that is used by the D community?
The __ scheme won't break existing code, and we don't need a survey to show
that.
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've put these forth
before, and I could repeat myself rebutting each. I expect we're at a dead end
with that.
But the fact remains, I've shown both you and Atila how to make things work for
you
On 05/08/2018 10:14 AM, Ethan wrote:
Freenode has been under sustained attack from a spam botnet since about
2.00 UTC 1 August. At least, that's when the first spam message was
posted to #d.
Freenode admins have suggested everyone adds +r to their channel mode to
stop unregistered acc
Freenode has been under sustained attack from a spam botnet since
about 2.00 UTC 1 August. At least, that's when the first spam
message was posted to #d.
Freenode admins have suggested everyone adds +r to their channel
mode to stop unregistered accounts from joining. Sounds simple.
E
On Saturday, 4 August 2018 at 17:54:11 UTC, Jonathan M Davis
wrote:
On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d
wrote:
The only person I've seen that wants this is Walter. I haven't
seen anyone else show interest in wanting a 1:1 correlation.
It's unreasonable,
On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d wrote:
> The only person I've seen that wants this is Walter. I haven't
> seen anyone else show interest in wanting a 1:1 correlation. It's
> unreasonable, D isn't C++ nor should it be trying to strive t
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
If we want to support interfacing with C++, we have to support
badly written C++, because that is the NORMAL case. Telling
them their code is and that they should rewrite it in
order to work with D is never, ever going to work
On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote:
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
The difference is they would have to rework their existing
code. If you are writing D source code bindings for your code,
then you are essentially writing new code. You
On 8/3/18 5:20 PM, Walter Bright wrote:
Telling them their code is
and that they should rewrite it in order to work with D is never,
ever going to work.
And that's OK with me. I'm OK with D saying it only supports reasonably
written C++ code, and 99% of the C++ community w
On Friday, 3 August 2018 at 21:27:50 UTC, dlangPupil2 wrote:
In lieu of a whole new edition maybe a web page listing major
changes to D since Andrei's book came out might be useful (and
help sales of his existing book too!!)
https://wiki.dlang.org/Differences_With_TDPL
On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote:
On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
wrote:
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
>
> The difference is they would have to rework their existing
> code. If you are writing D source code
On Wed, 1 Aug 2018 at 16:05, Walter Bright via Digitalmars-d
wrote:
>
> 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 u
On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
wrote:
>
> On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
> >
> > The difference is they would have to rework their existing
> > code. If you are writing D source code bindings for your code,
> > th
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
The difference is they would have to rework their existing
code. If you are writing D source code bindings for your code,
then you are essentially writing new code. You don't have to
worry about backwards compatibility.
Why woul
hole and if they don't want to support other compiles, then
they will be stuck with BrandX.
If we want to support interfacing with C++, we have to support
badly written C++, because that is the NORMAL case. Telling
them their code is and that they should rewrite it in
order to work
xin X!() x; alias foo = x.std.chrono.foo; // boilerplate suffix
I considered for a while whether or not this would be truly bad, and the more I
think about it the more convinced I am that Manu is right and there should be
_no_ scoping whatsoever in D regarding C++ namespaces. We have packages an
On 08/03/2018 02:27 PM, dlangPupil2 wrote:
a web page listing major changes to
D since Andrei's book came out
Related, here is the errata:
http://erdani.com/tdpl/errata/
Ali
On Friday, 3 August 2018 at 12:17:21 UTC, bachmeier wrote:
On Thursday, 2 August 2018 at 22:37:05 UTC, dlangPupil2 wrote:
Hi,
Will there be a new edition of Andrei A's "The D Programming
Language" (2010)? If so when will it be published?
Thanks!
This has come up many tim
ir code is and that
they should rewrite it in order to work with D is never, ever going to work.
Another anecdote - Microsoft MASM in the 80's was full of bugs. I mean full of
bugs. When Borland came out with an assembler, it wouldn't work with most of the
ASM files out there. They fin
On Friday, 27 July 2018 at 23:15:44 UTC, Laeeth Isharc wrote:
Because it's getting in the way of a decent prize - to be able
just to #include CPP headers and link with C++.
Just wanted to +100 on this one
Having this feature, and if marketed well, can be huge for D
This is 10 ti
On Thursday, 2 August 2018 at 22:37:05 UTC, dlangPupil2 wrote:
Hi,
Will there be a new edition of Andrei A's "The D Programming
Language" (2010)? If so when will it be published?
Thanks!
If you want a more recent book, there is Learning D by Michael
Parker
(who is a com
On Friday, 3 August 2018 at 10:58:18 UTC, Atila Neves wrote:
On Wednesday, 1 August 2018 at 23:31:57 UTC, Walter Bright
wrote:
[...]
Good point.
[...]
We can also just keep the current behaviour and implement
something like extern(C++, "std::chrono") in addition (as manu
pointed out multi
On Thursday, 2 August 2018 at 22:37:05 UTC, dlangPupil2 wrote:
Hi,
Will there be a new edition of Andrei A's "The D Programming
Language" (2010)? If so when will it be published?
Thanks!
This has come up many times, and I don't think it's going to
happen. For on
On Friday, 3 August 2018 at 10:58:18 UTC, Atila Neves wrote:
I thought about it some more and managed to make it work. It's
definitely a hack, but since in my case the user won't usually
see the generated code anyway it's not too bad. It's far from
ideal, though, because I can't alias an enti
On Wednesday, 1 August 2018 at 23:31:57 UTC, Walter Bright wrote:
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 n
underscore prefix is reserved
for the implementation, which is why I went down that path.
Because it will affect mangling only, do we have any examples of c/c++
code that appends _'s to it that is used by the D community?
Hi,
Will there be a new edition of Andrei A's "The D Programming
Language" (2010)? If so when will it be published?
Thanks!
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 w
On 8/2/2018 9:58 AM, Manu wrote:
Have you ever tried the alias method I proposed?
Of course, it's the only tool we have here, and a major source of my
frustration!
Why is it frustrating?
On 8/2/2018 2:05 AM, rikki cattermole wrote:
8. if any identifier starts with a keyword and ends with at minimum one _, one _
from the end of the identifier will be removed for mangling (but not e.g. lookup).
This will break existing code. A double underscore prefix is reserved for the
impleme
On Thu, 2 Aug 2018 at 02:05, Walter Bright via Digitalmars-d
wrote:
>
> On 8/1/2018 11:08 PM, Manu wrote:
> > We have demonstrated consistent ongoing issues and frustration for 6
> > years.
>
> Have you ever tried the alias method I proposed?
Of course, it's the
On Thursday, 2 August 2018 at 12:30:14 UTC, rikki cattermole
wrote:
On 03/08/2018 12:24 AM, Steven Schveighoffer wrote:
I've never seen it, but it's certainly valid C++ and in the
realm of possibility.
-Steve
I see, thanks.
That's easy to solve.
Split into a package, public import eac
with hijacking in D, where it doesn't
in C++ (as long as you don't ever use `using` declarations, or only use
one or the other).
So the difference from your example is that you're not trying to bind 2
different files with 2 different namespaces into one D module, but you
are trans
901 - 1000 of 41969 matches
Mail list logo