[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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #7 from Mike Franklin  ---
There is something screwy about it.  It's not the compiler that is reporting
the virus, it's the installer.  What utility are we using the generate the
installer executable?

--

[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 #6 from greenify  ---
> What information does checking the signature give? It shows it's signed, not 
> that it's virus-free. A signature shows that a binary comes from a certain 
> source, not that it carries no payloads.

Yes, but then again how do you know that anything does or doesn't contain a
virus?

FWIW you can build the compiler from the sources yourself quite quickly and
typically that is even more likely to be determined as a virus - even though in
this case you could have checked the entire code.
The signature at least insures that you got the binary built from the source
code you can see on GitHub (depending on whether or not you trust our release
master).

--

[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?

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

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

--- Comment #8 from Manu  ---
This is going to be so amazing if it works!

--

[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 #5 from greenify  ---
> I do not believe responsibility for reporting a false positive

Well, you are the one using the snake oil software (and possibly even paying
for it).

Don't forget that D is an open source project and driven by volunteers. Most D
developers use Linux, so they never run into this problems with Windows.
The only thing I can guarantee you is that it's a false positive because these
reports have been semi-regularily coming in from time to time over the recent
years. As mentioned for the AV vendors the D runtime looks still unfamiliar and
thus they often wrongly determine it to be a virus.

So tl;dr: if you don't report it to the AV vendor you use, who else is going
to?
And also AV vendors often take reports from their users much more seriously
than from open source projects (I tried to get in touch with done of them a few
years ago which horribly failed).

--

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 04:31:54 UTC, Neia Neutuladh 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.


The subject of your post is in the imperative. It's a command.



You are an imbecile, which I will attempt to prove: The subject 
describes the context of the post. It is not a command and no 
where says for everyone to drop what they are doing on work on 
it. That is what you want to read in to it. You are an evil 
person and want to spread your vitriol and hate by trying to read 
in the most negative things you can.





People who just have an idea that they want to discuss but 
aren't actively proposing as a change tend to communicate that 
explicitly. They say something like "what do you think about 
this idea?" or "would anyone find this useful?" or "soliciting 
feedback".




It doesn't matter. People that want to force other people to do 
things usually use guns. If we restrict our selves to forum posts 
someone will say something like:


"YOU BETTER IMPLEMENT THIS OR ELSE!"

or

"You guys have to implement this now!"

The fact is, you chose to be a douchebag because you are a 
douchebag. No where in my post did I have any animosity. Why? 
Because I didn't put in any. I had no animosity... just because 
you can misinterpret it and find it means that is something you 
projected on to it.


Even if I wrote "GO FUCK YOURSELF!", If I put no animosity in it 
then there is none and it means nothing what I wrote why? Because 
that could be also said in a joking way as we know some people 
say it that way. The fact is, I said nothing even close to being 
negative and the fact is you jumped to the conclusion that it was.


In fact, what you did was get pissed because I rejected your 
comment as being useful and then that made you negative so you 
decided to be a douchebag. That is your problem, not mine.  You 
seem to have a need for everyone to accept everything you say as 
the absolute truth. God complex?





At any rate, if you're just looking for whether anyone else 
thinks it would be useful, the answer seems to be no.


Um, another condescending attack? First, How do you know what 
others thing? Second, someone found it useful enough to create a 
simple piece of that emulates the behavior. If they thought it 
was absolutely useless as you are trying to imply they would 
never bothered. Again, it is you projecting.


You have a problem, you like to be a douchebag.

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.


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


What are you saying? You have rubbed dicks with them? There are a 
lot of douchebag moderators, in fact, most. Similar to cops where 
they get a little authority and they think they are a god. So, I 
fail to see exactly what you are saying here.


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?


You know what sets terrible expectations? When someone decides to 
read a post, reply trying to be helpful, when they are told their 
help wasn't on track they get pissed off then write posts that 
are condescending in attitude that is totally irrelevant to the 
original discussion and pretends to take the high ground.


If you notice I didn't attack anyone but you and that occurred 
after you attacked me. You, with your inflated ego expected me to 
roll over.


1. This is my thread, I shouldn't have to defend myself against 
any douchbag wants to but in and cause trouble.


2.




I hope that policy changes.

This is not an impossibly huge request, but it isn't trivial 
by any means. There are two socially acceptable ways to get 
people to implement something you want: convince them it's 
worthwhile, or pay them.


Um, no, it is trivial.


The relevant code is here:
https://github.com/dlang/dmd/blob/aa8fc584b92e736290f359596ec9e0aae857ae2c/src/dmd/statementsem.d#L1069

If, looking at it, you still think it's trivial, then you must 
be considerably better at this than me. And have a much firmer 
idea in your head of how this feature would work than you've 
told us.


1. The code isn't terrible, but I have never messed with the D 
source so it is not a test of my skills. It is a test of someone 
that actually deals in the idiom that is used along with the 
style and methods so that they can create proper features rather 
than for me to hack it together. The only people that can answer 
if this feature would be difficult to implement are 

[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?

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

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

--- Comment #7 from Rainer Schuetze  ---
Yes, you can also do this in C++. It's necessary to click the "Try Again" icon,
though, to not reevaluate it in the watch window with every step. I think this
can be done, too.

For properties execution should be automatic, but I don't think the debug info
contains info about strong purity. We might have to extract that info from the
mangling :-/

--

Re: extend foreach to work on non-arrays

[Neia Neutuladh via Digitalmars-d]

On Friday, 25 May 2018 at 03:24:32 UTC, IntegratedDimensions 
wrote:

Show me where I asked you to do any work for me.


The subject of your post is in the imperative. It's a command.

People who just have an idea that they want to discuss but aren't 
actively proposing as a change tend to communicate that 
explicitly. They say something like "what do you think about this 
idea?" or "would anyone find this useful?" or "soliciting 
feedback".


At any rate, if you're just looking for whether anyone else 
thinks it would be useful, the answer seems to be no.


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.


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.

This is not an impossibly huge request, but it isn't trivial 
by any means. There are two socially acceptable ways to get 
people to implement something you want: convince them it's 
worthwhile, or pay them.


Um, no, it is trivial.


The relevant code is here:
https://github.com/dlang/dmd/blob/aa8fc584b92e736290f359596ec9e0aae857ae2c/src/dmd/statementsem.d#L1069

If, looking at it, you still think it's trivial, then you must be 
considerably better at this than me. And have a much firmer idea 
in your head of how this feature would work than you've told us.

Re: extend foreach to work on non-arrays

[Jordan Wilson 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:
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.

Re: extend foreach to work on non-arrays

[Mike Parker via Digitalmars-d]

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!

[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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #3 from Mike Franklin  ---
I'm still trying to grok this, but from what I gather it sounds like
`genTypeInfo`
(https://github.com/dlang/dmd/blob/aa8fc584b92e736290f359596ec9e0aae857ae2c/src/dmd/typinf.d#L35)
is not being run for one of the types (the template instantiation in the
imported module?).

To fix, you may just need to enable logging in the compiler and find the
appropriate place to call `genTypeInfo`.  grep for `genTypeInfo` to find usage
examples in the source code.  There are quite a few.

--

[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?

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

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

--- Comment #6 from Manu  ---
It can call them... even if they mutate global state?

--

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

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.

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Friday, 25 May 2018 at 03:09:26 UTC, Neia Neutuladh wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions 
wrote:
If you can't find validity in the suggestion based on it's own 
inherent usefulness than the only way I can convince you is to 
provide examples that you actually find useful... that makes 
it difficult on my part and is not fair to me.


You are asking us all to do work for you. You're asking 
everyone to learn about this new language element. (And yes, we 
would have to learn, since it means the compiler is less able 
to find errors in our code, because more code is valid.) You're 
asking Walter Bright or another compiler developer to implement 
this feature for you, and write the tests, and write the 
documentation, and support this new code for years.


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.


This is not an impossibly huge request, but it isn't trivial by 
any means. There are two socially acceptable ways to get people 
to implement something you want: convince them it's worthwhile, 
or pay them.


Um, no, it is trivial. You just want to be an ass. It was already 
proved trivial by aliak. You just have some chip on your shoulder 
and are trying to make a general point when this is a specific 
problem.


Compare: there's no socket.io client or server library for D. 
You should implement one. Does my saying so make you inclined 
in any way to write a socket.io library?


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.

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

[IntegratedDimensions via Digitalmars-d-learn]

On Friday, 25 May 2018 at 01:42:48 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 01:17:45 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 01:02:00 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions 
wrote:

On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, 
IntegratedDimensions wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, 
treats t as T

   ...
}


The issue is that I programmed the class C with a variable 
that directly was based off TT, I later subderived T from 
TT and exposed it in I. (TT was refactored in to T and not 
T)




As as a side note:
I can hardly follow this, as you don't show, where you use 
the interface I. However, especially if TT was refactored 
in such a way, that is a set difference of T and not T, why 
you choose to derive from T instead of to contain T?




It really should be obvious that A was meant to derive from 
I. This is just standard oop.  Simply leaving off : I should 
not be a deal breaker because it would not change the whole 
problem from black to white or vice versa.


T is a member to be included. You can only derive from one 
class. C can't derive from both A and T and even if it did, 
it would mean something else.





https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



This is not a composition pattern.

This is a parallel inherentence pattern.

TT : T = T
||   |
vv   v
C  : A : I

TT is used with C and T with I.

When C changes to C', TT : T changes to TT' : T

All functions that use TT in C are forced to use it as if it 
were of type T rather than TT which requires a bunch of 
casts.


This is generally a violation of type logic. There is 
nothing in that prevents t from being something like TTT 
which has no direct relation to TT.


But the programming logic of the code enforces t to be of 
type TT in C *always*. So I don't know why I would have to 
use casting all the time. It would be nice if there where a 
simple logical way to enforce a design pattern in the type 
system knowing that it is enforced at runtime. This makes 
cleaner code, nothing else.






But all the code in C assumes t is of type TT but now due 
to the interface it looks like a T, even though internally 
it is actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my 
uses of t in C to type TT.


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).


So, it would be nice if somehow I could inform the type 
system that in C, t is always of type TT and so treat it 
as such rather than forcing me to explicitly cast for 
every use. Again, I could rename things to avoid the same 
name usage but in this case it is not necessary because of 
the design.


Is there any semantics that can get me around having to 
rename?


Maybe, you are looking for Curiously Recurring Template 
Pattern?


´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´


No, I am trying to keep parallel derived types consistently 
connected. If A is derived from B and C from D and B uses D 
then A uses C. Consistency cannot be guaranteed by the type 
system at compile time because A is typed to use C, I want 
to restrict it further to D.


You must put a template parameter in the interface and 
specialize the class that implements the interface.


```
module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}

module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```

but obviously this won't work if you want to derive C1 or 
C2...



or if there 100 fields.

This isn't a proper solution.

The whole issue is not outside of C but inside

Hypothetically

class C : A
{
   @property TT : T t() { return _t; }

   // t can be used directly as TT rather than 

Re: extend foreach to work on non-arrays

[Neia Neutuladh via Digitalmars-d]

On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions 
wrote:
If you can't find validity in the suggestion based on it's own 
inherent usefulness than the only way I can convince you is to 
provide examples that you actually find useful... that makes it 
difficult on my part and is not fair to me.


You are asking us all to do work for you. You're asking everyone 
to learn about this new language element. (And yes, we would have 
to learn, since it means the compiler is less able to find errors 
in our code, because more code is valid.) You're asking Walter 
Bright or another compiler developer to implement this feature 
for you, and write the tests, and write the documentation, and 
support this new code for years.


This is not an impossibly huge request, but it isn't trivial by 
any means. There are two socially acceptable ways to get people 
to implement something you want: convince them it's worthwhile, 
or pay them.


Compare: there's no socket.io client or server library for D. You 
should implement one. Does my saying so make you inclined in any 
way to write a socket.io library?

[Issue 18846] VisualD - show vtable in debugger

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

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

--- Comment #14 from Manu  ---
I'm noticing C++ symbols in the vtable don't demangle (ie, DMD).
Is there a way to call the C++ demangler that VS uses (to make sure the
demangle is identical)?

--

Re: extend foreach to work on non-arrays

[Jordan Wilson via Digitalmars-d]

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

[Issue 18846] VisualD - show vtable in debugger

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

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

--- Comment #13 from Manu  ---
Wow! Works on all my tests!

Thanks again!
I wonder if this feature should be turned on by default now :P

--

An analysis of dimensional analysis

[Andrei Alexandrescu via Digitalmars-d]

...in various languages, including D: 
https://www.reddit.com/r/programming/comments/8lwfis/dimensional_analysis_in_programming_languages/

[Issue 18642] VisualD - Demangle link errors?

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

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

--- Comment #12 from Manu  ---
I also had that thought... but I tried to push it aside and pretend I never
thought of it :P

--

[Issue 18642] VisualD - Demangle link errors?

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

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

Manu  changed:

   What|Removed |Added

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

--- Comment #13 from Manu  ---
Let's call this done huh?

--

Re: Support alias this in module scope?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/24/2018 03:07 AM, Jonathan M Davis wrote:


It's true. There's at least one post where he posted as WalterBright (note
the complete lack of spaces) and tried to make it look like Walter had
decided that having private be restricted to the module rather than the
class was a mistake. And if the lack of space in the name and the content
weren't enough to figure out that it wasn't Walter, the headers made it
clear that the post had come from the web forum, and AFAIK, Walter always
posts using NNTP. This fellow has impersonated at least half a dozen people
in the last couple of days.


The fake posts are also pretty easy to spot by their writing...*ahem* 
"style". The people being impersonated don't normally write in a way 
that sounds like barely-coherent trolling.

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

[Basile B. via Digitalmars-d-learn]

On Friday, 25 May 2018 at 01:17:45 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 01:02:00 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions 
wrote:

On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, 
IntegratedDimensions wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, 
treats t as T

   ...
}


The issue is that I programmed the class C with a variable 
that directly was based off TT, I later subderived T from 
TT and exposed it in I. (TT was refactored in to T and not 
T)




As as a side note:
I can hardly follow this, as you don't show, where you use 
the interface I. However, especially if TT was refactored in 
such a way, that is a set difference of T and not T, why you 
choose to derive from T instead of to contain T?




It really should be obvious that A was meant to derive from 
I. This is just standard oop.  Simply leaving off : I should 
not be a deal breaker because it would not change the whole 
problem from black to white or vice versa.


T is a member to be included. You can only derive from one 
class. C can't derive from both A and T and even if it did, 
it would mean something else.





https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



This is not a composition pattern.

This is a parallel inherentence pattern.

TT : T = T
||   |
vv   v
C  : A : I

TT is used with C and T with I.

When C changes to C', TT : T changes to TT' : T

All functions that use TT in C are forced to use it as if it 
were of type T rather than TT which requires a bunch of casts.


This is generally a violation of type logic. There is nothing 
in that prevents t from being something like TTT which has no 
direct relation to TT.


But the programming logic of the code enforces t to be of 
type TT in C *always*. So I don't know why I would have to 
use casting all the time. It would be nice if there where a 
simple logical way to enforce a design pattern in the type 
system knowing that it is enforced at runtime. This makes 
cleaner code, nothing else.






But all the code in C assumes t is of type TT but now due 
to the interface it looks like a T, even though internally 
it is actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my 
uses of t in C to type TT.


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).


So, it would be nice if somehow I could inform the type 
system that in C, t is always of type TT and so treat it as 
such rather than forcing me to explicitly cast for every 
use. Again, I could rename things to avoid the same name 
usage but in this case it is not necessary because of the 
design.


Is there any semantics that can get me around having to 
rename?


Maybe, you are looking for Curiously Recurring Template 
Pattern?


´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´


No, I am trying to keep parallel derived types consistently 
connected. If A is derived from B and C from D and B uses D 
then A uses C. Consistency cannot be guaranteed by the type 
system at compile time because A is typed to use C, I want to 
restrict it further to D.


You must put a template parameter in the interface and 
specialize the class that implements the interface.


```
module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}

module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```

but obviously this won't work if you want to derive C1 or C2...



or if there 100 fields.

This isn't a proper solution.

The whole issue is not outside of C but inside

Hypothetically

class C : A
{
   @property TT : T t() { return _t; }

   // t can be used directly as TT rather than having to do 
(cast(TT)t) everywhere t is used.

}

would solve 

Re: Why Is D So Slow?

[Kaleb McKinney via Digitalmars-d]

On Friday, 25 May 2018 at 00:47:00 UTC, Jonathan M Davis wrote:
On Friday, May 25, 2018 00:35:43 Kaleb McKinney via 
Digitalmars-d 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?


The only time that I've heard of anything like that was when 
the person was on Windows, and their antivirus was scanning the 
program every time they started it.


https://forum.dlang.org/post/kihdnggkyicbacznc...@forum.dlang.org

- Jonathan M Davis


Thanks! Doing that cut my program's run time from 16 seconds to 1 
second!

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

[IntegratedDimensions via Digitalmars-d-learn]

On Friday, 25 May 2018 at 01:02:00 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions 
wrote:

On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, 
IntegratedDimensions wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, 
treats t as T

   ...
}


The issue is that I programmed the class C with a variable 
that directly was based off TT, I later subderived T from TT 
and exposed it in I. (TT was refactored in to T and not T)




As as a side note:
I can hardly follow this, as you don't show, where you use 
the interface I. However, especially if TT was refactored in 
such a way, that is a set difference of T and not T, why you 
choose to derive from T instead of to contain T?




It really should be obvious that A was meant to derive from I. 
This is just standard oop.  Simply leaving off : I should not 
be a deal breaker because it would not change the whole 
problem from black to white or vice versa.


T is a member to be included. You can only derive from one 
class. C can't derive from both A and T and even if it did, it 
would mean something else.





https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



This is not a composition pattern.

This is a parallel inherentence pattern.

TT : T = T
||   |
vv   v
C  : A : I

TT is used with C and T with I.

When C changes to C', TT : T changes to TT' : T

All functions that use TT in C are forced to use it as if it 
were of type T rather than TT which requires a bunch of casts.


This is generally a violation of type logic. There is nothing 
in that prevents t from being something like TTT which has no 
direct relation to TT.


But the programming logic of the code enforces t to be of type 
TT in C *always*. So I don't know why I would have to use 
casting all the time. It would be nice if there where a simple 
logical way to enforce a design pattern in the type system 
knowing that it is enforced at runtime. This makes cleaner 
code, nothing else.






But all the code in C assumes t is of type TT but now due to 
the interface it looks like a T, even though internally it 
is actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my uses 
of t in C to type TT.


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).


So, it would be nice if somehow I could inform the type 
system that in C, t is always of type TT and so treat it as 
such rather than forcing me to explicitly cast for every 
use. Again, I could rename things to avoid the same name 
usage but in this case it is not necessary because of the 
design.


Is there any semantics that can get me around having to 
rename?


Maybe, you are looking for Curiously Recurring Template 
Pattern?


´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´


No, I am trying to keep parallel derived types consistently 
connected. If A is derived from B and C from D and B uses D 
then A uses C. Consistency cannot be guaranteed by the type 
system at compile time because A is typed to use C, I want to 
restrict it further to D.


You must put a template parameter in the interface and 
specialize the class that implements the interface.


```
module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}

module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```

but obviously this won't work if you want to derive C1 or C2...



or if there 100 fields.

This isn't a proper solution.

The whole issue is not outside of C but inside

Hypothetically

class C : A
{
   @property TT : T t() { return _t; }

   // t can be used directly as TT rather than having to do 
(cast(TT)t) everywhere t is used.

}

would solve the problem and it would scale.

The way it would work is that inside 

Re: Why Is D So Slow?

[Kaleb McKinney via Digitalmars-d]

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?

[Issue 18905] [Reg 2.079] C++ classes can no longer be used with -betterC

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

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #2 from Mike Franklin  ---
My research tells me this never actually worked; it used to generate a linker
error (1), then it generated a compiler error (2), and now HEAD is back to
generated a linker error (3).


1) Linker error was introduced with this:
-
digger: Installing
phobos-9f82a92b46e4236a29fa7a2830bcb09b89f1bcc8-2719e623bb150701c1636102dce91965
digger: Copy:
/home/mike/work/temp-cache/v3/phobos-9f82a92b46e4236a29fa7a2830bcb09b89f1bcc8-2719e623bb150701c1636102dce91965/lib
-> /home/mike/work/build/lib
digger: Clearing temporary cache
digger: -- Running test command... ---
digger: - Test command exited with status 0 (GOOD). --
digger: Finding shortest path between f65fb48e26f32114834c3eed3b89037894d5fcf2
and 90a8a78ab27a27dcf2df757214f7bb13446ce191...
digger: 0 commits (about 0 tests) remaining.
digger: 90a8a78ab27a27dcf2df757214f7bb13446ce191 is the first bad commit
commit 90a8a78ab27a27dcf2df757214f7bb13446ce191
Author: The Dlang Bot 
Date:   Mon Jun 26 23:19:46 2017 +0200

dmd: Merge pull request #6918 from WalterBright/link-betterC

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

fix Issue 17521 - -betterC programs should not link in Phobos by default
merged-on-behalf-of: Martin Nowak 

diff --git a/dmd b/dmd
index 47c0f9397..5a03f923f 16
--- a/dmd
+++ b/dmd
@@ -1 +1 @@
-Subproject commit 47c0f9397144e6db1e56fcec1e6d512084f4f947
+Subproject commit 5a03f923fce98e9db6b3b563308b510c21ac5116
digger: Bisection completed successfully.


2) The compiler error was introduced with this:
---
https://github.com/dlang/dmd/pull/7799
...which was actually an improvement because prior to that PR, the compiler was
expecting to find TypeInfo at link-time but was unable to.  The compiler-time
error at least gave notice that something was wrong before it got to the
linker.

3) Linker error re-introduced with this:

digger: Installing
phobos-42e9d6ffb9ec07cf2972d7d5932baae6aa60532c-039ab00227f1ab904b29ebf50fd56dad
digger: Copy:
/home/mike/work/temp-cache/v3/phobos-42e9d6ffb9ec07cf2972d7d5932baae6aa60532c-039ab00227f1ab904b29ebf50fd56dad/lib
-> /home/mike/work/build/lib
digger: Clearing temporary cache
digger: -- Running test command... ---
digger: - Test command exited with status 0 (GOOD). --
digger: Finding shortest path between 1904038db47e8710352c840956f95e8b08cf584f
and 4a8b2c80efe6c3546b37d95fe7db7740a06bdfaf...
digger: 0 commits (about 0 tests) remaining.
digger: 4a8b2c80efe6c3546b37d95fe7db7740a06bdfaf is the first good commit
commit 4a8b2c80efe6c3546b37d95fe7db7740a06bdfaf
Author: The Dlang Bot 
Date:   Fri Apr 27 11:34:39 2018 +0200

dmd: Merge pull request #8204 from JinShil/minimal_runtime_with_classes

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

Add ability to use interfaces and classes without the runtime if they only
contain static members
merged-on-behalf-of: unknown

diff --git a/dmd b/dmd
index 7f94ffbab..40b18f0ab 16
--- a/dmd
+++ b/dmd
@@ -1 +1 @@
-Subproject commit 7f94ffbab7328cdd643e0be5fbbb2b8ef580845f
+Subproject commit 40b18f0abfefc9aab0ff99e2d699c0bff7a4cf67
digger: Bisection completed successfully.

But all that is beside the point, isn't it.  It should work with -betterC.  I'm
looking into it.

--

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

[Basile B. via Digitalmars-d-learn]

On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions 
wrote:

On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions 
wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, 
treats t as T

   ...
}


