Re: On Forum Moderation

[Jonathan via Digitalmars-d]

On Saturday, 26 May 2018 at 03:34:50 UTC, Walter Bright wrote:

From time to time, the issue comes up.

The standard here is professional demeanor. For what 
professional demeanor is, see:


https://www.amazon.com/Etiquette-Society-Business-Politics-Home/dp/1497339979

Unprofessional demeanor will get removed at the forum staff's 
sole discretion on a case by case basis, as well as replies to 
it.


For unprofessional demeanor, I recommend reddit.


+1

[Issue 18907] Support cross-compiling

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18907

--- Comment #1 from Manu  ---
I should also add, this would be very useful for developing, but not JUST for
developing.

I have a couple of projects where we generate our windows builds from linux CI
infrastructure. We cross-compile our windows builds from linux, and DMD can't
currently participate in that workflow.
I have used wine to build for windows using DMD from linux in the past, and
that is... definitely less than ideal.

--

[Issue 18907] New: Support cross-compiling

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18907

  Issue ID: 18907
   Summary: Support cross-compiling
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

DMD is self-contained, and all the source is there to generate code for all
targets.
Can the target selection please be a runtime option?
It would be super handy even when *developing* DMD if it could cross-compile.
I'm working in windows, iterating on DMD, and every few minutes I run some test
compiles and see the windows output, but I'd love to also see the linux output
looks right.
Rather, I have to commit, push somewhere, sync on linux, build it there, and
run my tests.
That's a slow and pointless turnaround, when I'm sure it wouldn't be too hard
for DMD to just accept a --target option, then I could verify both outputs at
the same time from the same place. Save me hours of stuffing about!

So, any takers? :)

--

On Forum Moderation

[Walter Bright via Digitalmars-d]

From time to time, the issue comes up.

The standard here is professional demeanor. For what professional demeanor is, 
see:

https://www.amazon.com/Etiquette-Society-Business-Politics-Home/dp/1497339979

Unprofessional demeanor will get removed at the forum staff's sole discretion on 
a case by case basis, as well as replies to it.


For unprofessional demeanor, I recommend reddit.

[Issue 18470] std.algorithm.splitter has frame access problems for custom preds

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18470

Basile B.  changed:

   What|Removed |Added

   Keywords||pull

--

[Issue 18837] MMFile should have opDollar

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18837

Basile B.  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Basile B.  ---
Pull : https://github.com/dlang/phobos/pull/6521

--

[Issue 18470] std.algorithm.splitter has frame access problems for custom preds

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18470

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Severity|enhancement |normal

--- Comment #1 from Basile B.  ---
Pull : https://github.com/dlang/phobos/pull/6522

--

Re: C style callbacks fix for member callbacks

[IntegratedDimensions via Digitalmars-d-learn]

Investigating further, this does not seem to be pushed on the 
stack but set in EAX.


Hence no amount of parameter placement manipulation will work. It 
actually becomes an easy situation although this will be invalid 
as it will be be whatever value is in EAX used by the caller.


One cannot set this directly though but one does not have to use 
it. Therefor, simply using a member function here is the same as 
a static and no changes have to be made. Quite an easy fix. I do 
not know how safe it is. The docs say this is pushed and that is 
probably generally true.

Re: Any way to override base type with dervived in derived type

[IntegratedDimensions via Digitalmars-d-learn]

On Saturday, 26 May 2018 at 01:11:39 UTC, crimaniak wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions 
wrote:
I'm pretty much guaranteed that in C, t will be type TT due to 
the design(C goes with TT like bread with butter).

...
1) Your architecture is wrong, I recommend to rethink it.


Prove it genius! I recommend you rethink your absolutes without 
having a clue. Go back to SO, they need more Nazi's.


2) You still can deal with it using template mixins 
https://dlang.org/spec/template-mixin.html


I've already said templates do not work. Time to rethink your 
answers, they are useless and you are not an authority, quick 
acting like one.

Re: Draft for DIP concerning destroy is up.

[12345swordy via Digitalmars-d]

On Saturday, 26 May 2018 at 01:20:44 UTC, Mike Parker wrote:

On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote:

https://github.com/dlang/DIPs/pull/120

Feedback would be very appreciated.


From 
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#development-stage:


"The DIP Repository is not the place for the initial 
development of a DIP. The DIP Author(s) should develop the 
first draft of the DIP in the newly forked repository. A 
completed first draft is one that, if it were perfect and 
required no further revision, would be ready to proceed through 
the entirety of the DIP process.


If community feedback is desired during the Development Stage, 
the DIP Author(s) should announce in the D Forums that the DIP 
is in development and ask for feedback, providing a link to the 
DIP in the forked repository. Any pull request submitted to the 
DIP Repository before the DIP is in a first draft state will be 
rejected."


The DIP repository is not the place for draft development, but 
for draft review. If there are a lot of comments during 
development, it clutters up the review thread and makes it 
difficult later to follow the draft review comments.


I'm going to close the PR for now and ask that all feedback 
either be here or in the forked repository. When the DIP is 
ready for draft review, then we can open it up again.


And for future reference, anyone intending to submit a DIP, 
please make sure the draft is ready for review before 
submitting a PR.


Thanks!


k

Though I had posted a thread regarding my DIP and no one seems to 
care.



Alex

[Issue 18837] MMFile should have opDollar

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18837

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Severity|minor   |enhancement

--

[Issue 18875] String literals can't disambiguate between const(char)[] and const(char)* overload.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18875

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
  Component|phobos  |dmd

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18115

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Draft for DIP concerning destroy is up.

[Mike Parker via Digitalmars-d]

On Saturday, 26 May 2018 at 01:20:44 UTC, Mike Parker wrote:
ments.


I'm going to close the PR for now and ask that all feedback 
either be here or in the forked repository.


https://github.com/12345swordy/DIPs/blob/master/DIPs/DIP1xxx-attributefriendlydestroy.md

Re: Draft for DIP concerning destroy is up.

[Mike Parker via Digitalmars-d]

On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote:

https://github.com/dlang/DIPs/pull/120

Feedback would be very appreciated.


From 
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#development-stage:


"The DIP Repository is not the place for the initial development 
of a DIP. The DIP Author(s) should develop the first draft of the 
DIP in the newly forked repository. A completed first draft is 
one that, if it were perfect and required no further revision, 
would be ready to proceed through the entirety of the DIP process.


If community feedback is desired during the Development Stage, 
the DIP Author(s) should announce in the D Forums that the DIP is 
in development and ask for feedback, providing a link to the DIP 
in the forked repository. Any pull request submitted to the DIP 
Repository before the DIP is in a first draft state will be 
rejected."


The DIP repository is not the place for draft development, but 
for draft review. If there are a lot of comments during 
development, it clutters up the review thread and makes it 
difficult later to follow the draft review comments.


I'm going to close the PR for now and ask that all feedback 
either be here or in the forked repository. When the DIP is ready 
for draft review, then we can open it up again.


And for future reference, anyone intending to submit a DIP, 
please make sure the draft is ready for review before submitting 
a PR.


Thanks!

Re: Any way to override base type with dervived in derived type

[crimaniak via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions 
wrote:
I'm pretty much guaranteed that in C, t will be type TT due to 
the design(C goes with TT like bread with butter).

...
1) Your architecture is wrong, I recommend to rethink it.
2) You still can deal with it using template mixins 
https://dlang.org/spec/template-mixin.html

Re: extern(C++) template problem

[Manu via Digitalmars-d]

On 25 May 2018 at 11:28, Walter Bright via Digitalmars-d
 wrote:
> On 5/23/2018 10:48 AM, Manu wrote:
>>
>> Sadly, neither of these are correct.
>> The type is a class (has vtable, etc), so it is declared in D as a
>> class... It is also a class in C++, so it must mangle like a class.
>> It's also the case that it's passed by pointer, in C++ and in D. It's
>> a class that definitely behaves like a class.
>> The trouble is getting the class name into the function signature as
>> T, where the D compiler really wants to put Class* because that's the
>> type it sees a D class to be.
>
>
> One way is to create a wrapper for C in another module:
>
>  a.d -
> extern (C++) class C { ... }
>
>  b.d -
>
> import a;
>
> extern (C++) struct C {
> a.C m;
> alias m this;
> }
> --
>
> This relies on D regarding a.C and b.C as different symbols, even though
> they mangle the same.

Ah, interesting strategy!
Although, they don't mangle the same...

extern (C++, class) struct C { ... }

That should do it! :)

Re: Draft for DIP concerning destroy is up.

[sarn via Digitalmars-d]