The issue is that I programmed the class C with a variable 
that directly was based off TT, I later subderived T from TT 
and exposed it in I. (TT was refactored in to T and not T)




As as a side note:
I can hardly follow this, as you don't show, where you use the 
interface I. However, especially if TT was refactored in such 
a way, that is a set difference of T and not T, why you choose 
to derive from T instead of to contain T?




It really should be obvious that A was meant to derive from I. 
This is just standard oop.  Simply leaving off : I should not 
be a deal breaker because it would not change the whole problem 
from black to white or vice versa.


T is a member to be included. You can only derive from one 
class. C can't derive from both A and T and even if it did, it 
would mean something else.





https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



This is not a composition pattern.

This is a parallel inherentence pattern.

TT : T = T
||   |
vv   v
C  : A : I

TT is used with C and T with I.

When C changes to C', TT : T changes to TT' : T

All functions that use TT in C are forced to use it as if it 
were of type T rather than TT which requires a bunch of casts.


This is generally a violation of type logic. There is nothing 
in that prevents t from being something like TTT which has no 
direct relation to TT.


But the programming logic of the code enforces t to be of type 
TT in C *always*. So I don't know why I would have to use 
casting all the time. It would be nice if there where a simple 
logical way to enforce a design pattern in the type system 
knowing that it is enforced at runtime. This makes cleaner 
code, nothing else.






But all the code in C assumes t is of type TT but now due to 
the interface it looks like a T, even though internally it is 
actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my uses 
of t in C to type TT.


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).


So, it would be nice if somehow I could inform the type 
system that in C, t is always of type TT and so treat it as 
such rather than forcing me to explicitly cast for every use. 
Again, I could rename things to avoid the same name usage but 
in this case it is not necessary because of the design.


Is there any semantics that can get me around having to 
rename?


Maybe, you are looking for Curiously Recurring Template 
Pattern?


´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´


No, I am trying to keep parallel derived types consistently 
connected. If A is derived from B and C from D and B uses D 
then A uses C. Consistency cannot be guaranteed by the type 
system at compile time because A is typed to use C, I want to 
restrict it further to D.


You must put a template parameter in the interface and specialize 
the class that implements the interface.


```
module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}

module runnable;

class T{}
class TT : T{}

interface I(N)
{
   @property N t();
}

abstract class A(N) : I!N
{
   N _t;
   @property N t() { return _t; }
}

class C1 : A!T{}
class C2 : A!TT{}

void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```

but obviously this won't work if you want to derive C1 or C2...

Re: Why Is D So Slow?

[Jonathan M Davis via Digitalmars-d]

On Friday, May 25, 2018 00:35:43 Kaleb McKinney via Digitalmars-d 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?

The only time that I've heard of anything like that was when the person was
on Windows, and their antivirus was scanning the program every time they
started it.

https://forum.dlang.org/post/kihdnggkyicbacznc...@forum.dlang.org

- Jonathan M Davis

Re: Why Is D So Slow?

[bachmeier via Digitalmars-d]

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.

Why Is D So Slow?

[Kaleb McKinney via Digitalmars-d]

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?

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

[IntegratedDimensions via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions 
wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, treats 
t as T

   ...
}


The issue is that I programmed the class C with a variable 
that directly was based off TT, I later subderived T from TT 
and exposed it in I. (TT was refactored in to T and not T)