Just had a thought: attributes are inferred for templates, so 
maybe the ProtoObject could have a templated empty destructor.  I 
don't think this would work with the existing destructor 
implementation, but it least it could be possible.

Re: Morale of a story: ~ is the right choice for concat operator

[Jonathan M Davis via Digitalmars-d]

On Friday, May 25, 2018 23:57:03 IntegratedDimensions via Digitalmars-d 
wrote:
> On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
> So, you think by forcing programmers to use a break, goto, or
> return at the end of a case somes errors but really what it does
> it make programmers less aware of the problems. They become less
> effective programmers in the long run.

I don't see how it makes anyone less effective. It catches a programming
mistake, and if you want to purposefully fall through to the next statement,
then use goto case;. No expressiveness is lost, and there's no problem that
the programmer is not left aware of.

> The mentality that you think you can police everything and that
> you also have the experience and knowledge to protect everyone is
> ignorant and provably catastrophic in the long run.

We can't protect everyone from everything. And what we've done here (or what
primarily Walter has done here) is to make some simple constructs that have
proven over time to cause bugs illegal. In each case, there's a simple
alternative that really doesn't cost you anything more. So, a simple mistake
is prevented without you losing expressiveness in the language and without
hiding problems. The programmer still has to do know what they're doing, and
they can still do exactly the same things that they could do before. It's
just that one class of mistake just became illegal in the language, so you
won't have that particular bug.

I really don't understand why you think that that's a bad thing. It would be
one thing if D prevented you from doing something the simple way and forced
you to bend over backwards to in order to be able to do it, but that's not
how we generally do things in D. In some cases, you do have to tell the
compiler that you know what you're doing and don't want the hand-holding
(e.g. with @safe vs @system), but in general, the stuff that's made illegal
is stuff that's going to cause problems, and the alternatives are pretty
much just as simple as what's being prevented.

You seem to be saying the programming equivalent to arguing that knives
don't need handles (just bare blades) and that anyone who wants to use a
knife should learn how to hold the blade properly without cutting
themselves.

No, we can't protect programmers from everything (and shouldn't try), but
that's no reason to give up on designing language features in a way that
minimizes stupid mistakes - especially when the result is just as expressive
and doesn't actually restrict the programmer.

If you want a language that doesn't protect you from anything, then C is
going to be a much better fit for you than D.

- Jonathan M Davis

Re: Morale of a story: ~ is the right choice for concat operator

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
On Friday, May 25, 2018 22:23:07 IntegratedDimensions via 
Digitalmars-d wrote:

On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
> On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
>> This ambiguity bug with + has been causing well-known 
>> problems since Algol. A *really* long time. Yet it gets 
>> constantly welded into new languages.

>
> Yeah. I could understand that choice for a language that 
> tries to be simple for beginners above everything else. But 
> for large-scale application language like C#, I quess this 
> just did not occur to them.


I used to program in C# quite regularly and never had this 
issue. It is not a problem of the language but a problem of 
the programmer.


A programmer should always know the types he is working and 
the functional semantics used. While it obviously has the 
potential to cause more problems it is not a huge deal in 
general. I might have been caught by that "bug" once or twice 
but it's usually an obvious fix. If you are moving from one 
language to another or haven't programming in one much you 
will have these types of problems, but they go away with 
experience. To degrade the language based on that is wrong. 
Languages should not be designed around noobs because then the 
programmers of that language stay noobs. Think BASIC. If all 
you did was programmed in basic then you would be considered a 
novice programmer by today's standards. If even you were an 
expert BASIC programmer, when you moved to a modern language 
you would be confused. For you to say that those languages are 
inferior because they don't do things like BASIC would be 
wrong, it is your unfamiliarity with the language and newer 
programming concepts that are the problem.


A language will never solve all your problems as a programmer, 
else it would write the programs for us.


Personally, I don't think that I've ever made the mistake of 
screwing up + and concatenating instead of adding or vice 
versa. And at the end of the day, the programmer does need to 
know the tools that they're using and use them correctly. That 
being said, the language (and other tools used for programming) 
can often be designed in a way that reduces mistakes - and all 
programmers make mistakes. e.g. in D, implicit fallthrough in 
case statements is now illegal if the case statement is 
non-empty. e.g.


switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
// illegal fallthrough
}
default: return 17;
}

Instead, the programmer must put a control flow statement there 
such as break or goto. e.g.


switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
goto case; // now explicitly goes to the next case 
statement

}
default: return 17;
}

Sure, it can be argued that this should be unnecessary and that 
the programmer should just get it right, but it's not an 
altogether uncommon bug to screw up case statements and 
invadvertently fall through to the next one when you meant to 
put a break or some other control statement there. Originally, 
implicit fallthrough was perfectly legal in D just like it is 
in C or C++. However, when it was made illegal, it caught quite 
a few bugs in existing programs - including at companies using 
D. This change to the language fixed bugs and almost certainly 
saved people time and money.


Designing a good programming language is a bit of an art. It's 
not always easy to decide when the language should be picky 
about something and when it should let the programmer shoot 
themselves in the foot, but there are plenty of cases where 
having the language be picky catches bugs that programmers 
would otherwise make all the time, because we're not perfect.


That's part of why we have @safe in D. It disallows all kinds 
of perfectly legitimate code, because it's stuff that's easy 
for the programmer to screw up and often hard for them to get 
right, and by having large sections of the program restricted 
in what is allowed prevents all kinds of bugs. Then in the 
cases where the programmer actually needs to do the unsafe 
stuff, they write @system code, manually verify that it's 
correct, and mark it as @trusted so that it can be called from 
@safe code. Then, when they run into a memory corruption issue 
later, they have a relatively small portion of the program that 
they need to inspect.


A well-designed language enables the programmer to do their job 
correctly and efficiently while protecting them from stupid 
mistakes where reasonably possible. Using ~ instead of + costs 
us almost nothing while preventing potential bugs. It's quickly 
learned when you first start using D, and then the code is 
clear about whether something is intended to be addition or 
concatenation without the 

Re: Draft for DIP concerning destroy is up.

[sarn via Digitalmars-d]

On Friday, 25 May 2018 at 21:01:16 UTC, Mike Franklin wrote:

On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote:

https://github.com/dlang/DIPs/pull/120

Feedback would be very appreciated.


I was under the impression that Andrei's ProtoObject was 
supposed to remedy that:  
https://forum.dlang.org/post/pa1lg6$1lud$1...@digitalmars.com


Mike


It's not enough for destructors because they work "both ways".

If we have a universal base class with a @nogc destructor, then 
no subclass can have a non-@nogc destructor.  In particular, it 
won't be compatible with today's Object.  But if the universal 
base class has a destructor that's not @nogc, then classes can't 
ever be destroyed in @nogc code because destructors need to 
recurse to base class destructors.


I think we have to either give up on having a sole universal base 
class, or special-case destructors in the language (or some 
combination of both).

Re: D's Destructors are What Scott Meyers Warned Us About

[sarn via Digitalmars-d]

On Thursday, 24 May 2018 at 12:26:00 UTC, Steven Schveighoffer 
wrote:
I added the bug report here: 
https://issues.dlang.org/show_bug.cgi?id=18903. I outline 
exactly how to fix it, if anyone wants an easy PR opportunity.


-Steve


Thanks for digging into that.

On Wednesday, 23 May 2018 at 23:18:46 UTC, Manu wrote:
On 23 May 2018 at 15:47, sarn via Digitalmars-d 
 wrote:
On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole 
wrote:


I would consider the current state with classes a bug.
So ticket please, it should not require a DIP to change 
(although Walter

may disagree).



Unfortunately, the way __dtor and __xdtor work for classes 
can't be changed without the risk of breaking code.  (Even if 
the current behaviour is broken, users might be working around 
it.)


In what way is the current behaviour *broken*? (as opposed to 
awkward, confusing, and poorly documented)


If c is a class instance, then c.__xdtor compiles and runs but 
can only be guaranteed to run the right destructors in special 
controlled cases where there's most likely a better way.


That std.signals code that Steven filed a bug report for is 
example of why we can't just fix the behaviour, though.  If we 
just fixed __dtor/__xdtor, any code that used std.signals would 
start having ugly bugs at run time.


I think that longer term we'll have to deprecate and remove these 
functions.

[Issue 15870] UFCS not recognized on array when passing as alias parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15870

Ivan Kazmenko  changed:

   What|Removed |Added

 CC||ga...@mail.ru

--- Comment #1 from Ivan Kazmenko  ---
Still does not work in 2.080 release.
The error message however is interesting.
Here is a modified example with a line containing `(a)` instead of `a`.
Compile with `dmd -main`:

-
import std.algorithm;
enum test(alias fun) = "it works";
immutable a = [1,2,3];

pragma(msg, typeof(a));   // immutable(int[])
pragma(msg, test!((a).map!(x => x))); // "it works"
pragma(msg, test!(a.map!(x => x)));   // template identifier `map` is not a
member of variable `a.a`
-

Why is that `a.a` in the first place?
Does the compiler mistake `a` for an eponymous template somehow, instead of
seeing that `map` is a template here?

--

Re: Morale of a story: ~ is the right choice for concat operator

[Jonathan M Davis via Digitalmars-d]

On Friday, May 25, 2018 22:23:07 IntegratedDimensions via Digitalmars-d 
wrote:
> On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
> > On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
> >> This ambiguity bug with + has been causing well-known problems
> >> since Algol. A *really* long time. Yet it gets constantly
> >> welded into new languages.
> >
> > Yeah. I could understand that choice for a language that tries
> > to be simple for beginners above everything else. But for
> > large-scale application language like C#, I quess this just did
> > not occur to them.
>
> I used to program in C# quite regularly and never had this issue.
> It is not a problem of the language but a problem of the
> programmer.
>
> A programmer should always know the types he is working and the
> functional semantics used. While it obviously has the potential
> to cause more problems it is not a huge deal in general. I might
> have been caught by that "bug" once or twice but it's usually an
> obvious fix. If you are moving from one language to another or
> haven't programming in one much you will have these types of
> problems, but they go away with experience. To degrade the
> language based on that is wrong. Languages should not be designed
> around noobs because then the programmers of that language stay
> noobs. Think BASIC. If all you did was programmed in basic then
> you would be considered a novice programmer by today's standards.
> If even you were an expert BASIC programmer, when you moved to a
> modern language you would be confused. For you to say that those
> languages are inferior because they don't do things like BASIC
> would be wrong, it is your unfamiliarity with the language and
> newer programming concepts that are the problem.
>
> A language will never solve all your problems as a programmer,
> else it would write the programs for us.

Personally, I don't think that I've ever made the mistake of screwing up +
and concatenating instead of adding or vice versa. And at the end of the
day, the programmer does need to know the tools that they're using and use
them correctly. That being said, the language (and other tools used for
programming) can often be designed in a way that reduces mistakes - and all
programmers make mistakes. e.g. in D, implicit fallthrough in case
statements is now illegal if the case statement is non-empty. e.g.

switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
// illegal fallthrough
}
default: return 17;
}

Instead, the programmer must put a control flow statement there such as
break or goto. e.g.

switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
goto case; // now explicitly goes to the next case statement
}
default: return 17;
}

Sure, it can be argued that this should be unnecessary and that the
programmer should just get it right, but it's not an altogether uncommon bug
to screw up case statements and invadvertently fall through to the next one
when you meant to put a break or some other control statement there.
Originally, implicit fallthrough was perfectly legal in D just like it is in
C or C++. However, when it was made illegal, it caught quite a few bugs in
existing programs - including at companies using D. This change to the
language fixed bugs and almost certainly saved people time and money.

Designing a good programming language is a bit of an art. It's not always
easy to decide when the language should be picky about something and when it
should let the programmer shoot themselves in the foot, but there are plenty
of cases where having the language be picky catches bugs that programmers
would otherwise make all the time, because we're not perfect.

That's part of why we have @safe in D. It disallows all kinds of perfectly
legitimate code, because it's stuff that's easy for the programmer to screw
up and often hard for them to get right, and by having large sections of the
program restricted in what is allowed prevents all kinds of bugs. Then in
the cases where the programmer actually needs to do the unsafe stuff, they
write @system code, manually verify that it's correct, and mark it as
@trusted so that it can be called from @safe code. Then, when they run into
a memory corruption issue later, they have a relatively small portion of the
program that they need to inspect.

A well-designed language enables the programmer to do their job correctly
and efficiently while protecting them from stupid mistakes where reasonably
possible. Using ~ instead of + costs us almost nothing while preventing
potential bugs. It's quickly learned when you first start using D, and then
the code is clear about whether something is intended to be addition or
concatenation without the programmer having to study it closely, and there
are cases like what the OP 

Re: Morale of a story: ~ is the right choice for concat operator

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:

On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:


This ambiguity bug with + has been causing well-known problems 
since Algol. A *really* long time. Yet it gets constantly 
welded into new languages.


Yeah. I could understand that choice for a language that tries 
to be simple for beginners above everything else. But for 
large-scale application language like C#, I quess this just did 
not occur to them.


I used to program in C# quite regularly and never had this issue. 
It is not a problem of the language but a problem of the 
programmer.


A programmer should always know the types he is working and the 
functional semantics used. While it obviously has the potential 
to cause more problems it is not a huge deal in general. I might 
have been caught by that "bug" once or twice but it's usually an 
obvious fix. If you are moving from one language to another or 
haven't programming in one much you will have these types of 
problems, but they go away with experience. To degrade the 
language based on that is wrong. Languages should not be designed 
around noobs because then the programmers of that language stay 
noobs. Think BASIC. If all you did was programmed in basic then 
you would be considered a novice programmer by today's standards. 
If even you were an expert BASIC programmer, when you moved to a 
modern language you would be confused. For you to say that those 
languages are inferior because they don't do things like BASIC 
would be wrong, it is your unfamiliarity with the language and 
newer programming concepts that are the problem.


A language will never solve all your problems as a programmer, 
else it would write the programs for us.

Re: Morale of a story: ~ is the right choice for concat operator

[Dukc via Digitalmars-d]

On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:


This ambiguity bug with + has been causing well-known problems 
since Algol. A *really* long time. Yet it gets constantly 
welded into new languages.


Yeah. I could understand that choice for a language that tries to 
be simple for beginners above everything else. But for 
large-scale application language like C#, I quess this just did 
not occur to them.

Re: Morale of a story: ~ is the right choice for concat operator

[Walter Bright via Digitalmars-d]

On 5/25/2018 1:27 AM, Dukc wrote:
So, ~ may be a bit confusing for newcomers, but there is a solid reason why it's 
used instead of +, and it's because they have a fundamentally different meaning. 
Good work, whoever chose that meaning!


This ambiguity bug with + has been causing well-known problems since Algol. A 
*really* long time. Yet it gets constantly welded into new languages.

Re: Draft for DIP concerning destroy is up.

[Mike Franklin via Digitalmars-d]

On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote:

https://github.com/dlang/DIPs/pull/120

Feedback would be very appreciated.


I was under the impression that Andrei's ProtoObject was supposed 
to remedy that:  
https://forum.dlang.org/post/pa1lg6$1lud$1...@digitalmars.com


Mike

Requesting some feedback for my Dub module for Meson

[Filipe Laíns via Digitalmars-d]

Hi, I am writing regarding my Dub module for Meson.
I wanted to check with the D community before my changes get 
merged.


The module allows you to use dependencies provided by Dub in 
Meson. It also allows you to automatically generate/update a 
dub.json file for your Meson project.


Due Meson's policies, we can't download or build anything using 
an external tool (Dub, in this case). My module only uses Dub as 
a dependency resolver, kinda like pkgconfig. You will need to 
build the dependencies before running meson.


Something to be aware when interfacing Dub and Meson is the 
compiler. The libraries that we are linking should be built with 
the same compiler Meson is using. This can be achieved as follows.


dub fetch vibe-d
dub build vibe-d compiler=ldc2
DC="ldc2" meson builddir

You can then use Dub to resolve the dependency as follows.

vibed_dep = dependency('vibe-d', method: 'dub')

You can generate/update a dub.json file for your project as 
follows.


dub = import('dub')
dub.generate_dub_file(meson.project_name().to_lower(), 
meson.source_root(),

  authors: 'Filipe Laíns',
  description: 'Test executable',
  copyright: 'Copyright © 2018, Filipe Laíns',
  license: 'MIT',
  sourceFiles: 'test.d',
  targetType: 'executable',
  dependencies: vibed_dep
)

The only required arguments for generate_dub_file() are the 
project name and the dub.json folder path.

All the other arguments can be passed as dictionaries.

key: 'value'

Currently, the module ignores configurations, subConfigurations, 
and buildTypes because that would require unnecessary additional 
code. You can configure that directly in dub.json. If you do 
manually change dub.json, the configurations should be kept 
unless you overwrite them in the meson config.


If you want to check the changes, you can take a look at the PR.
https://github.com/mesonbuild/meson/pull/3592