As as a side note:
I can hardly follow this, as you don't show, where you use the 
interface I. However, especially if TT was refactored in such a 
way, that is a set difference of T and not T, why you choose to 
derive from T instead of to contain T?




It really should be obvious that A was meant to derive from I. 
This is just standard oop.  Simply leaving off : I should not be 
a deal breaker because it would not change the whole problem from 
black to white or vice versa.


T is a member to be included. You can only derive from one class. 
C can't derive from both A and T and even if it did, it would 
mean something else.





https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



This is not a composition pattern.

This is a parallel inherentence pattern.

TT : T = T
||   |
vv   v
C  : A : I

TT is used with C and T with I.

When C changes to C', TT : T changes to TT' : T

All functions that use TT in C are forced to use it as if it were 
of type T rather than TT which requires a bunch of casts.


This is generally a violation of type logic. There is nothing in 
that prevents t from being something like TTT which has no direct 
relation to TT.


But the programming logic of the code enforces t to be of type TT 
in C *always*. So I don't know why I would have to use casting 
all the time. It would be nice if there where a simple logical 
way to enforce a design pattern in the type system knowing that 
it is enforced at runtime. This makes cleaner code, nothing else.






But all the code in C assumes t is of type TT but now due to 
the interface it looks like a T, even though internally it is 
actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my uses 
of t in C to type TT.


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).


So, it would be nice if somehow I could inform the type system 
that in C, t is always of type TT and so treat it as such 
rather than forcing me to explicitly cast for every use. 
Again, I could rename things to avoid the same name usage but 
in this case it is not necessary because of the design.


Is there any semantics that can get me around having to rename?


Maybe, you are looking for Curiously Recurring Template Pattern?

´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´


No, I am trying to keep parallel derived types consistently 
connected. If A is derived from B and C from D and B uses D then 
A uses C. Consistency cannot be guaranteed by the type system at 
compile time because A is typed to use C, I want to restrict it 
further to D.

Re: Why char[] is not @nogc on this case

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, May 25, 2018 00:09:28 SrMordred via Digitalmars-d-learn wrote:
> On Friday, 25 May 2018 at 00:04:10 UTC, Adam D. Ruppe wrote:
> > On Thursday, 24 May 2018 at 23:55:24 UTC, SrMordred wrote:
> >> //Error: @nogc delegate onlineapp.main.__lambda1 cannot call
> >> non-@nogc function std.range.chain!(char[],
> >> char[]).chain.Result.front
> >>
> >> Why?
> >
> > phobos automatically decodes utf8 into dchars. This can throw a
> > new utf exception.
>
> Oh its the utf8 decode thing.
> I forgot about it.
> I thought that it only decodes when using strings and dchars.

It happens with any "narrow string" - i.e. any array of char or dchar. You
can test for it with std.traits.isNarrowString, whose current implementation
is:

enum bool isNarrowString(T) = isSomeString!T && !is(T : const dchar[]);

Basically, unless a range-based function goes out of its way to specialize
for narrow strings and avoids any decoding (and whether that makes any sense
depends on what the function does), it's going to treat any array of char or
wchar as a range of dchar and will throw a UTFException on invalid Unicode.

- Jonathan M Davis

Re: Why char[] is not @nogc on this case

[SrMordred via Digitalmars-d-learn]

Because arrays of char and wchar are treated as ranges of dchar.


That part that I didnt know, thanks! :)

Re: Why char[] is not @nogc on this case

[SrMordred via Digitalmars-d-learn]

On Friday, 25 May 2018 at 00:04:10 UTC, Adam D. Ruppe wrote:

On Thursday, 24 May 2018 at 23:55:24 UTC, SrMordred wrote:
//Error: @nogc delegate onlineapp.main.__lambda1 cannot call 
non-@nogc function std.range.chain!(char[], 
char[]).chain.Result.front


Why?


phobos automatically decodes utf8 into dchars. This can throw a 
new utf exception.


Oh its the utf8 decode thing.
I forgot about it.
I thought that it only decodes when using strings and dchars.

Thanks!

Re: Why char[] is not @nogc on this case

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 24, 2018 23:55:24 SrMordred via Digitalmars-d-learn wrote:
> int[] a;
> int[] b;
>
> ()@nogc {
> foreach(v ; chain( a,b ) ) printf("%d\n", v);
> }();
>
> //Ok, everything fine;
>
> char[] a;
> char[] b;
>
> ()@nogc {
> foreach(v ; chain( a,b ) ) printf("%c\n", v);
> }();
>
> //Error: @nogc delegate onlineapp.main.__lambda1 cannot call
> non-@nogc function std.range.chain!(char[],
> char[]).chain.Result.front
>
> Why?

Because arrays of char and wchar are treated as ranges of dchar.
std.primitives.range.front and popFront call std.utf.decode and stride
respectively so that front returns dchar. decode (and possibly stride - I'd
have to check) throw a UTFException on invalid Unicode, and that means that
they allocate with the GC. If you want to avoid the auto-decoding, you have
to use something like std.string.representation or std.utf.byCodeUnit to
wrap the array of chars before passing them to any range-based functions.

- Jonathan M Davis

Re: Why char[] is not @nogc on this case

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 23:55:24 UTC, SrMordred wrote:
//Error: @nogc delegate onlineapp.main.__lambda1 cannot call 
non-@nogc function std.range.chain!(char[], 
char[]).chain.Result.front


Why?


phobos automatically decodes utf8 into dchars. This can throw a 
new utf exception.

Why char[] is not @nogc on this case

[SrMordred via Digitalmars-d-learn]

int[] a;
int[] b;

()@nogc {
   foreach(v ; chain( a,b ) ) printf("%d\n", v);
}();

//Ok, everything fine;

char[] a;
char[] b;

()@nogc {
   foreach(v ; chain( a,b ) ) printf("%c\n", v);
}();

//Error: @nogc delegate onlineapp.main.__lambda1 cannot call 
non-@nogc function std.range.chain!(char[], 
char[]).chain.Result.front


Why?

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

[Alex via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions 
wrote:

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, treats 
t as T

   ...
}


The issue is that I programmed the class C with a variable that 
directly was based off TT, I later subderived T from TT and 
exposed it in I. (TT was refactored in to T and not T)




As as a side note:
I can hardly follow this, as you don't show, where you use the 
interface I. However, especially if TT was refactored in such a 
way, that is a set difference of T and not T, why you choose to 
derive from T instead of to contain T?


https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance

Well, can imagine useful cases though...



But all the code in C assumes t is of type TT but now due to 
the interface it looks like a T, even though internally it is 
actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my uses of 
t in C to type TT.


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).


So, it would be nice if somehow I could inform the type system 
that in C, t is always of type TT and so treat it as such 
rather than forcing me to explicitly cast for every use. Again, 
I could rename things to avoid the same name usage but in this 
case it is not necessary because of the design.


Is there any semantics that can get me around having to rename?


Maybe, you are looking for Curiously Recurring Template Pattern?

´´´
interface I(P)
{
@property P t();
}

abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}

class TT : T!TT
{

}

void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Thursday, 24 May 2018 at 23:08:39 UTC, aliak wrote:

On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
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.


You can already do this for any type you define:

class Foo
{
  auto iterate() { return only(this); }
  alias iterate this;
}

Can you give examples of code that is awkward today that would 
be simplified with your proposal? I don't expect people to 
give full cost-benefit analyses for every suggestion, but it'd 
be nice if you could at least mention some of the upsides.


And then you can generalize this for any type

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

foreach(i; 3.elseOnly) {
}

foreach(i; [1, 2, 3].elseOnly) {
}


Cheers
- Ali


cool, and this is optimal, right? non-arrays are not converted in 
to arrays, etc?

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Thursday, 24 May 2018 at 23:03:34 UTC, meppl wrote:
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.


on the otherhand some programmer might want to get informed buy 
an error-msg, if he accidentally used a non-iteratable variable 
for `foreach`-iteration. To avoid a silent bug


In this case it cannot be a bug. The foreach is simply 
ignored/reduced. It would be impossible for any bug to creep 
in(assuming no compiler bugs) in such cases.


foreach(a; x)
{
   x[]
}

would be some type of potential bug... but that bug would also 
exist without the loop. If x is not an array then the the foreach 
effectively is removed and a is just auto a = x;


Any code that uses x would fail just as much as using a and no 
more except.

Re: extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
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.


You can already do this for any type you define:

class Foo
{
  auto iterate() { return only(this); }
  alias iterate this;
}

Can you give examples of code that is awkward today that would 
be simplified with your proposal? I don't expect people to give 
full cost-benefit analyses for every suggestion, but it'd be 
nice if you could at least mention some of the upsides.


The upside is that it is a composite pattern and does not require 
any extra code to use preexisting functionality. There is no 
downside, which is an upside.




foreach(a; x)
{
   // uses a

}

gets directly converted to

{
   // uses x
}

by a simple renaming/aliasing of a to x and so it cannot require 
any more issues than what already exists.


Your method requires one to have access to all type definitions, 
which is not the case.