The questions I have to ask are:
  - Does this fit your needs?
  - Is there something I missed?
  - Would you like me to add other features?

Thank you,
Filipe Laíns (FFY00)
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

[Issue 18901] [Visual D] fatal error C1905: Front-End and Back-End are not compatible (have to use the same processor)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18901

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
This a C/C++ compiler message:
https://msdn.microsoft.com/en-us/library/414e6214.aspx

Are you building a C/C++ file with dub/visuald? Does building with dub work on
the command line? Can you build any C project in VS?

It seems that your VS installation is messed up.

--

Draft for DIP concerning destroy is up.

[12345swordy via Digitalmars-d]

https://github.com/dlang/DIPs/pull/120

Feedback would be very appreciated.

Re: Any way to override base type with dervived in derived type

[IntegratedDimensions via Digitalmars-d-learn]

On Friday, 25 May 2018 at 10:45:23 UTC, Steven Schveighoffer 
wrote:

On 5/24/18 4:24 PM, IntegratedDimensions wrote:


What I'd like to do is

class C : A
{
    private override @property TT t() { return cast(TT)(_t); } 
// null check if necessary

    // Stuff below uses t which is now a TT
    ...
}


It should work, you are allowed covariant overloads. However, 
private functions are not virtual, you need to make them at 
least protected.


-Steve


So, I upgraded everything, tried to add the setter and get an 
compile time access violation:



override @property T t(T v) { _t = v; return v; }

Changing T v to TT v gives the violation

override @property T t(TT v) { _t = v; return v; }


object.Error@(0): Access Violation

0x004850C8
0x00485C96
0x0043E22A
0x0047FB50
0x0046109A
0x0052401A
0x77D0B605 in LdrQueryProcessModuleInformation
0x77D11D02 in RtlQueryProcessLockInformation
0x77D11705 in RtlQueryProcessDebugInformation
0x77CA47DF in RtlAllocateHeap

While my specific use case is far more complex in design, the 
original essentially boils down to the dpaste I gave. Probably 
won't spent any time on it since I do not need the setter in this 
case(can use the field directly). But a bug is probably related 
to the code that fixed the "original bug" and possibly windows. 
What I do know is that 2.75 did not produce this access violation 
and it was the same code(I just uncommented out the setter).


The original dpaste code that did pass, I though, doesn't seem to 
pass now. I thought it was working for 2.80 and so I changed it 
to 2.69 and it failed but I might have made a mistake or the page 
lagged.


Either way, maybe you have a clue for future reference.

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 04:28:31 UTC, Jordan Wilson wrote:
On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, 
IntegratedDimensions wrote:
the idea in the first place. I needed a hammer but no one 
invented it. If I give you my use case then there would be 
two main outcomes: You attempt to find a workaround for the 
use case or claim that it is not applicable. These are the 
"I have a rock that should work as good as that hammer 
thingy you want" and "Hammers are useless".


3rd outcome: noobs like me who read the forums who benefit 
from such discussion.


Of course, you could be as disinterested in the 3rd outcome 
as you are the 1st and 2nd, and that's completely fair.


Jordan


Giving specific examples that are not applicable to your 
knowledge base won't help you. If you are too noobish to see 
how unifying foreach across non-arrays is useful then you have 
no experience where it is. Sure I could give some examples but 
then you have the option of excepting them as useful or saying 
they are too trivial.


If you can't think of examples on your own then you are 
probably not ready for the increase expressiveness of what the 
feature allows. It simply means don' t use the new feature. 
Why worry about something you don't understand?


void foo(T)(T t)
{
  foreach(a; t)
  {

  }
}

Does that help? I doubt it. If you are too much of a noob you 
won't get why the above makes certain things easier. If you 
don't have a good working knowledge of templates then you 
won't see how such a feature enhancement can simplify things.


So, I will solve the homework problem for you:

auto max(T)(T t)
{
  baseTypeOf(T) a;
  foreach(a; t)
 a = max(a,t)
  return a;
}

max(3) = 3
max([3,4,5]) = 5

See? and this is just an arbitrary example that I hope makes 
you happy. My examples are more complex and I don't see why it 
is necessary for me to waste 30m of my time extracting and 
developing a demo just to show that the feature is useful. It 
really boils down to the fact that if you can't see it being 
useful to you then it isn't and if you can then it is. A noob 
isn't going to be able to determine if the feature is sound or 
not so it is pointless for a noob to really worry about it.


I genuinely read these forums to increase my learning, and it's 
slow progress, but I believe it does help (obviously actually 
programming and looking at the many resources available online 
plays a big part too).


My intention wasn't to make you justify yourself; not at all. 
My intention was to simply to say that there are some people 
(well, maybe it is just me) who genuinely learn from more 
advanced programmers simply by reading their discussions with 
other advanced programmers.


I suppose I was just trying to be encouraging, but clearly it 
was more annoying, so my apologies for that.


No, not necessarily. Don't be offended. Nothing person. Maybe in 
a different context things would be different but I was attacked 
initially and you might have been caught in the cross fire.


My point was that you can't expect others to provide ever detail 
to you so you can learn. That is not the way to learn. You must 
learn to by getting behind having to be spoon fed. The only 
difference between a noob and a profession is the profession has 
learned how to read in between the lines. Noobs want training 
wheels because it makes them feel safe, but that is also what 
keeps them being a noob.


Just for you! (well I did for the other guy cause he was being an 
ass but I guess it worked out for you)


https://dpaste.dzfl.pl/1f5578364b6d


The point is that if you the people that know a little more have 
to spell everything out for the people who don't then it slows 
everyone down. It is up to the noobs to play catch up, not up to 
the "pros"(not that I would call myself a pro) to slow down.


Not everything is meant for noobs either, this question wasn't 
for noobs and was for people who knew what I was talking about 
and knew of a good solution. One person provided it out of about 
4-5. It should have been one response, his, and that is all. 
Maybe a few others could talk about specifics if interested but 
there should be no expectations on my part to waste any time on 
irrelevant things that do not progress the original topic. I 
asked a very specific question that had a very specific answer. 
Not really much room for other things... but you can see how it 
turns in to a whole shit storm by someone that didn't understand, 
gave a solution that wasn't really good, I told them, then they 
got upset and attacked me for this and that rather than just 
leave it be or try to satisfy my constraints. Sure, I could have 
been more clear, but it doesn't matter how clear someone is there 
will always be problems so there is a balance.


Do you want proof why? I will give it too since I feel like a 
giving mood:


1. I 

[Issue 18864] Building 64-bit dmd on Windows results in a debug build. The release build doesn't work.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18864

--- Comment #8 from ki...@gmx.net ---
(In reply to kinke from comment #7)
> I can confirm this regression for LDC on Win32 and Win64 too

I think I found the culprit causing the sporadic segfaults:
https://github.com/dlang/dmd/pull/8294

--

Re: extend foreach to work on non-arrays

[Jonathan M Davis via Digitalmars-d]

On Friday, May 25, 2018 19:06:54 IntegratedDimensions via Digitalmars-d 
wrote:
> Here is your "proper" example since you seem to need to be spoon
> fed like a little baby. I'm sorry, but if you can't read pseudo
> code you shouldn't be programming. To bitch at someone else for
> crossing your t's and dotting your i's when they have no
> obligation is not only moronic but selfish. I have better things
> to do then babysit you to make sure you can understand things.
> How bout you learn to code on your own so you can fill in the
> blanks rather than needing everything spelled out? I will only
> spell everything out once for you, don't expect it and don't ask
> for it any more:

Please, try to be polite. You don't have to like what someone says, but
please don't verbally attack anyone. Everyone here should be maintaining
something that at least approaches professional conduct.

Also, remember that in this thread, you're presenting an idea that you'd
like others to listen to and consider. Not everyone is going to instantly
agree with you or necessarily understand your explanation. There's nothing
wrong with them asking for clarification, and they don't have to agree with
you. You don't have to explain to them further either. But please act
professionally about it.

- Jonathan M Davis

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 04:09:55 UTC, Mike Parker wrote:
On Friday, 25 May 2018 at 03:24:32 UTC, IntegratedDimensions 
wrote:


Show me where I asked you to do any work for me. You are an 
imbecile. Just trying to stir up trouble because you obviously 
don't know how to read. You didn't like my response and so you 
are being a dick... simple as that. I'm sure you will get your 
supporters... some dicks like to other dicks.


What is your point? Where the fuck did I say that anyone 
needed to implement this feature? I like you parse things in 
ways that suit your agenda. Very convenient for you.


You seem to have a big problem communicating in a normal 
fashion. I tried to communicate on your level. Hopefully you 
understand me this time.


This sort of aggression is not appreciated in these forums. 
There's nothing in his post to warrant such a response. Please 
tone it down.


Thanks!


Way to take sides. Where was no aggression in my original post 
and he intentionally manipulated what I said and attacked me, yet 
you try to reprimand me? How about you try being fair and 
objective? Maybe this shit wouldn't happen if people like him 
didn't jump the gun and people like you wouldn't back him up 
allowing such behavior? I can be peaceful and cordial but I 
expect the same.


Show me where I attacked first and I will admit guilt and 
apologize! Show me! I dare you! If not, then STFU because you are 
part of the problem. If you don't like my attitude then don't 
have one yourself. Veiling your bias in nice tones does not 
admonish you of guilt. Wanting me to behave because I go 
overboard on someone who started it is exactly why I went 
overboard. Because you will allow the more subtle attacks 
because, what? They don't involve cuss words? Because they are 
outright threatening? Check your buddy and stop supporting his 
behavior and maybe these things won't happen? Kinda hard to do 
when your biased though?

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 09:57:20 UTC, meppl wrote:
On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, 
IntegratedDimensions wrote:

[...]


3rd outcome: noobs like me who read the forums who benefit 
from such discussion.


Of course, you could be as disinterested in the 3rd outcome 
as you are the 1st and 2nd, and that's completely fair.


Jordan






So, I will solve the homework problem for you:

auto max(T)(T t)
{
  baseTypeOf(T) a;
  foreach(a; t)
 a = max(a,t)
  return a;
}

max(3) = 3
max([3,4,5]) = 5




you didnt take your time to give a proper example. That code is 
wrong in multiple ways. People would have to reconstruct your 
code


Why should I take my time to give a fucking proper example? Why 
the hell are you people so retarded?


https://dpaste.dzfl.pl/1f5578364b6d


Here is your "proper" example since you seem to need to be spoon 
fed like a little baby. I'm sorry, but if you can't read pseudo 
code you shouldn't be programming. To bitch at someone else for 
crossing your t's and dotting your i's when they have no 
obligation is not only moronic but selfish. I have better things 
to do then babysit you to make sure you can understand things. 
How bout you learn to code on your own so you can fill in the 
blanks rather than needing everything spelled out? I will only 
spell everything out once for you, don't expect it and don't ask 
for it any more:



import std.stdio;

auto elseOnly(T)(T t) {
  import std.range: isInputRange;
  static if (isInputRange!T) {
return t;
  } else  {
import std.range: only;
return only(t);
  }
}

auto max(T)(T a, T b)
{
return (a >= b) ? a : b;
}

auto max(T)(T t)
{
  import std.traits;
  static if (isArray!(T)) typeof(t[0]) c; else T c;


  foreach(a; t.elseOnly())
 c = max(a,c);
  return c;
}

void main()
{
auto x = max(3);
auto y = max([3,4,5]);

writeln(x);
writeln(y);

}

If there is some specific problem with you not understanding 
pseudo code then you can ask for clarification, but don't try to 
pretend it is my problem for your ignorance.

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-05-24 22:06, Basile B. wrote:


Ahhh i was forgetting, the linker...


The LLVM linker, LLD, works pretty well on Windows.


--
/Jacob Carlborg

Re: Any way to override base type with dervived in derived type

[IntegratedDimensions via Digitalmars-d-learn]

On Friday, 25 May 2018 at 10:45:23 UTC, Steven Schveighoffer 
wrote:

On 5/24/18 4:24 PM, IntegratedDimensions wrote:


What I'd like to do is

class C : A
{
    private override @property TT t() { return cast(TT)(_t); } 
// null check if necessary

    // Stuff below uses t which is now a TT
    ...
}


It should work, you are allowed covariant overloads. However, 
private functions are not virtual, you need to make them at 
least protected.


-Steve


Wow, I didn't expect that! Thanks, exactly what I needed.

Unfortunately property setters seem to be broken.

https://dpaste.dzfl.pl/24ce8c7e0681

Seems this is a bug though that has been fix as it only happens 
on certain the older compilers. I had to downgrade because in the 
latest I get a lot of link errors ;/

Re: extern(C++) template problem

[Walter Bright via Digitalmars-d]

On 5/23/2018 10:48 AM, Manu wrote:

Sadly, neither of these are correct.
The type is a class (has vtable, etc), so it is declared in D as a
class... It is also a class in C++, so it must mangle like a class.
It's also the case that it's passed by pointer, in C++ and in D. It's
a class that definitely behaves like a class.
The trouble is getting the class name into the function signature as
T, where the D compiler really wants to put Class* because that's the
type it sees a D class to be.


One way is to create a wrapper for C in another module:

 a.d -
extern (C++) class C { ... }

 b.d -

import a;

extern (C++) struct C {
a.C m;
alias m this;
}
--

This relies on D regarding a.C and b.C as different symbols, even though they 
mangle the same.

Re: DConf 2018 Videos

[Walter Bright via Digitalmars-d]

On 5/21/2018 10:50 PM, Nicholas Wilson wrote:
As Ali said Walter will be giving his talk again (some conference in Poland 
(Krakow?,  code eu? can't remember the name).


It was at Code Europe 2018 in Krakow on May 8. They said it would take a month 
for them to upload the videos on youtube. I'll announce it when they do.

Re: PIMPL Idiom in D

[Walter Bright via Digitalmars-d]

On 5/22/2018 6:27 AM, Steven Schveighoffer wrote:

There's no need for the private struct.


That is correct. But pragmatically, I wanted the public interface to be very 
small and easily inspected. The struct is very large with many dependencies and 
hard to inspect to see what is public and what is private.

[Issue 18906] Template specialisations should not be stripped if they're not called

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18906

--- Comment #2 from Manu  ---
It's a specialisation.

Someone might call `t!(IDontKnowWhat)(value);`, and if IDontKnowWhat is int, it
should use that specialisation, and if it's not, it should instantiate the
generic unspecialised one.

It also affects function mangling, and extern linkage.

--

[Issue 18906] Template specialisations should not be stripped if they're not called

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18906

Nathan S.  changed:

   What|Removed |Added

 CC||n8sh.second...@hotmail.com

--- Comment #1 from Nathan S.  ---
```
  int t(T : int)(int x)
  {
return x * 2;
  }
```

What is the point of the template?

--

Re: An analysis of dimensional analysis

[12345swordy via Digitalmars-d]

On Friday, 25 May 2018 at 02:28:10 UTC, Andrei Alexandrescu wrote:
...in various languages, including D: 
https://www.reddit.com/r/programming/comments/8lwfis/dimensional_analysis_in_programming_languages/


"The inclusion of dimensional analysis support in the Phobos 
standard library has been discussed for several years and seems 
to be an ongoing effort. So far there have been only a couple 
major community projects."


How it is coming so far?


Alex

[Issue 18864] Building 64-bit dmd on Windows results in a debug build. The release build doesn't work.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18864

ki...@gmx.net changed:

   What|Removed |Added

 CC||ki...@gmx.net

--- Comment #7 from ki...@gmx.net ---
(In reply to Atila Neves from comment #1)
> Further information:  the 64-bit dmd artifact from AppVeyor also seems to
> fail with -int.max/2 every now and again, as does any dmd I compiled with
> dmd 2.080.0 on Windows. It doesn't always fail, but it results in flaky CI
> builds.

I can confirm this regression for LDC on Win32 and Win64 too; I first wrongly
attributed it to AppVeyor strangeness. After compiling LDC master with itself
and then repeatedly building dub finally led to a frontend crash after about 10
runs, here's the call stack:

#0 0x7ff6bcf99419 Expression::checkPurity(struct Scope *,class
VarDeclaration *) C:\LDC\ldc\dmd\expression.d:2133:13
#1 0x7ff6bcfa73d7 ExpressionSemanticVisitor::visit(class CallExp *)
C:\LDC\ldc\dmd\expressionsem.d:2927:17
#2 0x7ff6bcf98c8f
_D3dmd13expressionsem18resolvePropertiesXFPSQBq6dscope5ScopeCQCh10expression10ExpressionQBcZQBg
C:\LDC\ldc\dmd\expressionsem.d:156:17
#3 0x7ff6bceb01d3 resolveProperties(struct Scope *,class Expression *)
C:\LDC\ldc\dmd\expressionsem.d:332:5
#4 0x7ff6bcf99fb0
_D3dmd13expressionsem21preFunctionParametersFPSQBt6dscope5ScopePSQCl4root5array__T5ArrayTCQDk10expression10ExpressionZQBkZb
C:\LDC\ldc\dmd\expressionsem.d:468:13
#5 0x7ff6bcfa7626 ExpressionSemanticVisitor::visit(class CallExp *)
C:\LDC\ldc\dmd\expressionsem.d:2962:9
#6 0x7ff6bcecdd0e StatementSemanticVisitor::visit(class ExpStatement *)
C:\LDC\ldc\dmd\statementsem.d:179:13
#7 0x7ff6bcece5ad StatementSemanticVisitor::visit(class CompoundStatement
*) C:\LDC\ldc\dmd\statementsem.d:237:17
#8 0x7ff6bcecf41c StatementSemanticVisitor::visit(class ScopeStatement *)
C:\LDC\ldc\dmd\statementsem.d:415:13
#9 0x7ff6bced0973
_D3dmd12statementsem15semanticNoScopeFCQBl9statement9StatementPSQCk6dscope5ScopeZQBr
C:\LDC\ldc\dmd\statementsem.d:4293:5
#10 0x7ff6bcecfd7c
_D3dmd12statementsem13semanticScopeFCQBj9statement9StatementPSQCi6dscope5ScopeQBqQBtZQBx
C:\LDC\ldc\dmd\statementsem.d:4307:5
#11 0x7ff6bcee6fe7 StatementSemanticVisitor::visit(class TryCatchStatement
*) C:\LDC\ldc\dmd\statementsem.d:3824:9
#12 0x7ff6bcece5ad StatementSemanticVisitor::visit(class CompoundStatement
*) C:\LDC\ldc\dmd\statementsem.d:237:17
#13 0x7ff6bcefb06b Semantic3Visitor::visit(class FuncDeclaration *)
C:\LDC\ldc\dmd\semantic3.d:610:17
#14 0x7ff6bcef8ce2 Semantic3Visitor::visit(class TemplateInstance *)
C:\LDC\ldc\dmd\semantic3.d:134:17
#15 0x7ff6bcfe035c
_D3dmd10dsymbolsem24templateInstanceSemanticFCQBs9dtemplate16TemplateInstancePSQCz6dscope5ScopePSQDr4root5array__T5ArrayTCQEq10expression10ExpressionZQBkZv
C:\LDC\ldc\dmd\dsymbolsem.d:5696:13
#16 0x7ff6bcf43328
_D3dmd9dtemplate15functionResolveFPSQBi11declaration5MatchCQCf7dsymbol7DsymbolSQCz7globals3LocPSQDq6dscope5ScopePSQEi4root5array__T5ArrayTCQFhQz10rootobject10RootObjectZQBmCQGp5mtype4TypePSQHfQCxQCv__TQCsTCQHw10expression10ExpressionZQDzPPxaZv
C:\LDC\ldc\dmd\dtemplate.d:2831:9
#17 0x7ff6bced8eb0 resolveFuncCall(struct Loc const &,struct Scope *,class
Dsymbol *,struct Array *,class Type *,struct Array *,int) C:\LDC\ldc\dmd\func.d:2749:5
#18 0x7ff6bcfa83e4 ExpressionSemanticVisitor::visit(class CallExp *)
C:\LDC\ldc\dmd\expressionsem.d:3406:17
#19 0x7ff6bcecdd0e StatementSemanticVisitor::visit(class ExpStatement *)
C:\LDC\ldc\dmd\statementsem.d:179:13
#20 0x7ff6bcece5ad StatementSemanticVisitor::visit(class CompoundStatement
*) C:\LDC\ldc\dmd\statementsem.d:237:17
#21 0x7ff6bcefb06b Semantic3Visitor::visit(class FuncDeclaration *)
C:\LDC\ldc\dmd\semantic3.d:610:17
#22 0x7ff6bcef8ce2 Semantic3Visitor::visit(class TemplateInstance *)
C:\LDC\ldc\dmd\semantic3.d:134:17
#23 0x7ff6bcfe040a
_D3dmd10dsymbolsem24templateInstanceSemanticFCQBs9dtemplate16TemplateInstancePSQCz6dscope5ScopePSQDr4root5array__T5ArrayTCQEq10expression10ExpressionZQBkZv
C:\LDC\ldc\dmd\dsymbolsem.d:5644:9
#24 0x7ff6bcf43328
_D3dmd9dtemplate15functionResolveFPSQBi11declaration5MatchCQCf7dsymbol7DsymbolSQCz7globals3LocPSQDq6dscope5ScopePSQEi4root5array__T5ArrayTCQFhQz10rootobject10RootObjectZQBmCQGp5mtype4TypePSQHfQCxQCv__TQCsTCQHw10expression10ExpressionZQDzPPxaZv
C:\LDC\ldc\dmd\dtemplate.d:2831:9
#25 0x7ff6bced8eb0 resolveFuncCall(struct Loc const &,struct Scope *,class
Dsymbol *,struct Array *,class Type *,struct Array *,int) C:\LDC\ldc\dmd\func.d:2749:5
#26 0x7ff6bcfa83e4 ExpressionSemanticVisitor::visit(class CallExp *)
C:\LDC\ldc\dmd\expressionsem.d:3406:17
#27 0x7ff6bcecdd0e StatementSemanticVisitor::visit(class ExpStatement *)
C:\LDC\ldc\dmd\statementsem.d:179:13
#28 0x7ff6bcece5ad StatementSemanticVisitor::visit(class CompoundStatement
*) 

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