I do not know why I would be required to specify a use case to 
justify the usability. Most things are not usable until they are 
invented. Most people did not know how useful the hammer would be 
until someone created it. You have to build it for them to come. 
I have my use cases which is why I came up with 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".


If you can't find validity in the suggestion based on it's own 
inherent usefulness than the only way I can convince you is to 
provide examples that you actually find useful... that makes it 
difficult on my part and is not fair to me.

Re: Assigning a method name to a variable and then calling it with an object

[aliak via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 23:08:29 UTC, Basile B. wrote:

On Thursday, 24 May 2018 at 23:03:21 UTC, aliak wrote:

Hi,

I was essentially trying to do this:

struct S {
  void f() {}
}

auto f = S.f; // f becomes void function(S) ??
S s;
f(s);

Is something like that possible?

Cheers,
- Ali


Sure:

```
import std.stdio;

void main(string[] args)
{

struct S {
  void f() {"yeah possible".writeln;}
}

void delegate() f;
f.funcptr = 
S s;
f.ptr = 
s.f();
}
```

It's just that you have to learn the ABI of D delegates.
There are two members: .funcptr (function) and .ptr (context, 
i.e the "this").


ahh, gracias!

Re: extend foreach to work on non-arrays

[aliak via Digitalmars-d]

On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
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.


You can already do this for any type you define:

class Foo
{
  auto iterate() { return only(this); }
  alias iterate this;
}

Can you give examples of code that is awkward today that would 
be simplified with your proposal? I don't expect people to give 
full cost-benefit analyses for every suggestion, but it'd be 
nice if you could at least mention some of the upsides.


And then you can generalize this for any type

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

foreach(i; 3.elseOnly) {
}

foreach(i; [1, 2, 3].elseOnly) {
}


Cheers
- Ali

Re: Assigning a method name to a variable and then calling it with an object

[Basile B. via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 23:03:21 UTC, aliak wrote:

Hi,

I was essentially trying to do this:

struct S {
  void f() {}
}

auto f = S.f; // f becomes void function(S) ??
S s;
f(s);

Is something like that possible?

Cheers,
- Ali


Sure:

```
import std.stdio;

void main(string[] args)
{

struct S {
  void f() {"yeah possible".writeln;}
}

void delegate() f;
f.funcptr = 
S s;
f.ptr = 
s.f();
}
```

It's just that you have to learn the ABI of D delegates.
There are two members: .funcptr (function) and .ptr (context, i.e 
the "this").

Re: extend foreach to work on non-arrays

[Neia Neutuladh 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.


You can already do this for any type you define:

class Foo
{
  auto iterate() { return only(this); }
  alias iterate this;
}

Can you give examples of code that is awkward today that would be 
simplified with your proposal? I don't expect people to give full 
cost-benefit analyses for every suggestion, but it'd be nice if 
you could at least mention some of the upsides.

Re: extend foreach to work on non-arrays

[meppl 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.


on the otherhand some programmer might want to get informed buy 
an error-msg, if he accidentally used a non-iteratable variable 
for `foreach`-iteration. To avoid a silent bug

Assigning a method name to a variable and then calling it with an object

[aliak via Digitalmars-d-learn]

Hi,

I was essentially trying to do this:

struct S {
  void f() {}
}

auto f = S.f; // f becomes void function(S) ??
S s;
f(s);

Is something like that possible?

Cheers,
- Ali

Stateful modules and extern(C)

[Arredondo via Digitalmars-d-learn]

I want to call some of my D code from Python. I'm annotating the 
pertinent functions with extern(C) export, as in


module foo;
extern(C) export int initialize() {
return 42;
}

I compile with:

dmd -fPIC -shared ./foo.d

From the Python end, I can load the library using ctypes and the 
call works fine. The problem is, as soon as I have some state in 
my D module, as in:


module foo;

int call_count;

extern(C) export int initialize() {
++call_count;
return 42;
}

the call to initialize from python gives:

AttributeError: ./foo.so: undefined symbol: initialize

Can you share some tips/examples of non-trivial/stateful D 
modules that are successfully export(C)ed and maybe consumed with 
ctypes? Are there any specific attributes that I need to annotate 
my module globals with?


Thank you!
Arredondo.

extend foreach to work on non-arrays

[IntegratedDimensions via Digitalmars-d]

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.

[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 #4 from David M  ---
What information does checking the signature give? It shows it's signed, not
that it's virus-free. A signature shows that a binary comes from a certain
source, not that it carries no payloads.

> Please report it to your Antivirus vendors.

VirusTotal.com tests using 60-70 vendors, of which 18% (let's round to one
fifth of all AVs) have trouble with this binary. I do not believe
responsibility for reporting a false positive, at such a scale, lies with
someone with no knowledge of your runtime, your build machines, your internal
pre-signature AV checks, your runtime or the areas of your runtime that cause
AVs to flag the binary.

--

Re: Tiny D suitable for embedded JIT

[Jonathan Marler via Digitalmars-d]

On Thursday, 24 May 2018 at 20:22:15 UTC, Dibyendu Majumdar wrote:
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
The ultimate goal is to have JIT library that is small, has 
fast compilation, and generates reasonable code (i.e. some 
form of global register allocation). The options I am looking 
at are a) start from scratch, b) hack LLVM, or c) hack DMD.




I have been looking at DMD code (mainly the backend stuff) for 
this ... I think it will be too difficult for me to try to 
modify it :-(


Regards
Dibyendu


Sad to hear. Was interested to see if this was feasible.  I don't 
have much experience with the backend but if you're still up for 
the task, take a look at `dmd/glue.d`.  I don't know how much of 
the glue layer this includes but it would be a good start.  DMD 
does have a common "glue layer" shared by DMD, LDC and GDC, so 
you'd basically need to find the API to build this glue layer and 
that's what you would use.


https://github.com/dlang/dmd/blob/master/src/dmd/glue.d

Re: UFCS syntax I never saw before.

[aliak via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 22:03:38 UTC, aliak wrote:
It feels like the only difference between a no-arg function 
that is @property and one that is not is that the former could 
be invoked with optional parentheses and the latter should be 
illegal with parentheses.


Edit: err... other way around!

Re: UFCS syntax I never saw before.

[aliak via Digitalmars-d-learn]

On Tuesday, 22 May 2018 at 14:33:20 UTC, Jonathan M Davis wrote:
A free function with a single argument works just fine as a 
setter property. e.g. you could do something like


void env(Tuple!(string, string)[] str)
{
// set environment variables
}

env = [tuple("foo", "bar")];

is perfectly legal. I question that there are many cases where 
such a function would be considered good design, but basically 
any case where it would make sense to have a function act like 
a global variable is currently allowed but would be disallowed 
if you couldn't have a setter property with only one argument.


- Jonathan M Davis


That can be attributed with @property if the developer intends 
for it to be used in that way, else should be illegal.

[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 #3 from greenify  ---
It's a false positive. You can check the signature of the binary.

Please report it to your Antivirus vendors. They traditionally have troubles
with the DigitalMars runtime.

--

Re: UFCS syntax I never saw before.

[aliak via Digitalmars-d-learn]

On Tuesday, 22 May 2018 at 13:59:16 UTC, Steven Schveighoffer 
wrote:
The derailed plan was to leave alone the ability to call no-arg 
functions without parentheses, but to REQUIRE @property to call 
an argument-taking function with the assignment style.


See the DIP here: https://wiki.dlang.org/DIP23

Written by Walter and Andrei. I can't remember why it didn't 
happen.


-Steve


Aha. Thanks for the link!

It feels like the only difference between a no-arg function that 
is @property and one that is not is that the former could be 
invoked with optional parentheses and the latter should be 
illegal with parentheses.


Whereas an argument taking function marked as @property should 
probably allow read or write operations depending on whether or 
not it's invoked with an implicit first argument or not:


@property int f(int) { ... }
1.f; // read op
f = 1; // write op

And to make parentheses illegal as well of course.

[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

David M  changed:

   What|Removed |Added

 CC||vintaged...@gmail.com

--- Comment #2 from David M  ---
dmd-2.080.0.exe, downloaded yesterday, gives 12 reports on VirusTotal including
McAfee, TrendMicro, and Microsoft.

This is 12/64 scanners, ie 18%.  A false positive sounds less likely.

https://www.virustotal.com/#/file/007560cc35e78ba74d6fa9732e27032a1fd2f2d6cbadffd1c3968d5dd100/detection

Windows Defender on Win10 identifies it as a trojan and will not run, too.

--

[Issue 18905] [Reg 2.079] C++ classes can no longer be used with -betterC

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

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

--- Comment #1 from Walter Bright  ---
When compiled with -betterC

--

[Issue 18905] New: [Reg 2.079] C++ classes can no longer be used with -betterC

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

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

  Issue ID: 18905
   Summary: [Reg 2.079] C++ classes can no longer be used with
-betterC
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Consider:

  extern (C++) class C { } // Error: TypeInfo cannot be used with -betterC

This worked with 2.074. TypeInfo with 2.074 was not generated for this class,
it just generated the vtbl[] which is fine.

Looks like 

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

is the culprit.

--

[Issue 18905] [Reg 2.079] C++ classes can no longer be used with -betterC

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||betterC, C++

--

[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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Schuetze  ---
Please note that -1073741819 is 0xc005, i.e. this is an access violation.
Does the same code compile with a dmc compiled nightly build?

--

Re: Tiny D suitable for embedded JIT

[Dibyendu Majumdar via Digitalmars-d]

On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
The ultimate goal is to have JIT library that is small, has 
fast compilation, and generates reasonable code (i.e. some form 
of global register allocation). The options I am looking at are 
a) start from scratch, b) hack LLVM, or c) hack DMD.




I have been looking at DMD code (mainly the backend stuff) for 
this ... I think it will be too difficult for me to try to modify 
it :-(


Regards
Dibyendu

Any way to override base type with dervived in derived type

[IntegratedDimensions via Digitalmars-d-learn]

class T;
class TT : T;

interface I
{
   @property T t();
}

abstract class A
{
   T _t;
   @property T t() { return _t; }

}

class C : A
{

   // Stuff below uses t as TT but compiler, of course, treats t 
as T

   ...
}


The issue is that I programmed the class C with a variable that 
directly was based off TT, I later subderived T from TT and 
exposed it in I. (TT was refactored in to T and not T)



But all the code in C assumes t is of type TT but now due to the 
interface it looks like a T, even though internally it is 
actually a TT.


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
   ...
}

or whatever.

This is simply so I don't have to rename or cast all my uses of t 
in C to type TT.


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).


So, it would be nice if somehow I could inform the type system 
that in C, t is always of type TT and so treat it as such rather 
than forcing me to explicitly cast for every use. Again, I could 
rename things to avoid the same name usage but in this case it is 
not necessary because of the design.


Is there any semantics that can get me around having to rename?

Re: try & catch / repeating code - DRY

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, May 24, 2018 19:39:07 Jacob Carlborg via Digitalmars-d-learn 
wrote:
> On 2018-05-24 08:05, Robert M. Münch wrote:
> > Hi, great! Thanks for the examples... BTW: Is there a place where such
> > generic and fundamental examples are collected?
>
> Not as far as I know.
>
> >> void handleException1(alias dg)()
> >> {
> >>  try dg();
> >>  catch (Exception e) { /* handle exception */ }
> >> }
> >>
> >> void handleException2(lazy void dg)
> >> {
> >>  try dg();
> >>  catch (Exception e) { /* handle exception */ }
> >> }
> >>
> >> void handleException3(scope void delegate () dg)
> >> {
> >>  try dg();
> >>  catch (Exception e) { /* handle exception */ }
> >> }
> >>
> >> void main()
> >> {
> >>  handleException1!({
> >>  writeln("asd");
> >>  });
> >>
> >>  handleException1!(() => writeln("asd"));
> >>
> >>  handleException2(writeln("asd"));
> >>
> >>  handleException3({
> >>  writeln("asd");
> >>  });
> >> }
> >
> > What is exactly the difference between handleException1 and 3?
>
> With handleException1 the delegate needs to be passed as a template
> argument, in the other case as a regular argument. I thought that the
> lambda syntax, () => writeln("asd"), did not work as a regular argument,
> but I checked now and it does.
>
> Passing it as a template argument might allow the compiler to inline it.
> All range functions in Phobos are using template argument approach.

With a template alias, it will accept pretty much any symbol (which would
then normally be restricted by a template constraint so that it's a symbol
which is usable in the target context), whereas an explicit delegate will
only accept anything that implicitly converts to a delegate with that
signature. What matches, I don't know, since I pretty much enver declare
explicit delegates, though I don't find it surprising that a lambda works,
since that's basically what a lambda is. But I expect that if you did
something like pass a functor, it would work with the alias but wouldn't
work with the delegate parameter.

- Jonathan M Davis

Re: Tiny D suitable for embedded JIT

[Dibyendu Majumdar via Digitalmars-d]

On Thursday, 24 May 2018 at 02:39:18 UTC, Joakim wrote:


I don't know if this does exactly what you want, but have you 
seen it?


https://forum.dlang.org/thread/bskpxhrqyfkvaqzoo...@forum.dlang.org


Hi - thanks I hadn't seen it. It is based on LLVM - I already use 
LLVM and it isn't a small / or fast compiling JIT engine.


Regards

Re: Support alias this in module scope?

[Rubn via Digitalmars-d]

On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote:
Okay, I'm still really angry about the stupid stupid decision 
to make C++ namespaces into scopes rather than just a detail 
used for mangling, with absolutely no consultation of the 
community, in particular the target audience, who are 
unanimously annoyed as far as I can tell...


I'm unsatisfied by the work-arounds to make the situation 
not-suck, but I think I have an idea that would pacify me...


If we can use `alias this` to mirror an entire C++ namespace 
into the location we want (ie, the scope immediately outside 
the C++ namespace!!), then one sanitary line would make the 
problem quite more tolerable:


extern(C++, FuckOff)
{
  void bah();
  void humbug();
}
alias this FuckOff;  // <-- symbols are now aliased where they 
should

have been all along



(count the seconds until the reply that says to use reflection 
to scan the scope, and use a mixin to... blah blah)


Would there be any use for this other than working around this 
problem with extern(C++) ?


If not then perhaps changing the behavior to be what is desired 
would be better. If we change extern(C++, Namespace) to work only 
for mangling and not as a struct, then existing code would only 
need to create a new module with "Namespace" and statically 
import it to work with existing code. I'd rather the actual 
problem be fixed than having some work around for it. We don't 
even have multiple "alias this" in structs. If a new feature were 
to be added I'd rather it'd be that, which was "approved" but has 
yet to be included.

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

[Basile B. via Digitalmars-d-announce]

On Thursday, 24 May 2018 at 18:54:41 UTC, Walter Bright wrote:

On 5/23/2018 7:31 PM, Walter Bright wrote:

Back on the front page with an apparent followup:

Consider using Digital Mars C compiler (virtualbox.org)
33 points by yuhong 3 hours ago | flag | hide | past | web | 
favorite | 14 comments


https://news.ycombinator.com/news


Direct link:

https://news.ycombinator.com/item?id=17139305


At last the Digital Mars stand C library sources.
Maybe now things can be be fixed more easily, although win32 is 
dead now.


Now snn has to be compiled for mscoff32 (so not possible with 
DMC, right ?) and generate DWARF2 debug info and finally GDB 
could be used under win32, giving a working, out of the box, 
MS-free, package, just like current one but with more coherent 
object type.


Ahhh i was forgetting, the linker...

Possible before 2020 ?

Re: Ideas for students' summer projects

[Steven Schveighoffer via Digitalmars-d]

On 5/24/18 2:21 PM, Mike Franklin wrote:

On Thursday, 24 May 2018 at 18:08:35 UTC, Patrick Schluter wrote:

As a contrived illustration, take a look at the code in 
https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  
Those same features are also in Phobos.


OT, numberDigits enters an infinite loop if radix == 1.


and crashes for radix == 0


All the more reason to implement my proposal.


Why? they are just bugs.

https://github.com/dlang/druntime/pull/2192

-Steve

[Issue 18904] core.internal.string has issues with radix

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Steven Schveighoffer  ---
PR: https://github.com/dlang/druntime/pull/2192

--

[Issue 18904] New: core.internal.string has issues with radix

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

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

  Issue ID: 18904
   Summary: core.internal.string has issues with radix
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

radices of 0 or 1 will cause crashes/infinite loops. radices greater than 36
will not be printable.

For the numDigits function, we can make sure it makes sense.

For the other functions, I'll just return a blank string, making the error
detectable elsewhere.

--

[Issue 11331] Inefficient initialization of struct with members = void

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

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

johanenge...@weka.io changed:

   What|Removed |Added

 CC||johanenge...@weka.io

--- Comment #9 from johanenge...@weka.io ---
Assignment with T.init is used to remove dangling pointers after destruction:
https://github.com/dlang/druntime/blob/54ab96e9977e0c6baa7ed9740810058fd4aec6ef/src/object.d#L3082-L3098
So if spec is changed/clarified on this issue, we probably need to change/fix
that code too. (if there isn't already, we need help from traits to figure out
which members are =void, such that we can zero them explicitly)

--

[Issue 18899] destroy is inefficient for small structs

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

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

--- Comment #9 from Manu  ---
True.
Anyway, I'm just playing devils advocate. I agree, it should do an element copy
for small structs.

--

[Issue 18899] destroy is inefficient for small structs

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

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

--- Comment #8 from Steven Schveighoffer  ---
(In reply to Steven Schveighoffer from comment #7)
> See the generated AST

...generated *assembly*

--

[Issue 18899] destroy is inefficient for small structs

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

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

--- Comment #7 from Steven Schveighoffer  ---
I'm not sure that it is.

But we aren't calling memcpy anyway, we are calling _d_arraycopy, not inlined.
See the generated AST from Mike's example.

--

Re: Conditionally set nothrow: for a block of code.

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/24/18 2:51 PM, Mike Franklin wrote:

Given that the PR above is for object.d, I can't turn the entire 
object.d source file into a string and conditionally mix that in.  Does 
anyone have a solution to this?


My recommendation would have been the last one, but if that doesn't 
work, I don't think anything will that is... palatable.


The only other avenue you *could* explore is importing a file as a 
string and mixing the whole thing in (prepending "nothrow:" at the top).


Other than that, I think it's on to DIP territory.

-Steve

[Issue 18236] Invalid line reported on error casting enum

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

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/69a82a612253a47f134cac1e0dab65831fd3f715
Fix Issue 18236 - Invalid line reported on error casting enum

https://github.com/dlang/dmd/commit/aa8fc584b92e736290f359596ec9e0aae857ae2c
Merge pull request #8287 from RazvanN7/Issue_18236

[Trivial]Fix Issue 18236 - Invalid line reported on error casting enum
merged-on-behalf-of: Jacob Carlborg 

--

[Issue 18236] Invalid line reported on error casting enum

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

Conditionally set nothrow: for a block of code.

[Mike Franklin via Digitalmars-d-learn]

I'm trying to find a way to declare a block of code `nothrow:` 
when compiling with -betterC, but not `nothrow` when not 
compiling with -betterC.


The solution is needed for this PR:  
https://github.com/dlang/druntime/pull/2184/files#r188627707


Attempt #1
--
void test() { }

version(D_BetterC)
{
nothrow:
}

extern(C) void main()
{
test();   // This should throw an error in -betterC because 
`main` is

  // `nothrow` but `test` isn't. It doesn't work
}

Attempt #2
--
version(D_BetterC)
{
enum isNoThrow = true;
}
else
{
enum isNoThrow = false;
}

void test() { }

static if (isNoThrow)
{
nothrow:
}

extern(C) void main()
{
test();   // This should throw an error in -betterC because 
`main` is

  // `nothrow` but `test` isn't. It doesn't work
}

Attempt #3
--
version(D_BetterC)
{
enum nothrowValue = "nothrow:";
}
else
{
enum nothrowValue = "";
}

void test() { }

mixin(nothrowValue);

extern(C) void main()
{
test();   // This should throw an error in -betterC because 
`main` is

  // `nothrow` but `test` isn't. It doesn't work
}


Given that the PR above is for object.d, I can't turn the entire 
object.d source file into a string and conditionally mix that in. 
 Does anyone have a solution to this?


Thanks,
Mike

[Issue 18899] destroy is inefficient for small structs

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

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

--- Comment #6 from Manu  ---
memcpy should be an intrinsic, which is implemented using magic...

--

Re: Ideas for students' summer projects

[Mike Franklin via Digitalmars-d]

On Thursday, 24 May 2018 at 18:08:35 UTC, Patrick Schluter wrote:

As a contrived illustration, take a look at the code in 
https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  Those same features are also in Phobos.


OT, numberDigits enters an infinite loop if radix == 1.


and crashes for radix == 0


All the more reason to implement my proposal.

Re: Ideas for students' summer projects

[Patrick Schluter via Digitalmars-d]

On Wednesday, 23 May 2018 at 01:33:19 UTC, Mike Franklin wrote:

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


Let the brainstorming begin!


I would like to see a dependency-less Phobos-like library that 
can be used by the DMD compiler, druntime, -betterC, and other 
runtime-less/phobos-less use cases.  It would have no 
dependencies whatsoever.



As a contrived illustration, take a look at the code in 
https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  Those same features are also in Phobos.


OT, numberDigits enters an infinite loop if radix == 1.

Re: Ideas for students' summer projects

[Patrick Schluter via Digitalmars-d]

On Thursday, 24 May 2018 at 18:07:53 UTC, Patrick Schluter wrote:

On Wednesday, 23 May 2018 at 01:33:19 UTC, Mike Franklin wrote:
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu 
wrote:



Let the brainstorming begin!


I would like to see a dependency-less Phobos-like library that 
can be used by the DMD compiler, druntime, -betterC, and other 
runtime-less/phobos-less use cases.  It would have no 
dependencies whatsoever.



As a contrived illustration, take a look at the code in 
https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  Those same features are also in Phobos.


OT, numberDigits enters an infinite loop if radix == 1.


and crashes for radix == 0

Re: Translate C/C++ patern: return a pointer

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-05-24 11:10, biocyberman wrote:

Thanks for the hints. `Read` in C++ and D are both classes. And the 
function is inside the class definition itself.


In that case specifying the type as `Read` is the correct thing to do. 
Note that `new` always allocates on the heap and returns a pointer or 
reference type.


--
/Jacob Carlborg

Re: try & catch / repeating code - DRY

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-05-24 08:05, Robert M. Münch wrote:

Hi, great! Thanks for the examples... BTW: Is there a place where such 
generic and fundamental examples are collected?


Not as far as I know.


void handleException1(alias dg)()
{
 try dg();
 catch (Exception e) { /* handle exception */ }
}

void handleException2(lazy void dg)
{
 try dg();
 catch (Exception e) { /* handle exception */ }
}

void handleException3(scope void delegate () dg)
{
 try dg();
 catch (Exception e) { /* handle exception */ }
}

void main()
{
 handleException1!({
 writeln("asd");
 });

 handleException1!(() => writeln("asd"));

 handleException2(writeln("asd"));

 handleException3({
 writeln("asd");
 });
}


What is exactly the difference between handleException1 and 3?


With handleException1 the delegate needs to be passed as a template 
argument, in the other case as a regular argument. I thought that the 
lambda syntax, () => writeln("asd"), did not work as a regular argument, 
but I checked now and it does.


Passing it as a template argument might allow the compiler to inline it. 
All range functions in Phobos are using template argument approach.


--
/Jacob Carlborg

[Issue 18236] Invalid line reported on error casting enum

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8287

--

Re: dlang feed, thunderbird

[number via Digitalmars-d]

On 24.05.2018 17:38, Vladimir Panteleev wrote:

On Thursday, 24 May 2018 at 15:14:11 UTC, number wrote:
are the mlOnly ones like 'phobos' accessible, since they are public 
via the forum?  tried with server lists.puremagic.com but didn't work.


To access mailing lists with an email/news client, like Thunderbird, you 
will need to subscribe to them, e.g. at:


http://lists.puremagic.com/cgi-bin/mailman/listinfo/phobos

Unfortunately there is no way to download the archives for local 
browsing, only new messages will be delivered to your inbox. Replying to 
them is the same as replying to an email.




Ok, thanks!

Re: dlang feed, thunderbird

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 24 May 2018 at 15:14:11 UTC, number wrote:
are the mlOnly ones like 'phobos' accessible, since they are 
public via the forum?  tried with server lists.puremagic.com 
but didn't work.


To access mailing lists with an email/news client, like 
Thunderbird, you will need to subscribe to them, e.g. at:


http://lists.puremagic.com/cgi-bin/mailman/listinfo/phobos

Unfortunately there is no way to download the archives for local 
browsing, only new messages will be delivered to your inbox. 
Replying to them is the same as replying to an email.

Re: dlang feed, thunderbird

[number via Digitalmars-d]

On 24.05.2018 16:20, Vladimir Panteleev wrote:


This file is the source of truth for the forum.dlang.org mappings:

https://github.com/CyberShadow/DFeed/blob/master/config/gengroups.d



are the mlOnly ones like 'phobos' accessible, since they are public via 
the forum?  tried with server lists.puremagic.com but didn't work.

Re: dlang feed, thunderbird

[number via Digitalmars-d]

On 24.05.2018 16:13, Ali Çehreli wrote:

On 05/24/2018 06:36 AM, number wrote:
 > On Wednesday, 23 May 2018 at 18:50:37 UTC, Ali Çehreli wrote:

 > How do the newsgroups match to the forum categories (on the left here in
 > the forum), or specifically, what is the newsgroup for 'general' for
 > example?

These are the three I have and the first one is "General":

   news://www.digitalmars.com:119/digitalmars.D
   news://www.digitalmars.com:119/digitalmars.D.announce
   news://www.digitalmars.com:119/digitalmars.D.learn



.D does it, thanks! I wasn't sure if its just a collection of all the 
others.

Re: dlang feed, thunderbird

[number via Digitalmars-d]

On 24.05.2018 16:13, Ali Çehreli wrote:

On 05/24/2018 06:36 AM, number wrote:
 > On Wednesday, 23 May 2018 at 18:50:37 UTC, Ali Çehreli wrote:

 > How do the newsgroups match to the forum categories (on the left here in
 > the forum), or specifically, what is the newsgroup for 'general' for
 > example?

These are the three I have and the first one is "General":

   news://www.digitalmars.com:119/digitalmars.D
   news://www.digitalmars.com:119/digitalmars.D.announce
   news://www.digitalmars.com:119/digitalmars.D.learn



.D does it, thanks! I wasn't sure if its just a collection of all the 
others.

Re: dlang feed, thunderbird

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 24 May 2018 at 13:36:03 UTC, number wrote:
Thanks, that works much better, though i don't have links to 
the web version of posts as i had previously.


One thing you can do via NNTP which you can't do via feeds is 
post and reply :)


How do the newsgroups match to the forum categories (on the 
left here in the forum), or specifically, what is the newsgroup 
for 'general' for example?


This file is the source of truth for the forum.dlang.org mappings:

https://github.com/CyberShadow/DFeed/blob/master/config/gengroups.d

Re: dlang feed, thunderbird

[Ali Çehreli via Digitalmars-d]

On 05/24/2018 06:36 AM, number wrote:
> On Wednesday, 23 May 2018 at 18:50:37 UTC, Ali Çehreli wrote:

> How do the newsgroups match to the forum categories (on the left here in
> the forum), or specifically, what is the newsgroup for 'general' for
> example?

These are the three I have and the first one is "General":

  news://www.digitalmars.com:119/digitalmars.D
  news://www.digitalmars.com:119/digitalmars.D.announce
  news://www.digitalmars.com:119/digitalmars.D.learn

>>   From: =?UTF-8?Q?Ali_=c3=87ehreli?= 
>>
>> I did not set that manually; either Thunderbird or my Yahoo account
>> (which is my default SMTP account) must have done it. As far as I
>> know, that's the correct value.
>>
>
> I didn't even consider it could have indeed been caused on your side,

It could very well have been my fault in the olden days when I remember 
setting it manually in an older email client. :)


Ali

Re: Online impersonation

[Patrick Schluter via Digitalmars-d]

On Thursday, 24 May 2018 at 06:32:23 UTC, Dukc wrote:
On Wednesday, 23 May 2018 at 17:31:40 UTC, Steven Schveighoffer 
wrote:
The IP address is included in the headers of the newsgroup. 
All of them came from the same IP. I have a filter on my 
thunderbird client to flag certain IPs, and his was added to 
the list recently.


Then again, it's possible they're family members or neighbours 
using the same IP. How likely this is, I won't comment.


I don't this is a case of inpersonation if you're right, since 
the aliases have not been trying to inpersonate any real, exact 
person. But dishonourable action nonetheless.


It was quite obvious that KingJoffrey could be the sock puppeteer 
as he was childish and unreasonable all along the thread about 
private class members.

Re: dlang feed, thunderbird

[number via Digitalmars-d]

On Wednesday, 23 May 2018 at 18:50:37 UTC, Ali Çehreli wrote:


I don't think I'm using "feeds" with Thunderbird. Instead, I 
have an NNTP "account" in Thunderbird:


  www.digitalmars.com
  port: 119

Once that account was added, I had "subscribed" to some of the 
newsgroups.




Thanks, that works much better, though i don't have links to the 
web version of posts as i had previously.


How do the newsgroups match to the forum categories (on the left 
here in the forum), or specifically, what is the newsgroup for 
'general' for example?


The source of the same message looks like this for me in 
Thunderbird:


  From: =?UTF-8?Q?Ali_=c3=87ehreli?= 

I did not set that manually; either Thunderbird or my Yahoo 
account (which is my default SMTP account) must have done it. 
As far as I know, that's the correct value.




I didn't even consider it could have indeed been caused on your 
side, I thought maybe the forum software / feed generation was 
flawed.



> any ideas?

Not here... :/

Ali


It was already helpful, thanks! And I think the feed would work 
again, since the validator doesn't show the parsing error anymore.

Re: Migrating an existing more modern GC to D's gc.d

[Per Nordlöw via Digitalmars-d]

On Thursday, 24 May 2018 at 13:13:03 UTC, Steven Schveighoffer 
wrote:
Really though, the issues with D's GC are partly to blame from 
the language itself rather than the GC design. Having certain 
aspects of the language precludes certain GCs. Java as a 
language is much more conducive to more advanced GC designs.


I'm hoping for a tough long-term deprecation process that 
alleviates these issues eventhough they will cause big breakage. 
I believe it will be worth it.

Re: Migrating an existing more modern GC to D's gc.d

[Steven Schveighoffer via Digitalmars-d]

On 5/24/18 8:35 AM, Chris wrote:

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which kinds of GC's would be of interest?

Which attempts have been made already?


IBM has open sourced its JVM:

https://www.eclipse.org/openj9/

They claim they have good GCs. So maybe someone knowledgeable wants to 
have a look at it.


It's GPL, Apache, or EPL. I'm not sure about EPL, but I know that the 
former 2 are not convertible to Boost, so we couldn't accept a port from 
there.


Really though, the issues with D's GC are partly to blame from the 
language itself rather than the GC design. Having certain aspects of the 
language precludes certain GCs. Java as a language is much more 
conducive to more advanced GC designs.


-Steve

Re: Support alias this in module scope?

[12345swordy via Digitalmars-d]

On Thursday, 24 May 2018 at 07:07:48 UTC, Jonathan M Davis wrote:

On Thursday, May 24, 2018 06:42:21 Dukc via Digitalmars-d wrote:

On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer

wrote:
> and in others he has impersonated WalterBright as well.
>
> -Steve

Sorry forgot that part in my last post. If that's true, it 
makes it VERY serious.


It's true. There's at least one post where he posted as 
WalterBright (note the complete lack of spaces) and tried to 
make it look like Walter had decided that having private be 
restricted to the module rather than the class was a mistake. 
And if the lack of space in the name and the content weren't 
enough to figure out that it wasn't Walter, the headers made it 
clear that the post had come from the web forum, and AFAIK, 
Walter always posts using NNTP. This fellow has impersonated at 
least half a dozen people in the last couple of days.


- Jonathan M Davis


That guy show so much salt by doing that.

Re: return type of std.algorithm.mutation.reverse changed for good?

[biocyberman via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 12:34:38 UTC, Steven Schveighoffer 
wrote:

On 5/24/18 8:08 AM, rikki cattermole wrote:

On 25/05/2018 12:06 AM, biocyberman wrote:
I am testing with DMD 2.078.2 locally. This tiny snippet 
works on dlang's online editor: https://run.dlang.io/is/nb4IV4


But it does not work on my local dmd.

import std.algorithm.mutation;
import std.stdio;
char[] arr = "hello\U00010143\u0100\U00010143".dup;
writeln(arr.reverse);

Error: template std.stdio.writeln cannot deduce function from 
argument types !()(void)


The document says reverse returns a range: 
https://dlang.org/phobos/std_algorithm_mutation.html#reverse


https://docarchives.dlang.io/v2.078.0/phobos/std_algorithm_mutation.html#reverse



This doesn't quite tell the whole story.

An array used to have a .reverse property that the compiler 
implemented, which returned the array after reversing it. So in 
history, this actually worked without std.algorithm.


You get a nice history of what happens using "all dmd versions" 
on run.dlang.io. If you remove the "mutation" part from the 
import, you get:


Up to  2.071.2: Success with output: ŃĀŃolleh
2.072.2 to 2.074.1: Success with output:
-
onlineapp.d(6): Deprecation: use std.algorithm.reverse instead 
of .reverse property

ŃĀŃolleh
-

   2.075.1: Failure with output:
-
onlineapp.d(6): Error: template std.stdio.writeln cannot deduce 
function from argument types !()(void), candidates are:

/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/stdio.d(3553):
  std.stdio.writeln(T...)(T args)
-

2.076.1 to 2.077.1: Failure with output:
-
onlineapp.d(6): Error: template std.stdio.writeln cannot deduce 
function from argument types !()(void), candidates are:

/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/stdio.d(3571):
  std.stdio.writeln(T...)(T args)
-

   2.078.1: Failure with output:
-
onlineapp.d(6): Error: template std.stdio.writeln cannot deduce 
function from argument types !()(void), candidates are:

/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/stdio.d(3657):
  std.stdio.writeln(T...)(T args)
-

Since  2.079.0: Success with output: ŃĀŃolleh

-Steve


@Rikki and Steve: Many thanks for the good tips. I upgraded to 
dmd.2.080.0 now, but the server seems to be very slow. It's 
another story anyway.


 % ./install.sh dmd   
  
  
  
  !9767
Downloading and unpacking 
http://downloads.dlang.org/releases/2.x/2.080.0/dmd.2.080.0.linux.tar.xz


curl: (28) Operation too slow. Less than 1024 bytes/sec 
transferred the last 30 seconds
Failed to download 
'http://downloads.dlang.org/releases/2.x/2.080.0/dmd.2.080.0.linux.tar.xz'

Re: Migrating an existing more modern GC to D's gc.d

[Chris via Digitalmars-d]

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which kinds of GC's would be of interest?

Which attempts have been made already?


IBM has open sourced its JVM:

https://www.eclipse.org/openj9/

They claim they have good GCs. So maybe someone knowledgeable 
wants to have a look at it.

[Issue 18517] Import order is not invariant

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

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

--- Comment #1 from Jonathan Marler  ---
Added 2 tests to dmd for this bug here: https://github.com/dlang/dmd/pull/8165
but the PR was rejected. Razvan doesn't think tests should be pushed to dmd by
themselves (without their corresponding fixes).

> Razvan: I don't see much benefit in having tests that don't pass in the test 
> suite. This puts a burden on the autotester and encourages people to make PRs 
> just with tests creating a separation between the fix and the test.

--