[Meta via Digitalmars-d-announce]

On Thursday, 24 May 2018 at 20:10:24 UTC, Walter Bright wrote:
Maybe. I was thinking about using DasBetterC for the DMC 
runtime library instead of C :-)


That would be very cool Walter.

Re: Stopping compile time execution

[Russel Winder via Digitalmars-d-learn]

On Sat, 2018-05-26 at 04:00 +1200, rikki cattermole via Digitalmars-d-
learn wrote:
> […]
> 
> Use a module constructor to initialize your global.

Splendid idea! :-)

I know, I should have thought of that.

I note that if you click "Constructor" on https://dlang.org/spec/module
.html
you get taken to https://dlang.org/spec/class.html#Constructor which
really does help describe the concept of a module constructor.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: Why Is D So Slow?

[Kagamin via Digitalmars-d]

On Friday, 25 May 2018 at 01:11:38 UTC, Kaleb McKinney wrote:

What would the antivirus be doing to slow it down?


One approach to behavioral detection is when the antivirus has an 
emulator that executes the analyzed program to see if it will do 
something nasty. Viruses are usually not written in python, so 
this emulation can be skipped for python programs.

Re: Stopping compile time execution

[rikki cattermole via Digitalmars-d-learn]

On 26/05/2018 3:58 AM, Russel Winder wrote:

I have a bit of code which is the definition of a class Preferences,
which has:

this() {
filePath = expandTilde(chainPath("~", ".config", "me-tv", 
"preferences.yml").array);

filePath is a member of the class. Now if I have a module level
instance (clearly not a good move but OK for now):

public auto preferences = new Preferences;

then Dub using DMD on Debian Sid gives me:

/usr/include/dmd/phobos/std/path.d(3970,31): Error: getenv cannot be 
interpreted at compile time, because it has no available source code
/usr/include/dmd/phobos/std/path.d(4064,41):called from here: 
expandFromEnvironment(inputPath)
source/preferences.d(36,25):called from here: expandTilde(array(chainPath("~", ".config", 
"me-tv", "preferences.yml")))

What is the official way of getting preferences initialised at run time
and not compile time.


Use a module constructor to initialize your global.

Stopping compile time execution

[Russel Winder via Digitalmars-d-learn]

I have a bit of code which is the definition of a class Preferences,
which has:

this() {
filePath = expandTilde(chainPath("~", ".config", "me-tv", 
"preferences.yml").array);

filePath is a member of the class. Now if I have a module level
instance (clearly not a good move but OK for now):

   public auto preferences = new Preferences;

then Dub using DMD on Debian Sid gives me:

/usr/include/dmd/phobos/std/path.d(3970,31): Error: getenv cannot be 
interpreted at compile time, because it has no available source code
/usr/include/dmd/phobos/std/path.d(4064,41):called from here: 
expandFromEnvironment(inputPath)
source/preferences.d(36,25):called from here: 
expandTilde(array(chainPath("~", ".config", "me-tv", "preferences.yml")))

What is the official way of getting preferences initialised at run time
and not compile time.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: extend foreach to work on non-arrays

[Neia Neutuladh via Digitalmars-d]

On Friday, 25 May 2018 at 07:39:03 UTC, Cym13 wrote:
Please note that Mike Parker stepped in for you too. I don't 
think there's much merit in stirring mud any further.


Yes, between when I started writing a reply and when I posted 
that reply. Editing posts isn't allowed here.

[Issue 18864] Building 64-bit dmd on Windows results in a debug build. The release build doesn't work.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18864

--- Comment #6 from Atila Neves  ---
The same code compiles with dmd 2.080.0. The failures are random.

--

Re: Ideas for students' summer projects

[rikki cattermole via Digitalmars-d]

On 26/05/2018 2:13 AM, meppl wrote:

On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


Let the brainstorming begin!


Make WebAssembly a thing in D.

See https://forum.dlang.org/post/ejplfelcqsvjmdvxt...@forum.dlang.org

Currently C++ and Rust dominate that domain.  D could kick some web 
asm there too.


Mike


I am curious about binary size of microservies on webpages. D-binaries 
tend to be bigger and the D garbage collector needs to be within them. 
Then we would have to rely on LLVM drastically reducing the binary size 
of static compiled apps.


If we say "its only for betterc" or "its only for bigger webapps and 
nodejs-webassembly", it would be half assed - and in my humble opinion 
too much of a disadvantage compared to rust. I might be wrong of course


Until web assembly's GC interface and TLS is designed, -betterC would be 
the correct solution for us going forward.

Re: Ideas for students' summer projects

[meppl via Digitalmars-d]

On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


Let the brainstorming begin!


Make WebAssembly a thing in D.

See 
https://forum.dlang.org/post/ejplfelcqsvjmdvxt...@forum.dlang.org


Currently C++ and Rust dominate that domain.  D could kick some 
web asm there too.


Mike


I am curious about binary size of microservies on webpages. 
D-binaries tend to be bigger and the D garbage collector needs to 
be within them. Then we would have to rely on LLVM drastically 
reducing the binary size of static compiled apps.


If we say "its only for betterc" or "its only for bigger webapps 
and nodejs-webassembly", it would be half assed - and in my 
humble opinion too much of a disadvantage compared to rust. I 
might be wrong of course

Re: Ideas for students' summer projects

[Mike Franklin via Digitalmars-d]

On Friday, 25 May 2018 at 12:23:35 UTC, Seb wrote:

I just gave converting the DMD Make build script to D a quick 
shot and it doesn't look too complicated:


Very Nice!  Many thumbs up!  And, welcome back!

Mike

Re: Ideas for students' summer projects

[Seb via Digitalmars-d]

On Wednesday, 23 May 2018 at 03:56:32 UTC, Mike Franklin wrote:

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


Let the brainstorming begin!


Building and running the DMD test suite on vanilla Windows is a 
pain.  I never succeeded but it appears to require the user to 
first set up a posix environment and then battle environment 
configuration, and other vague dependencies such as whether you 
are building for 32-bit or 64-bit and whether Visual Studio 
2017 is installed.


I believe most contribute to D with a Linux development 
machine, but sometimes there are Windows-only issues that need 
to be solved.  For that we need to be able to build and test 
our changes on Windows without hassle.


I'd like to see the requirement for a posix environment lifted 
by porting all makefiles to D, so the same code (with 
appropriate `version`ing of course) could be used to compile 
and build dlang repositories on all platforms without a lot of 
environment setup and configuration.  All that would be 
required a recent D compiler in one's PATH.


See https://github.com/dlang/dmd/pull/8162 for some working 
moving in that direction.


Mike


Yep, `test/run.d` is a first step in this direction and apart 
from the few shell tests, it should allow running the DMD 
testsuite without the prior hassles. Though for the shell tests, 
just using the shell shipped with the Windows version of Git is 
enough.


I just gave converting the DMD Make build script to D a quick 
shot and it doesn't look too complicated:


https://github.com/dlang/dmd/pull/8293

[Issue 18833] [REG 2.073] DMD in some cases forgets to generate wrapping TypeInfo for modifiers on classes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18833

--- Comment #4 from Steven Schveighoffer  ---
Mike,

We worked through all that at dconf (including putting your recommended print
statements, etc). What is happening is that the call to see if dmd should
generate the TypeInfo *is* made, but the compiler decides it doesn't have to
because it believes the TypeInfo has already been generated in the imported
module.

The real problem here is that the compiler treats the class typeinfo that has
the const flag set identically to how it treats the class typeinfo that doesn't
have the const flag set. In other words, it elides generating the
Const_TypeInfo wrapper because it has already generated the TypeInfo_Class.

It's really difficult to explain, but look at the function in dsymbolsem.d that
sets the instantiated module to null.

Then look at typinf.d for isSpeculativeType.

The decision not to generate the Const_TypeInfo is confused with the decision
not to instantiate the class that it wraps. I don't know how to extract them
into 2 separate decisions, which is why I'm not the one to solve this. Still
getting my feet wet with DMD development.

--

Re: Any way to override base type with dervived in derived type

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/24/18 4:24 PM, IntegratedDimensions wrote:


What I'd like to do is

class C : A
{
    private override @property TT t() { return cast(TT)(_t); } // null 
check if necessary

    // Stuff below uses t which is now a TT
    ...
}


It should work, you are allowed covariant overloads. However, private 
functions are not virtual, you need to make them at least protected.


-Steve

Re: extend foreach to work on non-arrays

[Steven Schveighoffer via Digitalmars-d]

On 5/25/18 12:31 AM, Neia Neutuladh wrote:



I've first-hand experience with moderation on this forum: nothing 
public, at most a private email from Walter or Andrei.


This does a terrible job of setting expectations of community behavior. 
It makes it look like there is no moderation at all. I have no idea 
whether the moderation I experienced was unique or standard -- do most 
people not even get a warning? If someone is rude to me, are they 
tolerated while I am rebuked?


There is a "flag" link on a post on the forum, if you click it, then a 
message gets sent to an administrator who may or may not remove the 
post. In this case, the response to this post was removed, proving 
moderation does happen. I don't know what happens privately, as I've 
never been warned.


The truth is, the forum is very lightly moderated. We are generally 
pretty tolerant of legitimate conversation, even if it's peppered with 
some salty language. In this case, I'd consider the conversation from 
the IntegratedDimensions side to be pretty low quality.



I hope that policy changes.


There is rudeness, which is tolerated to a certain degree, and then 
there is nothing-but-ad-hominem abuse and harrassment, which describes 
the previous post that I purposely did not quote.


The former is likely to get you nowhere, but isn't considered worthy of 
removal IMO. The latter needs to be dealt with, and is usually done by 
removing the post in question. It can result in banning as well.


And finally, there's spam, which generally gets you banned.

So while there's no formal policy, what happens is effective IMO.

-Steve

Re: extend foreach to work on non-arrays

[Stefan Koch via Digitalmars-d]

On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions 
wrote:

Doesn't make any sense?

foreach(a; x)

if x is not an array then a = x and the loop reduces simply and 
function to the case it is not so their can be no harm.


It unifies the concepts so that one does not have to worry if x 
is an array or not and can offer no harm since when x is not an 
array everything simply reduces to an an alias of x.


please look at opApply.

Re: extend foreach to work on non-arrays

[meppl via Digitalmars-d]

On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions 
wrote:

[...]


3rd outcome: noobs like me who read the forums who benefit 
from such discussion.


Of course, you could be as disinterested in the 3rd outcome as 
you are the 1st and 2nd, and that's completely fair.


Jordan






So, I will solve the homework problem for you:

auto max(T)(T t)
{
  baseTypeOf(T) a;
  foreach(a; t)
 a = max(a,t)
  return a;
}

max(3) = 3
max([3,4,5]) = 5




you didnt take your time to give a proper example. That code is 
wrong in multiple ways. People would have to reconstruct your code

[Issue 18786] AV program detects malware in windows download of DMD

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18786

--- Comment #8 from David M  ---
Greenify, I hear you in that I know D is open source software run by
volunteers, and that means no-one needs to look after reports like this if they
don't want to.

If it was one AV vendor, I'd happily report it.  It's up to 21% of vendors on
Virustotal now, though, and that means a couple of things:

* I, as a new D user, do not have the knowledge and background to state to a
vendor that it is truly virus free.  If the runtime causes problems, I can't
explain what and why.  You can't ask I report it, because you're asking me to
make statements to the vendor that I don't have the knowledge to back up. 
("Can you take this package on board the airplane for me? No bombs, promise." 
Later, at security, "No, no bombs. Oh, no, it's not my package.  No, I don't
know what's in it.  It's locked, I don't have the key.  But no bombs.  I'm
sure.")

The only people who can speak to an AV with authority and assist them in
finding why it is a false positive are those with a good understanding of the
RTL and the patterns in it that are causing the AV to be concerned.

* A large number of AVs is a danger sign, and if this was my own software I'd
be investigating, even if I believed there was no cause for concern.  I have
done that in the past for even a single AV report.

* This impacts your users.  Currently, no-one on Windows 10 can install D
because the installer is captured by Windows Defender.  The importance of that
depends on the value you put on allowing Windows users to use D.  I'll be
frank: I'm new to D, and I downloaded to try it out and learn it.  It's not
reasonable to expect any new user to ignore thirteen different antivirus
vendors screaming "don't run it!" and to bypass security on their local system
to install.

--

Re: toString OutputWriter method not calling derived class

[rikki cattermole via Digitalmars-d-learn]

On 25/05/2018 9:21 PM, cc wrote:
When defining a toString(W)(ref W writer) function on a base class and 
derived class, only the version on the base class is called when 
formatting into a string.  Is this intended behavior?


import std.format;
import std.range.primitives;
class Foo {
 string test() {
     return "Foo?";
 }
 void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
     put(writer, "");
 }
}
class Bar : Foo {
 override string test() {
     return "Bar?";
 }
 void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
     put(writer, "");
 }
}
Foo[] list = [new Foo(), new Bar()];
foreach(i, item; list) {
 writefln("%d: %s (%s)", i, item, item.test());
}


Result:
0:  (Foo?)
1:  (Bar?)



Yes, because templates are not virtual.

toString OutputWriter method not calling derived class

[cc via Digitalmars-d-learn]

When defining a toString(W)(ref W writer) function on a base 
class and derived class, only the version on the base class is 
called when formatting into a string.  Is this intended behavior?


import std.format;
import std.range.primitives;
class Foo {
string test() {
return "Foo?";
}
void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
put(writer, "");
}
}
class Bar : Foo {
override string test() {
return "Bar?";
}
void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
put(writer, "");
}
}
Foo[] list = [new Foo(), new Bar()];
foreach(i, item; list) {
writefln("%d: %s (%s)", i, item, item.test());
}


Result:
0:  (Foo?)
1:  (Bar?)

Morale of a story: ~ is the right choice for concat operator

[Dukc via Digitalmars-d]

I was programming in C# and wanted to format an int in 
hexadecimal. It may be that I should have used some library 
function for that, but I decided to roll my own function for that 
anyway, in my general utility class:


public static string FormatHexadecimal(int what)
{   if (what == 0) return "0";
string result = "";
bool signed = what < 0;
if (signed) what = -what;

for (;what != 0;what >>= 4)
{   int digit = what & 0x000F;
		result = (digit < 10? '0' + (char)digit: 'A' + (char)(digit - 
10)) + result;

}

return signed? "-" + result: result;
}

Looks correct, right? Yes.

But quess what? Op+ has a double meaning in C#, depending on 
context it means either addition or string concatenation. If you 
add two characters, it interprets it as a concatenation that 
results in a string with two charactes.  The correct way to do 
what I tried is:


public static string FormatHexadecimal(int what)
{   if (what == 0) return "0";
string result = "";
bool signed = what < 0;
if (signed) what = -what;

for (;what != 0;what >>= 4)
{   int digit = what & 0x000F;
result = (char)(digit < 10? (int)'0' + digit: (int)'A' + 
(digit - 10)) + result;

}

return signed? "-" + result: result;
}

You can imagine me confused when the first version returned way 
too long and incorrect strings. Now, if I were programming in D, 
this would not have happened. Using + always means an addition. 
If one wants to concatenate, ~ is used instead.


So, ~ may be a bit confusing for newcomers, but there is a solid 
reason why it's used instead of +, and it's because they have a 
fundamentally different meaning. Good work, whoever chose that 
meaning!

[Issue 18906] New: Template specialisations should not be stripped if they're not called

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18906

  Issue ID: 18906
   Summary: Template specialisations should not be stripped if
they're not called
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

extern(C++) class C
{
  T t(T)(T x);
  int t(T : int)(int x)
  {
return x * 2;
  }
}

Given the code above, the symbol `t!int` will NOT be emit to the object unless
something somewhere calls that instantiation.
I think this is wrong, an explicit specialisation like this needs to go in the
object file regardless, it was hand-written, and it might be used externally
(in my case, it is used externally).

Likewise, we should have a method to force an instantiation of a template into
the object like C++ has. For instance, C++ for the above:
  `template float C::t(float);`

Causes explicit instantiation of the template for float.

Perhaps D already has this syntax, but I don't know what it is?

--

Re: extend foreach to work on non-arrays

[Cym13 via Digitalmars-d]

On Friday, 25 May 2018 at 04:31:54 UTC, Neia Neutuladh wrote:
I've first-hand experience with moderation on this forum: 
nothing public, at most a private email from Walter or Andrei.


This does a terrible job of setting expectations of community 
behavior. It makes it look like there is no moderation at all. 
I have no idea whether the moderation I experienced was unique 
or standard -- do most people not even get a warning? If 
someone is rude to me, are they tolerated while I am rebuked?


I hope that policy changes.


Please note that Mike Parker stepped in for you too. I don't 
think there's much merit in stirring mud any further.

[Issue 18893] extern(C++) class RTTI

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18893

Manu  changed:

   What|Removed |Added

   Keywords||C++, industry

--

Re: extend foreach to work on non-arrays

[aliak via Digitalmars-d]

On Thursday, 24 May 2018 at 23:28:59 UTC, IntegratedDimensions 
wrote:
cool, and this is optimal, right? non-arrays are not converted 
in to arrays, etc?


Seems they are not converted no, but it loops like an extra 
variable is stored though (a bool to denote existence of a value)


https://github.com/dlang/phobos/blob/v2.080.0/std/range/package.d#L9512

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #19 from Manu  ---
extern(C++) in D is fraught with perils. When working on a multi-language
program, you really need those symbols and the vtable is super useful to know
everything's in good state.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #18 from Rainer Schuetze  ---
I use the demangler supplied by the debugger with flags as they seem to be used
in C++. That doesn't prepend the module name, though.

But looking at the vtable isn't too common and is probably rather special to
your current work. I also do it sometimes to figure the dynamic type if the
debugger fails to do it.

--

[Issue 18642] VisualD - Demangle link errors?

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18642

--- Comment #15 from Manu  ---
Oh cool.
I suspected it must be possible, exactly because you already do that for the
runtime libraries ;)

--

[Issue 18642] VisualD - Demangle link errors?

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18642

--- Comment #14 from Rainer Schuetze  ---
I think I managed to call pipelink.exe only if there are D sources found in the
project itself or any referenced project, similar to adding the runtime
libraries.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #17 from Manu  ---
Or if you're looking at a symbol in the watch window let's say, and you step
from D <-> C, and the symbol appears to suddenly change name in the crossing :P

I'm doing a lot of watching vtables as I step back and fourth.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #16 from Manu  ---
Sure, except that it needs to demangle EXACTLY like the MSVC tools, so you
don't see 2 errors from C++ and from D next to eachother and get confused as if
they're different symbols, and then spend minutes figuring out that they're
actually the same symbol, just piped through 2 different demanglers! ;)

--

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

[rikki cattermole via Digitalmars-d-announce]

On 25/05/2018 8:10 AM, Walter Bright wrote:
Maybe. I was thinking about using DasBetterC for the DMC runtime library 
instead of C :-)


That has been a desire for a bunch of us for a while now.

Just because we /might/ be able to get it to 64bit.

Re: Why Is D So Slow?

[rikki cattermole via Digitalmars-d]

On 25/05/2018 1:11 PM, Kaleb McKinney wrote:

On Friday, 25 May 2018 at 00:40:55 UTC, bachmeier wrote:

On Friday, 25 May 2018 at 00:35:43 UTC, Kaleb McKinney wrote:
I began learning D to get a performance upgrade from Python for 
performance reliant applications, and I was disappointed to find that 
a basic "Hello, World!" program takes almost 8 seconds to run, where 
in Python, it only took about a tenth of a second. Why is it so slow?


If you're on Windows, it's probably an antivirus issue.


What would the antivirus be doing to slow it down?


Scanning it, monitoring it.

Like any good antivirus should be doing.

Add an exclusion path for your projects directory (and toolchains too), 
it'll save you a lot of trouble down the road.

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #15 from Rainer Schuetze  ---
demangling C++ is easy, helper functions everywhere... ;-)

--