Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote:


You don't need to have subsystem for Linux to use bash.  Just 
the standard git client for Windows is enough.




Happy to find out about this. It's not like using git bash 
everyday on Windows to know this by default.


sh setup.sh
[...]
make -> Command error: undefined switch '-C'

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Monday, 12 March 2018 at 03:37:11 UTC, Laeeth Isharc wrote:


cd test
make all -j8
Command error: undefined switch '-j8'


Why are you adding -j8 ? Does it say to do so in the 
instructions ? Try without it.  (I can't test here as typing 
from my phone).


https://wiki.dlang.org/DMD_development

Of course, it works without the -j8 switch, but the documentation 
doesn't say that multiple threads option is only available on 
Linux.

Re: Vision document for H1 2018

[Seb via Digitalmars-d-announce]

On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote:
On Monday, March 12, 2018 03:37:11 Laeeth Isharc via 
Digitalmars-d-announce wrote:

On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:
> [...]

Why are you adding -j8 ? Does it say to do so in the 
instructions ? Try without it.  (I can't test here as typing 
from my phone).


When dealing with building on Windows, it would definitely pay 
to read the instructions and not assume anything about make, 
since unfortunately, the Windows build uses the digital mars 
make, which is severely limited in comparison to the BSD make 
or GNU make.


- Jonathan M Davis


That's only partially true and the reason for the error. GNU/BSD 
make is required to run the DMD testsuite.
BTW removal of DigitalMars Make has been officially approved 
since a long time, but it's blocked since it's so hard to make 
changes to the auto-tester.

[Issue 18133] BitArray constructors are poorly documented.

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

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3609d7233414fbd8a9d0c21313be21aff02d6829
Merge pull request #6112 from byebye/issue_18133

Fix issue 18133 - improve docs and add code examples for BitArray constructors
merged-on-behalf-of: Jack Stouffer 

--

Re: Vision document for H1 2018

[Jonathan M Davis via Digitalmars-d-announce]

On Monday, March 12, 2018 03:31:36 Laeeth Isharc via Digitalmars-d-announce 
wrote:
> If Phobos looks like a mess to C# programmers, so much the worse
> for C# programmers.  However I doubt they this is true in the
> general case.  It's better in many ways, but different and
> unfamiliar and everything unfamiliar is disconcerting in the
> beginning.

Yeah, I remember when I was first dealing with D years ago, and the range
stuff that was in there was totally unfamiliar, and it annoyed me, because I
just wanted the iterators that I was familiar with so that I could easily do
what I wanted to do. Granted, it was worse to figure all of that out then,
since the documentation was much worse (e.g. at the time, there was a
compiler bug that made it so that auto return functions did not show up in
the documentation, so all of std.algorithm explicitly listed the return
types, making it downright scary), but still, at the time, I just didn't
want to deal with figuring out the unfamiliar concept, so it annoyed me.
Now, I actually understand ranges and am very glad that they're there, but
as a D newbie, they were annoying, because they were unfamiliar. I think
that I'd approach it all very differently now, since at the time, I was in
college and just generally a far less experienced programmer, but I think
that many of us tend to look for what we expect when learning a new language
or library, and when that's not what we get, it can be disconcerting to
begin with.

Phobos is very unique in its approach with ranges, likely making it a major
learning experience for anyone from any language, but AFAIK, the only
language with a comparable approach in its standard library is C++, and I'd
definitely expect it to be somewhat alien to the average C# or Java
programmer - at least to begin with. D does things differently, so anyone
learning it is just going to have to expect to deal with a learning curve.
How steep a curve that is is going to depend on the programmer's experience
and background, but it's going to be there regardless.

- Jonathan M Davis

Re: Vision document for H1 2018

[Jonathan M Davis via Digitalmars-d-announce]

On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce 
wrote:
> On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:
> > On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:
> >> [...]
> >
> > Yes, I'm the typical lazy convenient Windows user scared of the
> > terminal window.
> >
> >> [...]
> >
> > I am happy for Posix users. Theoretically the process is the
> > same on Windows.
> >
> >> [...]
> >
> > This will need Linux subsystem as a Windows feature installed.
> > Bash scripts do not work on Windows. Or other third party
> > applications that are not listed as prerequisites on wiki.
> >
> >> [...]
> >
> > make -fwin32.mak release
> > Error: don't know how to make 'release'
> >
> > Ok, let's skip this, make it without "release".
> >
> > Now test it:
> >
> > cd test
> > make all -j8
> > Command error: undefined switch '-j8'
>
> Why are you adding -j8 ? Does it say to do so in the instructions
> ? Try without it.  (I can't test here as typing from my phone).

When dealing with building on Windows, it would definitely pay to read the
instructions and not assume anything about make, since unfortunately, the
Windows build uses the digital mars make, which is severely limited in
comparison to the BSD make or GNU make.

- Jonathan M Davis

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


Hey.. I feel your pain.. I like things to be easy too ;-)

but I think comparing things in the C# world, to things in the D 
world, does not make a lot of sense, really.


It's like comparing my local corner shop to some worldwide 
supermarket chain.


What's the point in going into the local corner shop and 
complaing that they don't stock this or that, but the supermarket 
down the road does. Or complaining that they charge $4 for a loaf 
of bread, when down the road at the supermarket it only costs 
$2.50.


You have to compare apples with apples, not apples with shiny red 
toffee apples ;-)

[Issue 18591] DMD should allow access to mixin template declarations

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #2 from Simen Kjaeraas  ---
Issue example from PR:

struct TypeObj
{
alias This = typeof(this);

mixin template MixinTempl()
{
int value;
}
}

ref TypeObj Obj()
{
static TypeObj a;
return a;
}

void main()
{
mixin Obj.This.MixinTempl; // ok
mixin Obj.MixinTempl;  // error: "MixinTempl!()" is not defined
}

--

Re: How do you call an eponymous template that has a secondary template arg?

[Simen Kjærås via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 12:05:56 UTC, aliak wrote:

* aliasOf!int!"string" // multiple ! arguments are not allowed
* (aliasOf!int)!"string" // error c-style cast
* aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) 
does not have property 'isAliasOf


Yeah, that's a little hole in the grammar, but there are ways:

// Declare an alias:
alias aliasOfInt = aliasOf!int;

// And use that:
assert(!aliasOfInt!string);


Or use std.meta.Instantiate:

assert(!Instantiate!(aliasOf!int, string));

--
  Simen

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Monday, 12 March 2018 at 03:13:08 UTC, Seb wrote:
Out of interest: I wonder what's your usecase for using qsort. 
Or in other words: why you can't use the high-level 
std.algorithm.sorting.sort?


This is only temporary. I will be using 
std.algorithm.sorting.sort. I was converting a C program and it 
annoyed me that I couldn't get the qsort invocation past the D 
compiler.

Re: Question over C++ to D conversion

[jmh530 via Digitalmars-d]

On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote:

[snip]
For conversion of C headers, watch this space.  C first, C++ 
eventually.  Might be a talk at Dconf on it.


I think I saw a reference to this somewhere else. Sounds pretty 
darn cool.

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

[...]


Yes, I'm the typical lazy convenient Windows user scared of the 
terminal window.



[...]


I am happy for Posix users. Theoretically the process is the 
same on Windows.



[...]


This will need Linux subsystem as a Windows feature installed. 
Bash scripts do not work on Windows. Or other third party 
applications that are not listed as prerequisites on wiki.



[...]


make -fwin32.mak release
Error: don't know how to make 'release'

Ok, let's skip this, make it without "release".

Now test it:

cd test
make all -j8
Command error: undefined switch '-j8'


Why are you adding -j8 ? Does it say to do so in the instructions 
? Try without it.  (I can't test here as typing from my phone).

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


And personally, depending on the problem, C# is better to 
program in than D. I still don't know why C# programmers are 
willing to give up C# and prefer to use D.

C# is vastly surperior for what it does.



Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.


I suppose that every C# programmer is enthusiastic on the first 
contact with the D language, but fails to keep his enthusiasm 
when he sees Phobos. C# programmer's mind is locked in the OOP 
world and Phobos looks like a mess from his point of view.


The problem is that D stagnates and in the same time C# 
evolves. Sometimes I feel like the C# language team is using D 
as inspiration for the new features, starting with C# 7.0, a 
lot of D concepts were introduced in the language: local 
functions, '_' as digit separator, binary literals, ref 
returns, tuples, templates, immutability. Guess what the next 
version of C# has on the table: slices.


In the same time, D delegates new features (and sometime 
existing ones) to library implementation, instead of assume 
them in the language syntax.


My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


It's a good thing not bad that other languages are inspired by 
what works.  Languages aren't in a vicious battle to the death, a 
Hobbesian war of all against all.  If C# gets better, that's 
great!


I don't think D is stagnating at all - on the contrary, it's 
amazing to see the ecosystem flourishing, no matter where you 
look - documentation, adoption, libraries, commercial adoption.


I think it's reasonable to disagree with the strategic decision 
made to move capabilities from compiler to libraries.  But you 
really have to make an argument about why you disagree if you are 
you expect to be persuasive because there is a thought-through 
argument for the choices made, which I am sure you must be 
familiar with.


I don't think it matters much whether you are right about what 
happens to C# programmer interest in D dies as soon as C# native 
cross-platform is ready because D is quite an ambitious language 
and doesn't need to depend on adoption from any one community to 
continue growing at an impressive rate.  As it happens though, as 
an empirical matter I doubt it.


C# slices look great.  I wanted to use them for generating 
wrappers for our analytics.  Not that easy for that purpose, from 
what I could see.  Looks like the primitives are stack only, and 
I tried to figure out how to use them elsewhere and gave up 
because it wasn't that easy.


If Phobos looks like a mess to C# programmers, so much the worse 
for C# programmers.  However I doubt they this is true in the 
general case.  It's better in many ways, but different and 
unfamiliar and everything unfamiliar is disconcerting in the 
beginning.

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |INVALID

--- Comment #1 from Walter Bright  ---
(In reply to Mike Franklin from comment #0)
> void main() @safe
> {
> string foo = "foo";
> scope string*[] ls;
> ls ~= 
> }
> 
> Compile with `-dip1000`
> 
> onlineapp.d(5): Error: reference to local variable foo assigned to non-scope
> ls

While ls is scope, ls[] is not scope. Scope is not transitive, hence the
compiler error.


> The compiler doesn't seem to recognize that ls is attributed with `scope`. 
> However due to the way D's attributes are parsed, I'm not sure if it should
> actually be `scope string*[]`, `scope(string*)[]`, or `scope(string*[])`. 
> Anyway, if you use `scope()` (i.e. with parens) the compiler confuses it
> with `scope(exit)` and friends.
> 
> 
> void main() @safe
> {
> string foo = "foo";
> scope(string*[]) ls;
> ls ~= 
> }
> 
> Compile with `-dip1000`
> 
> onlineapp.d(4): Error: valid scope identifiers are exit, failure, or
> success, not string

Scope is a storage class, not a type constructor. (`const`, for example, is a
type constructor, and `static` is a storage class.)

--

Re: core.stdc.stdlib._compare_fp_t and qsort

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

On Monday, 12 March 2018 at 02:44:17 UTC, Joe wrote:
I saw the extern(C) and I believe I tried it before my previous 
post, but dismissed it because I saw no difference in compiler 
behavior.


Yeah, the compiler should just tell you what specifically it is 
complaining about instead of making you hunt. These "no function 
match" errors are actually my #1 pain point as a daily D user... 
and as a regular D tech support rep, I see there are very 
frequent problems for everyone else too.


Could you explain or direct me to something that elucidates why 
the "scope" qualifiers are needed?  And is there something else 
that is necessary inside compar() or are the "scope"s just for 
decorative purposes?


So `scope` means you promise not to escape the reference outside 
your scope; that you won't store the pointers somewhere else for 
future use.


It is defined here: 
https://dlang.org/spec/function.html#parameters tho that's pretty 
light.


The compiler only checks it if you throw some random 
-dipsomething switch. The idea is something similar to Rust's 
borrow checker. It aims to make it a compile error to sneak out 
pointers to temporaries through our callback. You wouldn't do 
that anyway with a compare function, but now it is an error to 
try ( if the strict enforcement thing is thrown. and i don't 
remember the name, they are all random dip numbers on the 
switches)


I'm actually mildly against adding these directly to C functions, 
but this attribute spam is being added to all the druntime 
definitions. It requires stuff like nothrow and nogc on a bunch 
of handlers too, ugh, but the idea behind it is to make sure you 
don't break the C function's documented rules, but here checked 
by the D compiler without needing any runtime wrappers/checks.




But until recently it wasn't checked at all which is why I wasn't 
sure if that was causing your error. I guess it is required to 
match the function call even if the strict enforcement isn't 
thrown now.

Re: dpldocs now has cross-package search (experimental)

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

I probably released this a bit too soon... it seems to have a 
memory leak and eventually pushes all other server functions out 
if I leave it running.


So I took the search back down for now until I can debug that, or 
maybe just rewrite the program to something fundamentally more 
memory-efficient.

Re: core.stdc.stdlib._compare_fp_t and qsort

[Seb via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 23:12:30 UTC, Joe wrote:

I'm getting a compiler error in a qsort() call as follows:

qsort(recs, num_recs, (Record *).sizeof, compar);

Record is a struct, recs is a fixed array of pointers to 
Record's and num_recs is a size_t that holds the number of 
valid records.


compar is this:

int compar(const void *p1, const void *p2)
{
import core.stdc.string : strcmp;
const Record **rp1 = cast(Record **)p1;
const Record **rp2 = cast(Record **)p2;

return strcmp((*rp1).name.ptr, (*rp2).name.ptr);
}

The error is: Error: function testd.compar (const(void*) p1, 
const(void*) p2) is not callable using argument types ()


I don't quite understand what those parentheses mean: is it 
implying "no arguments" and if so, where would one provide 
arguments?


Joe


Out of interest: I wonder what's your usecase for using qsort. Or 
in other words: why you can't use the high-level 
std.algorithm.sorting.sort?

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


Funnily enough, becoming a significant contributor to the 
ecosystem - compiler or Phobos - demonstrably does not require 
even a complete graduation from high school or any industrial 
programming experience.  I know of what I speak, but I don't say 
who as it's not for me to say.


I was in Munich over new year and I asked someone else who has 
been a star contributor how he got involved.  It was really easy 
for him to start contributing, so he did.  But different people 
find different things easy.


You don't need to have subsystem for Linux to use bash.  Just the 
standard git client for Windows is enough.


I agree the Windows experience could be easier upfront.  Still, 
it's better than it used to be and next year it will be better 
again.


You can't really compare the C# ecosystem to the D ecosystem 
because they are organised around different principles.  Yes, the 
pain is upfront with D, and it's not for everyone.  However on 
the basis of rational calculation the pain in learning something 
new is a small part of the total cost of the technology choice 
and for some people by far not the most relevant question.


And it's an advantage in hiring because the D community filters 
for people who have a tolerance for discomfort upfront.


It would be wonderful to be able to wave a wand and make all of 
life's little frustrations disappear.  But in my experience, 
that's not what is possible - one picks from the choices 
available and the new ones one thinks up.  People have a tendency 
to think that leadership has more power to just change things 
then is actually the case.


I'm going to be building standard developer images from scratch 
programmatically.  Transform froma Windows  ISO into  a VM 
image.Maybe I could open source those scripts and then it's 
easier to get to the bottom of any install and build problems and 
one can replicate difficulties.

[Issue 17961] std.uni does not compile with -unittest -dip1000

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 Blocks||18585


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18585
[Issue 18585] Linker error if compiled with -dip1000
--

[Issue 18585] Linker error if compiled with -dip1000

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

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

Carsten Blüggel  changed:

   What|Removed |Added

   Keywords||rejects-valid, safe
 CC||chi...@posteo.net
 Depends on||17961

--- Comment #1 from Carsten Blüggel  ---
The origin of errors seems to be, that std.uni is not -dip1000 compilable
currently.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17961
[Issue 17961] std.uni does not compile with -unittest -dip1000
--

Re: Question over C++ to D conversion

[Laeeth Isharc via Digitalmars-d]

On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote:


The second is that mbed uses C++ class's for it's API
most of this is just headers such
I was wondering if there are any other ways that are known 
about for translating C++ into D, or accessing C++ libraries.


Many Thanks
Richard


See Gooberman fork of binderoo.  It only worked on Windows and X 
Box before, but now it should work on Linux.  That's for C++ 
talking to D.  C# to follow.


For conversion of C headers, watch this space.  C first, C++ 
eventually.  Might be a talk at Dconf on it.


Also see the tool in Visual D, which I haven't yet used myself.

Re: Question over C++ to D conversion

[Mike Franklin via Digitalmars-d]

On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote:


There's a couple of outstanding things at the moment though

The first is the use of BetterC, although from what I can tell 
DMD now has support for a minimal runtime feature as part of 
2.079.0

https://dlang.org/changelog/2.079.0.html#minimal_runtime
so hopefully when this makes it's way into LDC I can then make 
use of it for an Arm MCU for creating class's without the full 
runtime.

https://github.com/ldc-developers/ldc/pull/2587


I'm hoping for that to land soon as well.  The minimal runtime 
features and -betterC do have some overlap, but there are some 
specific things -betterC does that the minimal runtime doesn't 
do.  See https://dlang.org/spec/betterc.html.  At least one such 
feature is "assert failures are directed to the C runtime 
library".


The minimal runtime has uses for those wishing to port the 
druntime to a new platform or architecture and do so 
incrementally.  It's also useful for those that may choose to 
implement minimal subset of runtime features or provide an 
alternate implementation of a runtime feature for their 
application.  This is especially useful in the embedded domain 
where there is typically one process running, and you know 
upfront what features you will need or not need; and you won't 
have to do the work of porting everything just to get a build.


-betterC, on the other hand, is somewhat of a blunt instrument, 
and removes certain features of the runtime wholesale.


With the minimal runtime features, you will be able to create a 
betterC-like application by simply avoiding features that you 
haven not implemented in your port of the runtime.  That wasn't 
possible prior to 2.079.0.



I was wondering if there are any other ways that are known 
about for translating C++ into D, or accessing C++ libraries.


I'm sorry I don't know of any reliable tool that can create 
bindings to C++ libraries automatically.


Mike

Re: Date range iteration

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 12, 2018 02:11:49 Jordan Wilson via Digitalmars-d-learn 
wrote:
> I wanted to iterate through a date range, so I initially tried:
> iota(Date(2016,1,1),Date(2018,1,1),dur!"days"(1));
>
> That wouldn't compile, which is fair enough I guess.

Maybe iota should be made to work, but as present, it basically wants all
three of the types it's given to be the same or implicitly convertible to
a single type. It can't handle the step being a completely different type.

> So I tried a for loop:
> for (auto i = Date(2016,1,1); i < Date(2018,1,1);
> i+=dur!"days"(1)){}
>
> That seemed to work fine, but I remember reading "for loops are
> bad" somewhere.

for loops are just fine - especially if you're just going to loop through
all the values and do something to them - but if you have a range, it's a
lot more flexible.

> So I looked for a range type mechanism, and I
> think it's this:
> foreach (i; Interval!Date
> (Date(2016,1,1),Date(2018,1,1)).fwdRange ( (a) { return
> a+dur!"days"(1); })){}
>
> My question is if the third way is the proper way of stepping
> through a period of time? It just seems quite complicated to me.

Well, honestly, the range support in std.datetime isn't very good. The core
problem that overcomplicates it is that the Interval needs to know which
direction you want to iterate in, and then the helper functions tend to need
to know it too in order to work properly. Also, the time point type being
used also tends to get duplicated a fair bit. So, you end up with annoyingly
repetitive code. The helper function intended for this use case is

https://dlang.org/phobos/std_datetime_interval.html#everyDuration

So, you'd get something more like

auto interval = Interval!Date(Date(2016, 1, 1), Date(2018, 1, 1));
auto range = interval.fwdRange(everyDuration!Date(days(1)));

But if you're just going to use the range in a foreach loop, then you might
as well just use a for loop. All of this extra machinery only really starts
being valuable when you start feeding the ranges into range-based functions.
For a simple loop, it's overkill.

- Jonathan M Davis

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Monday, 12 March 2018 at 01:45:54 UTC, Adam D. Ruppe wrote:
I just reformatted it but now the difference should be visible: 
`extern(C)` is missing on your callback.


The scope things might make a difference too, but I know for 
sure extern(C) is necessary on your callback function.


I saw the extern(C) and I believe I tried it before my previous 
post, but dismissed it because I saw no difference in compiler 
behavior.  In any case declaring


extern (C) int compar(const (void *) p1, const (void *) p2) {
   ... // as before
}

still gives the error:

function core.stdc.stdlib.qsort (scope void* base, ulong nmemb, 
ulong size, extern (C) int function(scope const(void*), scope 
const(void*)) @system compar) is not callable using argument 
types (void*, ulong, ulong, extern (C) int function(const(void*) 
p1, const(void*) p2))


It only went away with

extern (C) int compar(scope const (void *) p1, scope const (void 
*) p2)


Could you explain or direct me to something that elucidates why 
the "scope" qualifiers are needed?  And is there something else 
that is necessary inside compar() or are the "scope"s just for 
decorative purposes?


Joe

[Issue 18000] [scope] auto-generated opAssign not scope aware

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

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

--- Comment #1 from Walter Bright  ---
Attributes are inferred for the generated opAssign, the result looks like:

   @nogc ref return @trusted File opAssign(File p)

Not sure why scope is not inferred.

In any case, the example has problems as well:

scope File f;
f = File();

The lifetime of File() is less than that of f, so this example should fail to
compile for that reason. https://issues.dlang.org/show_bug.cgi?id=17977
addresses that.

--

Re: Question over C++ to D conversion

[Mike Parker via Digitalmars-d]

On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote:

I was wondering if there are any other ways that are known 
about for translating C++ into D, or accessing C++ libraries.




If you have access to a Windows box, this might help get you 
there:


http://rainers.github.io/visuald/visuald/CppConversion.html

Date range iteration

[Jordan Wilson via Digitalmars-d-learn]

I wanted to iterate through a date range, so I initially tried:
iota(Date(2016,1,1),Date(2018,1,1),dur!"days"(1));

That wouldn't compile, which is fair enough I guess.

So I tried a for loop:
for (auto i = Date(2016,1,1); i < Date(2018,1,1); 
i+=dur!"days"(1)){}


That seemed to work fine, but I remember reading "for loops are 
bad" somewhere. So I looked for a range type mechanism, and I 
think it's this:
foreach (i; Interval!Date 
(Date(2016,1,1),Date(2018,1,1)).fwdRange ( (a) { return 
a+dur!"days"(1); })){}


My question is if the third way is the proper way of stepping 
through a period of time? It just seems quite complicated to me.


Thanks,

Jordan

[Issue 18591] DMD should allow access to mixin template declarations

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

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

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

https://github.com/dlang/dmd/commit/786bdb338a64fa52b24ab515edf6706b259447de
Fix Issue 18591 - Allow getting type from template declarations.

--

Re: core.stdc.stdlib._compare_fp_t and qsort

[H. S. Teoh via Digitalmars-d-learn]

On Mon, Mar 12, 2018 at 01:04:06AM +, Joe via Digitalmars-d-learn wrote:
> On Sunday, 11 March 2018 at 23:26:04 UTC, Stefan Koch wrote:
> > You have to pass a pointer to the function.
> > Otherwise it'll be a parenthsis-less call.
> > use :  qsort(recs, num_recs, (Record *).sizeof, );
> 
> After passing a pointer, getting some other error messages, I changed
> the call to
> 
> qsort(cast(void *)recs, num_recs, cast(size_t)(Record *).sizeof,
> );
> 
> and the latest error is:
> 
> Error: function core.stdc.stdlib.qsort (scope void* base, ulong nmemb, ulong
> size, extern (C) int function(scope const(void*), scope const(void*))
> @system compar) is not callable using argument types (void*, ulong, ulong,
> int function(const(void*) p1, const(void*) p2))
> 
> I fail to see which argument is causing the problem now.
[...]

I wonder if the problem is because qsort expects a C linkage function
(`extern (C) int function(...)`), but you're passing a D linkage (i.e.,
native) function to it.  You can't do that, because the order of
arguments in a D linkage function may differ from a C linkage function,
and could potentially cause a subtle bug if you're not expecting the
arguments in a different order. (I actually ran into this myself, in a
different context where there was no type enforcement like there is
here, and it took me a long time to track down the problem.)

If indeed this is the problem, try adding `extern (C)` to your D
function to make it compatible with C linkage, and that should do the
trick.  I think.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly 
safe; if you look at it the thousandth time, you are in frightful danger of 
seeing it for the first time. -- G. K. Chesterton

Re: core.stdc.stdlib._compare_fp_t and qsort

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

On Monday, 12 March 2018 at 01:04:06 UTC, Joe wrote:

and the latest error is:


D's error messages are so bad and shouldn't be hard to fix. It 
kills me that basic every-day functionality like this isn't a 
priority to the core devs. I even wrote a patch myself that would 
call this out but it didn't fit the code style so rejected. Ugh. 
But behold:


(scope void* base,
ulong nmemb,
ulong size,
extern (C) int function(scope const(void*), scope const(void*)) 
@system compar)


(void*,
ulong,
ulong,
int function(const(void*) p1, const(void*) p2))



I just reformatted it but now the difference should be visible: 
`extern(C)` is missing on your callback.


The scope things might make a difference too, but I know for sure 
extern(C) is necessary on your callback function.

Re: Vision document for H1 2018

[Frank Brassard via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.
As an aside, I had to translate a special-use decompression 
algorithm from C# to D, and it was a near seamless transition. 
I'm trying to persuade some of my C# compatriots to try D because 
of that experience.

Question over C++ to D conversion

[Richard via Digitalmars-d]

Hi,
I'm sure this question has been asked a few times before
But I'm currently looking at something that will convert Cpp code 
to D


I've recently setup a proof of concept demo which uses mbed for 
an embedded LPC1769 Arm board
This is just a test, but I've recently managed to get debugging 
working across both C and D files at the same time.
This means single stepping code on a remotely attached Arm board 
in VSCode, while being able to inspect registers with an svd file

https://github.com/grbd/GBD.Dlang.MbedBlinkyTest

There's a couple of outstanding things at the moment though

The first is the use of BetterC, although from what I can tell 
DMD now has support for a minimal runtime feature as part of 
2.079.0

https://dlang.org/changelog/2.079.0.html#minimal_runtime
so hopefully when this makes it's way into LDC I can then make 
use of it for an Arm MCU for creating class's without the full 
runtime.

https://github.com/ldc-developers/ldc/pull/2587

These were also mentioned in a separate thread.
  * https://bitbucket.org/timosi/minlibd
  * https://github.com/JinShil/stm32f42_discovery_demo
  * https://github.com/kubo39/stm32f407discovery


The second is that mbed uses C++ class's for it's API
most of this is just headers such as DigitalOut.h
https://github.com/ARMmbed/mbed-os/blob/master/drivers/DigitalOut.h
So ideally I've been looking for something that can translate 
those headers into Dlang so they can be used there instead.


  * The first two utils I've found were DStep and htod, however 
they seem to only hand C

https://github.com/jacob-carlborg/dstep

  * I discovered some examples of libraries over here
https://github.com/D-Programming-Deimos

  * There's CPP2D but the last update was around 2016
https://github.com/lhamot/CPP2D

  * Calypso seems to be a Fork of LDC, but I think it might be a 
while before 2.079.0 makes it in.

https://github.com/Syniurge/Calypso

One possibility I might look into is a D backend for CppSharp 
if I can figure it out, since I'm familiar with C#.

  * https://github.com/mono/CppSharp

I was wondering if there are any other ways that are known about 
for translating C++ into D, or accessing C++ libraries.


Many Thanks
Richard

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 23:26:04 UTC, Stefan Koch wrote:

You have to pass a pointer to the function.
Otherwise it'll be a parenthsis-less call.
use :  qsort(recs, num_recs, (Record *).sizeof, );


After passing a pointer, getting some other error messages, I 
changed the call to


qsort(cast(void *)recs, num_recs, cast(size_t)(Record 
*).sizeof, );


and the latest error is:

Error: function core.stdc.stdlib.qsort (scope void* base, ulong 
nmemb, ulong size, extern (C) int function(scope const(void*), 
scope const(void*)) @system compar) is not callable using 
argument types (void*, ulong, ulong, int function(const(void*) 
p1, const(void*) p2))


I fail to see which argument is causing the problem now.

Joe

[Issue 17959] [DIP1000] Can store scope delegate in non-scope member

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8008

--

[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Walter Bright  ---
Adding @safe to the lambda:

  void test() @safe
  {
int var;
scope int* p;
static int* escape;
static assert(!__traits(compiles, () @safe { escape = p; }));
  //escape = p;
  }

and it compiles without error. The lambda does not inherit @safe from the
function. Perhaps it should, but that would be an enhancement request, and
would possibly break existing code. It should be the subject of a separate
issue.

--

Re: core.stdc.stdlib._compare_fp_t and qsort

[Stefan Koch via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 23:12:30 UTC, Joe wrote:

I'm getting a compiler error in a qsort() call as follows:

qsort(recs, num_recs, (Record *).sizeof, compar);

Record is a struct, recs is a fixed array of pointers to 
Record's and num_recs is a size_t that holds the number of 
valid records.


compar is this:

int compar(const void *p1, const void *p2)
{
import core.stdc.string : strcmp;
const Record **rp1 = cast(Record **)p1;
const Record **rp2 = cast(Record **)p2;

return strcmp((*rp1).name.ptr, (*rp2).name.ptr);
}

The error is: Error: function testd.compar (const(void*) p1, 
const(void*) p2) is not callable using argument types ()


I don't quite understand what those parentheses mean: is it 
implying "no arguments" and if so, where would one provide 
arguments?


Joe


You have to pass a pointer to the function.
Otherwise it'll be a parenthsis-less call.
use :  qsort(recs, num_recs, (Record *).sizeof, );

core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

I'm getting a compiler error in a qsort() call as follows:

qsort(recs, num_recs, (Record *).sizeof, compar);

Record is a struct, recs is a fixed array of pointers to Record's 
and num_recs is a size_t that holds the number of valid records.


compar is this:

int compar(const void *p1, const void *p2)
{
import core.stdc.string : strcmp;
const Record **rp1 = cast(Record **)p1;
const Record **rp2 = cast(Record **)p2;

return strcmp((*rp1).name.ptr, (*rp2).name.ptr);
}

The error is: Error: function testd.compar (const(void*) p1, 
const(void*) p2) is not callable using argument types ()


I don't quite understand what those parentheses mean: is it 
implying "no arguments" and if so, where would one provide 
arguments?


Joe

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

--- Comment #11 from Rainer Schuetze  ---
BTW: AFAIK -dip1000 is only supposed to affect @safe code, but there is no
@safe in the original test cases.

--

Re: How do you call an eponymous template that has a secondary template arg?

[aliak via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 13:44:38 UTC, Basile B. wrote:


The first version works here:

```
template aliasOf(T) {
enum aliasOf(alias a) = is(typeof(a) == T);
}

string s;

pragma(msg, allSatisfy!(aliasOf!string, s, "string"));
```



I can see that my description was a little confusing, sorry about 
that, I meant to ask how would you call that without using the 
allSatisfy meta template. If I were to call it as a stand alone, 
ie:


writeln(aliasOf!stringtemplate?>);


I hope that makes it clearer.


Now on the fact that what is done is correct is another story.
If the literal passed is supposed to be a type then it's 
clearly wrong.

You'd have to mix it:

```
template aliasOf(T)
{
template aliasOf(alias a)
{
mixin("alias A = " ~ a ~ ";");
enum aliasOf = is(A == T);
}
}

alias myString1 = string;
alias myString2 = string;

pragma(msg, allSatisfy!(aliasOf!string, "myString1", 
"myString2"));

```


Aye, I see what you mean, but it is supposed to be a literal of a 
specific type. I.e. 3, "some string", SomeType(), etc.


So aliasOf!int.aliasOf!3 // true

Also, if I define it like this:

template aliasOf(T) {
auto aliasOf(U)(U) { return is(U == T); }
}

Then at least I can call it like:

writeln(aliasOf!int(3)); // prints true

But then I can't do:

allSatisfy!(aliasOf!int, 3)

I guess because it's a function now and not a template anymore so 
can't be used by allSatisfy.

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Rainer Schuetze  ---
I didn't mean to change the status, but reopening is probably appropriate.

--

Re: DConf hotel poor QoS

[aberba via Digitalmars-d]

On Friday, 9 March 2018 at 15:26:24 UTC, Luís Marques wrote:
I'm not impressed with the conference hotel so far. Here's a 
summary of my interactions with them:


[...]


It might as well be your are talking with different employees 
changing shift. "The nightmare in customer support"... and they 
don't have a system to track previous discussions easily.

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #9 from ag0ae...@gmail.com ---
(In reply to Rainer Schuetze from comment #8)
> As with the modified reduced test case with @safe, this is still crashing
> for me (Win32 and Win64 with git HEAD). Checking the disassembly for
> compiling with -dip1000 it doesn't generate the closure that it is
> generating without the switch.

If it still crashes, did you mean to reopen this issue? (You changed it from
WORKSFORME to FIXED.)

--

[Issue 18594] X is not an lvalue should have a better error message

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

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

Seb  changed:

   What|Removed |Added

Summary|constant 1 is not an lvalue |X is not an lvalue should
   |should have a better error  |have a better error message
   |message |

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

Rainer Schuetze  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #8 from Rainer Schuetze  ---
> Fixing the code with @safe and @trusted:

As with the modified reduced test case with @safe, this is still crashing for
me (Win32 and Win64 with git HEAD). Checking the disassembly for compiling with
-dip1000 it doesn't generate the closure that it is generating without the
switch.

--

[Issue 18594] constant 1 is not an lvalue should have a better error message

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

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

--- Comment #1 from Seb  ---
(PR incoming)

--

[Issue 18594] New: constant 1 is not an lvalue should have a better error message

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

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

  Issue ID: 18594
   Summary: constant 1 is not an lvalue should have a better error
message
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

---
void main() {
assert(1 = 2);
}
---

currently errors with "foo.d(2): Error: constant 1 is not an lvalue".
The error message should be better: (1) not mention lvalue and (2) suggesting
`==`.

--

[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Walter Bright  ---
The following remain:

---
@safe:
struct Context0x0 { char[]   str; }

struct Parent0x1 { Context0x0  c; }
struct Parent0x2 { Context0x0[1] csa; }
struct Parent0x3 { Context0x0[]  csl; }
struct Parent0x4 { Context0x0*cp; }

struct Parent0x5 { Parent0x1  p1; }
struct Parent0x6 { Parent0x5  p5; }
struct Parent0x7 { Parent0x6  p6; }

struct Parent0x8 { Parent0x2[1]*  p2; }
struct Parent0x9 { Parent0x8[1]   p8; }
struct Parent0xA { Parent0x9[1]   p9; }

struct Parent0xB { Parent0x4* p4; }
struct Parent0xC { Parent0xB* pb; }
struct Parent0xD { Parent0xC* pc; }

char[] global;

void use0x2(scope char[]* arr)
{
global = *arr; // NG - accepts invalid
}

void use0x9(scope ref Parent0x4 p)
{
global = p.cp.str; // NG - accepts invalid
}

void use0xB(scope ref Parent0xA p)
{
global = (*p.p9[0].p8[0].p2)[0].csa[0].str; // NG - accepts invalid
}

void use0xC(scope ref Parent0xD p)
{
global = p.pc.pb.p4.cp.str; // NG - accepts invalid
}
---

All of them are instances of transitive scope, but scope is not transitive. Not
compiler bugs.

--

[Issue 18593] New: std.datetime.stopwatch.benchmark shouldn't optimize away its functions

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

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

  Issue ID: 18593
   Summary: std.datetime.stopwatch.benchmark shouldn't optimize
away its functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: pull
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See: https://github.com/dlang/phobos/pull/5416

--

[Issue 15653] IFTI fails for immutable parameter

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

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

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

   What|Removed |Added

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

--

[Issue 15653] IFTI fails for immutable parameter

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

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

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

https://github.com/dlang/dmd/commit/d68e181bda060f8e61253620695a3aadf0ad1093
Fix issue 15653 - IFTI fails for immutable parameter

https://github.com/dlang/dmd/commit/5fa45d1a355b5bd24caaeddf71b21d94561c3174
Add links to bugzilla for issue 15653

https://github.com/dlang/dmd/commit/25fbcbe2baaf085e679bc281954b208e076d7471
Merge pull request #7977 from JinShil/fix_15653

Fix issue 15653 - IFTI fails for immutable parameter
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

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

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

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8001

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Walter Bright  ---
Fixing the code with @safe and @trusted:

---
module test;

@safe:
struct Event9834
{
  @safe:
void delegate() dg;
void set(void delegate() @safe h) pure { dg = h; }  // AV occurs
void call() { dg(); }
}

void main()
{
Event9834 ev;
auto a = new class
{
Object o;
this() @safe
{
o = new Object;
ev.set(() @trusted { o.toString(); });
}
};
ev.call();
}
---

and it compiles and runs without error, with or without -dip1000.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

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

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

--- Comment #35 from Walter Bright  ---
(In reply to Shachar Shemesh from comment #33)
> You cannot be notified when the object
> moves, and once it does, the global linked list will get completely
> corrupted.

That is correct, and you are right to be concerned about it.

However, from a pragmatic point of view, the compiler cannot move objects that
have external pointers to them (unless it can unambiguously find them all and
update them). This is why, for example, there is an API in the GC to register
pointers to objects that are unknown to the GC.

Why was it moving the stack allocated objects in these examples? Because when
it went out of scope, it is safe to assume that there are no extant pointers to
it. This is why the compiler (now) complains when the code registers a pointer
to the stack object. Of course, making the code @trusted enables code like this
to be written, leaving it up to the programmer to ensure the safety.

But there's another wrinkle. With RVO (Return Value Optimization), if the stack
object is returned, and it is not returned in registers, it is actually not
returned. It is allocated in the caller's stack frame! and is not moved. This
is now the case with all the examples you've provided.

So, to guarantee RVO:

1. the object must be returned on the stack, not in registers. This can be
tested as shown in the documentation:

  https://dlang.org/spec/traits.html#isReturnOnStack

Generally speaking, a struct that is larger than two registers, or is not POD
(Plain Old Data), will return on the stack and not in registers.

2. use only one return statement in the function. Having multiple returns can
defeat RVO.

3. do not pass the object as a parameter to other functions, as the compiler
may 'move' it onto the parameter stack if there are no more references to the
object. If you must pass it as a parameter, pass it by `ref`.

Objects can also be constructed directly into their final destination by
passing them as `out` parameters.

Obviously, I am not familiar with your code and usage patterns. But the above
ought to offer some hope (!) for getting your code working properly. If there
are more pernicious problems with moving that aren't covered by this, please
let me know. Perhaps I can think of a solution.

--

[Issue 18024] checkedint.Abort should be @safe

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

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

Seb  changed:

   What|Removed |Added

Summary|checkedint.Warn should be   |checkedint.Abort should be
   |@safe   |@safe

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

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

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

--- Comment #8 from Walter Bright  ---
(In reply to Walter Bright from comment #7)
> https://github.com/dlang/dmd/pull/7999

For this to work, -dip1000 must be used.

--

[Issue 18519] freebsd 11 + phobos + curl, timing out

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

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

Seb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Seb  ---
REOPENED as I just tested the PR with https://github.com/dlang/phobos/pull/6264
and the problem still seems to be existent.

--

[Issue 18592] Associative array assignment with a destructor should be @safe if the destructor is @safe

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

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

Seb  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 18592] New: Associative array assignment with a destructor should be @safe if the destructor is @safe

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

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

  Issue ID: 18592
   Summary: Associative array assignment with a destructor should
be @safe if the destructor is @safe
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

cat > main.d << EOF
void main() @safe
{
struct ThrowingElement
{
int i;
~this()
{
assert(1);
}
}

ThrowingElement[int] aa;
aa[0] = ThrowingElement(0);
}
EOF


The problem is that the generated opAssign is @system:

ref return @system ThrowingElement opAssign(ThrowingElement p)
{
(ThrowingElement __swap2 = void;) , __swap2 = this , this = p ,
__swap2.~this();
return this;
}

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

--- Comment #6 from Rainer Schuetze  ---
> Adding more @safe Makes it compile and run successfully.

Your safe code also fails with -dip1000. (tried on Windows/OMF).

--

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

I assume you are using Windows?


Yes, I'm the typical lazy convenient Windows user scared of the 
terminal window.



Setup on Posix is really simple.
git clone all three repos + run make.


I am happy for Posix users. Theoretically the process is the same 
on Windows.




There's also a bash script to automate this:

https://github.com/dlang/tools/blob/master/setup.sh


This will need Linux subsystem as a Windows feature installed. 
Bash scripts do not work on Windows. Or other third party 
applications that are not listed as prerequisites on wiki.




From what I heard it's a bit tricky on Windows. I only tried 
with wine and that worked out-of-the-box for me. Execute the 
DMD installer, set PATH, DM_HOME and HOST_DC and then run the 
win32 makefiles work fine.


make -fwin32.mak release
Error: don't know how to make 'release'

Ok, let's skip this, make it without "release".

Now test it:

cd test
make all -j8
Command error: undefined switch '-j8'




What could be done from your perspective to make the setup 
easier?


From my perspective I would like to have an working setup, not 
necessary easier. But if interested, to contribute to C# 
compiler, you just need to open roslyn.sln in Visual Studio, make 
your modification, run the test suite, commit, you're done.

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

--- Comment #5 from Rainer Schuetze  ---
>  This is because 'scope' for delegates now means something with dip1000, it 
> means the delegate must not escape.

There is no "scope" in the test cases. I suspect it is falsely inferred.

--

Re: State of D 2018 Survey

[Seb via Digitalmars-d-announce]

On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote:
About a month ago, Sebastian Wilzbach sent an email out to a 
few of the core D folks asking for feedback on a survey he had 
put together. He thought it would be useful for the Foundation 
to use in order to make decisions about where to expend 
development efforts. Eventually Andrei gave his stamp of 
approval, the survey questions were tweaked, and then it was 
ready to roll.


Of course I would love for you to read my blog post announcing 
it, but if you want to skip the prose and go straight to the 
good stuff, here's the survey link:


https://seb134.typeform.com/to/H1GTak

The blog:
https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/

Reddit:
https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/


Wow, we got more than 500 responses so far. A huge thank you 
already!
The survey is still open for a few more days, so if you want to 
make your opinion count now is the last chance.

[Issue 18549] name gets overwritten in template definition

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

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

Johannes Nordhoff  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Johannes Nordhoff  ---
ah, sorry, i get it. sorry

--

[Issue 18591] New: DMD should allow access to mixin template declarations

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

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

  Issue ID: 18591
   Summary: DMD should allow access to mixin template declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

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

--

[Issue 18549] name gets overwritten in template definition

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

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

Johannes Nordhoff  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Johannes Nordhoff  ---
> > the compiler was using the same name for multiple
> > template-definitions.
>
> I don't understand what you mean by this. If you still think the compiler 
> should do something differently here, please feel free to reopen.
>

yeah, the error message should say:

sth.d(11): Error: sth.tmpl called with argument types () matches both:
sth.d(6): sth.tmpl!(SS).tmpl()
and:
sth.d(7): sth.tmpl!(tt).tmpl()


but instead it says:

sth.d(11): Error: sth.tmpl called with argument types () matches both:
sth.d(6): sth.tmpl!(SS).tmpl()
and:
sth.d(7): sth.tmpl!(SS).tmpl()


--

[Issue 18110] most of phobos should be @safe-ly useable

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

https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18158, which changed state.

Issue 18158 Summary: std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158

   What|Removed |Added

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

--

[Issue 18178] std.path should be usable in @safe

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

https://issues.dlang.org/show_bug.cgi?id=18178
Issue 18178 depends on issue 18158, which changed state.

Issue 18158 Summary: std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158

   What|Removed |Added

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

--

[Issue 18158] std.file.getcwd should be usable in @safe

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

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

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

   What|Removed |Added

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

--

[Issue 18158] std.file.getcwd should be usable in @safe

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

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

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

https://github.com/dlang/phobos/commit/767d1c51d4ae2e24c9d1752db4c1f1b881a3b658
Fix Issue 18158 - std.file.getcwd should be usable in @safe

https://github.com/dlang/phobos/commit/ba11d630a02345fa634d098694273f145fc5428f
Merge pull request #6252 from JackStouffer/issue18158

Fix Issue 18158 - std.file.getcwd should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

[Issue 17819] static foreach segfaults on __traits(allMembers)

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #3 from bitter.ta...@gmx.com ---
There's a stack overflow in Dsymbol's _foreach, every time it recurses into a
AttribDeclaration (such as the `static foreach') the stack gets deeper until it
explodes.

--

Re: Vision document for H1 2018

[Seb via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


Don't forget that "open source" != non-profit. For the C# 
compiler there's a dedicated team of full-time developers.


Also to be fair, the activity on dmd isn't that low either though 
the last week was a one with low-traffic:


https://github.com/dlang/dmd/pulse

Typically ~40 PRs get merged per PR for dmd alone:

https://auto-tester.puremagic.com/chart.ghtml?projectid=1

With druntime + phobos, it's a lot more.

The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


I assume you are using Windows?
Setup on Posix is really simple.
git clone all three repos + run make.

There's also a bash script to automate this:

https://github.com/dlang/tools/blob/master/setup.sh

From what I heard it's a bit tricky on Windows. I only tried with 
wine and that worked out-of-the-box for me. Execute the DMD 
installer, set PATH, DM_HOME and HOST_DC and then run the win32 
makefiles work fine.


What could be done from your perspective to make the setup easier?

[Issue 18126] [internal] Reduce number of turned off warnings.

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Buclaw  ---
This was implemented in https://github.com/dlang/dmd/pull/7958

--

[Issue 18182] std.uri should be usable in @safe

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

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

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

https://github.com/dlang/phobos/commit/9d44d7c13fc312bc39669df441f8b931789471c1
Fix Issue 18182 - std.uri should be usable in @safe

https://github.com/dlang/phobos/commit/8ec15a80ff844bd3457939cb4662952f736e7f50
Merge pull request #6256 from JackStouffer/issue18182

Fix Issue 18182 - std.uri should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18182] std.uri should be usable in @safe

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

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

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

   What|Removed |Added

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

--

[Issue 18110] most of phobos should be @safe-ly useable

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

https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18182, which changed state.

Issue 18182 Summary: std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182

   What|Removed |Added

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

--

Re: Embedded Linux really needs Dlang for the IOT market

[Andrea Fontana via Digitalmars-d]

On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote:

hi all,

I think the D community should make more effort to make Dlang 
more easier to use on embedded Linux(mostly are arm and mips, 
powerpc).



My IOT server works in D. I use it for home heating and also for 
my room lamp.
Single devices (sensor) are written in C but I hope d+better c 
could replace it.

Re: Vision document for H1 2018

[Aravinda VK via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


I contributed to phobos for the first time for the release 
2.079.0. Experience was smooth and also I learnt many new things 
from the review comments. I was able to follow wiki page to 
compile phobos or compile one specific module. Please let us know 
the issue faced, so that wiki can be improved.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last week 
72 pull requests form 24 contributors were merged on ~master. And 
this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is a 
no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh copy 
of dmd or phobos.

Re: Article: Why Const Sucks

[joe via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 15:13:09 UTC, Steven Schveighoffer 
wrote:

On 3/8/18 9:58 AM, joe wrote:
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis 
wrote:

Here's something I wrote up on const:
/snip


May be not entirely related, but a little gotcha.

given:

interface XY {}

class Foo: XY {}
class Bar: XY {}

void doSomething(in XY sth)
{
   auto foo = cast(Foo)sth; // error in @safe code
}

But the compiler doesn't emit a warning that const got cast 
away in @system code.
Since @system is the default setting and casting const away is 
by definition undefined behavior, there should be some 
feedback.


If you cast away const in C++ you need to be explicit about it 
by using const_cast, documents the intention rather than D's 
swiss-army-cast.


This is a problem with the cast system, not const. ...


I figured. Sorry for off topic.


... D has one cast mechanism, and it's used to:

a) dynamic type cast
b) hook user-supplied opCast
c) enter undefined behavior by casting away const/immutable.

I really think we should have a separate mechanism for a and b, 
as they are far less dangerous than c.


std.conv.to does this as well, ...


Thanks for pointing this out.

...but the language should have some safeguards against using 
"safe casting" incorrectly.


-Steve


yes, that's what I was aiming for :)

This one got me because I assumed, with all the improved security 
in place, D would never silently do such a thing...
Assumptions, right? ...the root of all evil. I should know 
better. haha.


Anyways, thanks for the insight and have a nice Sunday.

Re: Inner Classes vs. Inner Structs

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 11, 2018 13:19:39 Mike Franklin via Digitalmars-d-learn 
wrote:
> This works:
>
> ```
> class S {
>  int n, m;
>  int sum() { return n + m; }
>  Inner!(sum) a;
>
>  class Inner(alias f){
>  auto get() {
>  return f();
>  }
>  }
> }
> ```
>
> This doesn't:
>
> ```
> struct S {
>  int n, m;
>  int sum() { return n + m; }
>  Inner!(sum) a;
>
>  struct Inner(alias f){
>  auto get() {
>  return f(); // Error: this for sum needs to be type S
> not type Inner!(sum)
>  }
>  }
> }
> ```
>
> The only difference between the two is one one uses classes, the
> other uses structs.  My question is, under the current semantics
> of D, shouldn't the two work the same?  That is, shouldn't the
> inner struct in the second example have an implicit context
> reference to the outer struct?  Is this a bug?

No, it's on purpose, and the only reason that non-static, nested classes
have access to the class they're declared in is for compatibility with Java,
which doesn't have structs. Also, I suspect that if D were being designed
now, it would treat nested classes the same as nested structs rather than
treating nested structs like it currently does nested classes. Some of D's
design has a number of Java-isms because of when D was first started and the
fact that it didn't have some of features that it has now. Certainly, if we
included the feature at this point if we were redesigning the language, I
expect that it would only be to make porting Java code easier.

Regardless, changing the current behavior would break code, so I doubt that
it's going to change. IIRC, DWT relies on the behavior with classes (since
it's code ported from Java), and while I question that all that much D code
outside of DWT takes advantage of non-static, nested classes, I suspect that
having non-static, nested structs suddenly act differently from static,
nested structs would break a fair bit of D code. There is of course no way
to know how much code would break with either change, but I doubt that
Walter would agree to the potential code breakage in either direction.

- Jonathan M Davis

[Issue 18590] New: nothrow constructor call still type-checks destructor for purity

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

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

  Issue ID: 18590
   Summary: nothrow constructor call still type-checks destructor
for purity
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
extern(C) int printf(const char*, ...);

struct F
{
static F create() pure nothrow
{
return F(1);
}

this(int) pure nothrow
{
}

~this()
{
printf("~this\n");
}
}
CODE
dmd -c bug

Error: pure function 'bug.F.create' cannot call impure function 'bug.F.~this'


Apparently happens because `F(1)` is lowered to `(tmp = F(1)),tmp` internally.
https://github.com/dlang/dmd/blob/93804714c4091a8d867c09ca7b5bf332acb34dfb/src/dmd/expression.d#L3931

--

Re: UFCS in generic libraries, silent hijacking, and compile errors.

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 11, 2018 08:39:54 aliak via Digitalmars-d-learn wrote:
> On Saturday, 10 March 2018 at 23:00:07 UTC, Jonathan M Davis
> > issue in practice. That doesn't mean that it's never a problem,
> > but from what I've seen, it's very rarely a problem, and it's
> > easy to work around if you run into a particular case where it
> > is a problem.
>
> Ya, it's easy to work around but the caveat there is you need to
> realize it's happening first, and add that to that it's "rarely a
> problem" and well ... now it seems scary enough for this to
> mentioned somewhere I'd say.

You're talking about a situation where you used a function whose parameters
match that of a member function exactly enough that a member function gets
called instead of a free function. That _can_ happen, but in most cases,
there's going to be a mismatch, and you'll get a compiler error if the type
defines a member function that matches the free function. I don't think that
I have ever seen that happen or ever seen anyone complain about it. The only
case I recall along those lines was someone who was trying to use a free
function that they'd decided to call front instead of something else, and it
had parameters beyond just the input range, so that programmer got
compilation errors when they tried to use it in their range-based functions.

I think that this is really a theoretical concern and not a practical one.
Certainly, it's really only going to potentially be an issue in library code
that gets used by a ton of folks with completely unexpected types. If it's
in your own code, you're usually well aware of what types are going to be
used with a generic function, and proper testing would catch the rare case
where there would be a problem. If you're really worried about it, then just
don't use UFCS, but for better or worse, it seems to be the case that the
vast majority of D programmers use UFCS all the time and don't run into
problems like this.

> > The one case that I am aware of where best practice is to avoid
> > UFCS is with put for output ranges, but that has nothing to
> > with your concerns here. Rather, it has to do with the fact
> > that std.range.primitives.put has a lot of overloads for
> > handling various arguments (particularly when handling ranges
> > of characters), and almost no one implements their output
> > ranges with all of those overloads. So, if you use put with
> > UFCS, you tend to run into problems if you do anything other
> > than put a single element of the exact type at a time, whereas
> > the free function handles more cases (even if they ultimately
> > end up calling that member function with a single argument of
> > the exact type). We probably shouldn't have had the free
> > function and the member function share the same name.
>
> Oh, can you share a short example here maybe? Not sure I followed
> completely
>
> Is it basically:
>
> // if r is output range
>
> r.put(a, b) // don't do this?
>
> put(r, a, b) // but do this?
>
> (Cause compilation error)

Essentially yes, though you're passing too many arguments to put. There are
cases where put(output, foo) will compile while output.put(foo) will not. In
particular, std.range.primitives.put will accept both individual elements to
be written to the output range and ranges of elements to be written, whereas
typically, an output range will be written to only accept an element at a
time. It's even more extreme with output ranges of characters, because the
free function put will accept different string types and convert them, and
even if the programmer who designed the output range added various overloads
to put for completeness, it's enough extra work to deal with all of the
various character types that they probably didn't. And put also works with
stuff like delegates (most frequently used with a toString that accepts an
output range), which don't have member functions. So, if you write your
generic code to use the member function put, it's only going to work with
user-defined types that define the particular overload(s) of put that you're
using in your function, whereas if you use the free function, you have more
variety in the types of output ranges that your code works with, and you
have more ways that you can call put (e.g. passing a range of elements
instead of a single element).

> How about if it's not part of the overload set, but is looked up
> if the function does not exist in the overload set. What would
> the problems there be?
>
> Basically I don't see a reason why we wouldn't want the following
> to work:
>
> struct S { void f() {} }
> void f(S s, int i) {}
> S().f(3); // error

So, are you complaining that it's an error, or you want it to be an error?
As it stands, it's an error, because as far as the compiler is concerned,
you tried to call a member function with an argument that it doesn't accept.

If you want that code to work, then it would have to add the free function
to the overload set while somehow leaving out the overloads 

Re: D for microservices

[Jacob Carlborg via Digitalmars-d]

On 2018-03-11 12:10, Tamas wrote:


Simple Vibe.d app talking to Redis, packed into docker containers:
https://github.com/tam4s/hello-redis

The takeaway is that I could not use Alpine as a host image, because I 
could not build the app statically on ubuntu.


warning: Using 'dlopen' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking


It's just a warning. If you're not using "dlopen" or any of your 
dependencies you can just ignore the warning.


--
/Jacob Carlborg

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:


I am sure that lots of D members will be quick to point out, 
that C# is run by a commercial company and D has only open 
source contributors. Now why did you not contribute! /sarcasm




I'd like to point out, that C# is run by a commercial company and 
D has only open source contributors.


For that matter, so is Rust (a 1/2 billion $ organisation, at 
least), run by sjw's who will 'attack' (as opposed to 'point 
out') anyone that speaks out against anything. As for cross 
platform, have you tried running Rust in Windows XP?


Anyway.. I'm going back to the sandbox, to play with my own toys.

[Issue 18537] Cannot pass absolute path to coverage options

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

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

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

https://github.com/dlang/druntime/commit/feb6e9b2f035f2b564765120e6fb794abfd53622
fix Issue 18537 - Cannot pass absolute path to coverage options

allow DRT arguments to include '=' or ':', splitting is done by ' '

https://github.com/dlang/druntime/commit/ab14e9af2b9f4bbea00d543fe229047ede4dd909
Merge pull request #2120 from rainers/issue18537

fix Issue 18537 - Cannot pass absolute path to coverage options

--

Re: Vision document for H1 2018

[bachmeier via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:

With the usual response here: "Why do you not fix it yourself 
or pay for it". Maybe because most people who come want to use 
the tools and be productive and not spend their time fixing up 
those tools.


I've never seen anyone write that. Most likely you saw someone 
post something that looks similar, but has a dramatically 
different meaning. The usual response is "If you want something 
done, you're going to have to do it yourself or pay someone to do 
it for you, or else it won't get done."


Its a mentality issue that some do not get here. In order to 
grow you need consumers for your product. If you force or whine 
to them to fix the issues, they leave. When they leave you lose 
potential growth. That loss in growth means losing potential 
members that can fix and want to fix the issues.


And this clarifies the source of your confusion. The D 
programming language is an open source project, not a for-profit 
company. D is not the language you're looking for.

Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux

[Pjotr Prins via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 12:41:28 UTC, Johan Engelen wrote:
Kai has been working recently [1] on updating LDC 0.17.x 
(ltsmaster) to work with LLVM 6, PowerPC, AArch64, ...  You may 
want to take advantage of that activity to get better bootstrap 
compiler support for your platforms. For example by filing bug 
reports, or better: helping out with testing and fixing things 
;-)


Sure thing. Guix can support multiple versions of LLVM and build 
against those, so you can inject different dependencies (read 
versions of LLVM) in the dependency graph. I am quite keen to use 
the latest for my tools.

Re: How do you call an eponymous template that has a secondary template arg?

[Basile B. via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 12:05:56 UTC, aliak wrote:

Eg:

template aliasOf(T) {
enum aliasOf(alias a) = is(typeof(a) == T);
}

The use case for this is for std.meta.allSatisfy for variadic 
args, i.e.


template T(values...) if (allSatisfy!(aliasOf!string, values) { 
... }


But how do you call that template otherwise?

I've tries:

* aliasOf!int!"string" // multiple ! arguments are not allowed
* (aliasOf!int)!"string" // error c-style cast
* aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) 
does not have property 'isAliasOf


I can work around this by:

template typeOf(T) {
enum isAliasedBy(alias a) = is(typeof(a) == T);
}

and then do:

template T(values...) if 
(allSatisfy!(typeOf!string.isAliasedBy, values) { ... }


But I like the readability of the former better if there's a 
way to achieve it?


Cheers
- Ali


The first version works here:

```
template aliasOf(T) {
enum aliasOf(alias a) = is(typeof(a) == T);
}

string s;

pragma(msg, allSatisfy!(aliasOf!string, s, "string"));
```

Now on the fact that what is done is correct is another story.
If the literal passed is supposed to be a type then it's clearly 
wrong.

You'd have to mix it:

```
template aliasOf(T)
{
template aliasOf(alias a)
{
mixin("alias A = " ~ a ~ ";");
enum aliasOf = is(A == T);
}
}

alias myString1 = string;
alias myString2 = string;

pragma(msg, allSatisfy!(aliasOf!string, "myString1", 
"myString2"));

```

Re: Vision document for H1 2018

[R via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.


Most people do not have issues with the core language of D. You 
can come from any of the above mentioned languages ( like C, C++, 
Rust, PHP, Python, Nim, ... ) and get going with D. That is what 
attracted me in the first place. The language looks good but the 
moment you actually start using D its issue after issue.


With the usual response here: "Why do you not fix it yourself or 
pay for it". Maybe because most people who come want to use the 
tools and be productive and not spend their time fixing up those 
tools.


Its a mentality issue that some do not get here. In order to grow 
you need consumers for your product. If you force or whine to 
them to fix the issues, they leave. When they leave you lose 
potential growth. That loss in growth means losing potential 
members that can fix and want to fix the issues.


One can call it selfish but every language is based upon this 
principle. No growth and community of lots of selfish users means 
no other members to fix the issues. It is the 9 Circles of Hell.


I suppose that every C# programmer is enthusiastic on the first 
contact with the D language, but fails to keep his enthusiasm 
when he sees Phobos. C# programmer's mind is locked in the OOP 
world and Phobos looks like a mess from his point of view.


+1!

It has the language mostly right but its everything around it 
that is simply a mess. When one compares that to Rust. They are 
not having constant discussion about replacing cargo ( as dub in 
D has issues ). They do not need to have multiple documentation 
generators. The cross platform is simple and fast. Same applies 
to Go. And C# ... Resources simple are more focused and enhance 
the whole platform as such. D is like a children sandbox where 
everybody is playing with their own toys. So when other complain 
about the mess of the playground, the responds by some is just as 
typical.



The problem is that D stagnates and in the same time C# evolves.


I am sure that lots of D members will be quick to point out, that 
C# is run by a commercial company and D has only open source 
contributors. Now why did you not contribute! /sarcasm


Sometimes I feel like the C# language team is using D as 
inspiration for the new features, starting with C# 7.0, a lot 
of D concepts were introduced in the language: local functions, 
'_' as digit separator, binary literals, ref returns, tuples, 
templates, immutability. Guess what the next version of C# has 
on the table: slices.


Yep ... Things are moving faster in the .net camp thanks to the 
focus on .net Core and the RyuJit.


Here is a fun one, with Blazer now being part of the official 
.net.


https://github.com/aspnet/blazor

Blazer = C# code runable in the browser using WebAssembly.

In the same time, D delegates new features (and sometime 
existing ones) to library implementation, instead of assume 
them in the language syntax.


My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


Personally i am waiting to see CoreRT finalized:

https://github.com/dotnet/corert

-> CppCodeGen/C++
-> RyuJIT codegen
-> Webasm

Its already working and getting better by the day.

Other languages are moving forwards at blazing speeds and D seems 
to put it priorities on adding new exiting features. Where as a 
large part of the outcry is the issues with the library, lacking 
editors support, cross platform issues, ...

Re: Forwarding arguments through a std.algorithm.map

[Stefan Koch via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 20:48:06 UTC, Nordlöw wrote:

If I have a function

bool f(Rs...)(Rs rs)

is it somehow possible to map and forward all its arguments 
`rs` to another function


bool g(Rs...)(Rs rs);

through a call to some map-and-forward-like-function 
`forwardMap` in something like


bool f(Rs...)(Rs rs)
{
alias someArbitraryFun = _ => _;
return g(forwardMap!(someArbitraryFun)(rs));
}

?

What should the definition of forwardMap look like?

Does Phobos contain something like this already?


there is staticMap.

Inner Classes vs. Inner Structs

[Mike Franklin via Digitalmars-d-learn]

This works:

```
class S {
int n, m;
int sum() { return n + m; }
Inner!(sum) a;

class Inner(alias f){
auto get() {
return f();
}
}
}
```

This doesn't:

```
struct S {
int n, m;
int sum() { return n + m; }
Inner!(sum) a;

struct Inner(alias f){
auto get() {
return f(); // Error: this for sum needs to be type S 
not type Inner!(sum)

}
}
}
```

The only difference between the two is one one uses classes, the 
other uses structs.  My question is, under the current semantics 
of D, shouldn't the two work the same?  That is, shouldn't the 
inner struct in the second example have an implicit context 
reference to the outer struct?  Is this a bug?


Thanks for the help,
Mike

[Issue 18519] freebsd 11 + phobos + curl, timing out

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

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

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

https://github.com/dlang/phobos/commit/b8e5bca94b661c1d1ffb9ec6f7e37b9fa7a0d09d
fix issue 18519 freebsd 11 + phobos + curl, timing out

stop the TestServer waiting in accept() before thread_joinall

https://github.com/dlang/phobos/commit/35e9807bbec392658ecdc8b4ed93d1f6c02f2845
Merge pull request #6234 from rainers/curl_freeze

fix issue 18519 freebsd 11 + phobos + curl, timing out
merged-on-behalf-of: Petar Kirov 

--

Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux

[Johan Engelen via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 08:43:25 UTC, Pjotr Prins wrote:
The GNU package manager updated LDC to 1.7.0 which now provides 
x86_64-linux, see 
https://www.gnu.org/software/guix/packages/L/. Runtime 
dependencies and build are listed at 
https://hydra.gnu.org/build/2525193#tabs-runtime-deps, 
including 0.17.4 (bootstrap) and LLVM 3.8.1.


LDC 0.17.4 provides x86_64-linux, i686-linux, armhf-linux.

We aim to add D compilers for all supported architectures.


Kai has been working recently [1] on updating LDC 0.17.x 
(ltsmaster) to work with LLVM 6, PowerPC, AArch64, ...  You may 
want to take advantage of that activity to get better bootstrap 
compiler support for your platforms. For example by filing bug 
reports, or better: helping out with testing and fixing things ;-)


-Johan

[1] See e.g. 
https://github.com/ldc-developers/dmd-testsuite/pull/34

Re: Error compiling with DUB (dmd) since yesterday dub update

[Seb via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 07:17:58 UTC, Mario wrote:
On Sunday, 11 March 2018 at 07:11:09 UTC, rikki cattermole 
wrote:

On 11/03/2018 8:02 PM, Mario wrote:
On Sunday, 11 March 2018 at 06:59:32 UTC, rikki cattermole 
wrote:

On 11/03/2018 7:55 PM, Mario wrote:

[...]


Are you aware that it is compiling with ldc?


Actually, I didn't even realize XD. I'm a newbie in VibeD and 
DLang, should I change it? Why did compiling work yesterday?


Thanks in advance


Workaround switch to dmd.
Real solution please file a bug for Botan and attach your log 
in.


Thank you, I followed your advice and I created an issue on the 
GitHub project: https://github.com/etcimon/botan/issues/42


Or simply use the built-in openssl 1.1?

How do you call an eponymous template that has a secondary template arg?

[aliak via Digitalmars-d-learn]

Eg:

template aliasOf(T) {
enum aliasOf(alias a) = is(typeof(a) == T);
}

The use case for this is for std.meta.allSatisfy for variadic 
args, i.e.


template T(values...) if (allSatisfy!(aliasOf!string, values) { 
... }


But how do you call that template otherwise?

I've tries:

* aliasOf!int!"string" // multiple ! arguments are not allowed
* (aliasOf!int)!"string" // error c-style cast
* aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) 
does not have property 'isAliasOf


I can work around this by:

template typeOf(T) {
enum isAliasedBy(alias a) = is(typeof(a) == T);
}

and then do:

template T(values...) if (allSatisfy!(typeOf!string.isAliasedBy, 
values) { ... }


But I like the readability of the former better if there's a way 
to achieve it?


Cheers
- Ali

Re: Forwarding arguments through a std.algorithm.map

[Seb via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 20:48:06 UTC, Nordlöw wrote:

If I have a function

bool f(Rs...)(Rs rs)

is it somehow possible to map and forward all its arguments 
`rs` to another function


bool g(Rs...)(Rs rs);

through a call to some map-and-forward-like-function 
`forwardMap` in something like


bool f(Rs...)(Rs rs)
{
alias someArbitraryFun = _ => _;
return g(forwardMap!(someArbitraryFun)(rs));
}

?

What should the definition of forwardMap look like?

Does Phobos contain something like this already?


Not sure whether I understand what you are looking for, but 
std.functional is your friend here I think pipe/compose is the 
function you are searching for.


https://dlang.org/phobos/std_functional.html#forward
https://dlang.org/phobos/std_functional.html#partial
https://dlang.org/phobos/std_functional.html#pipe

Re: C++ launched its community survey, too

[Dmitry Olshansky via Digitalmars-d]

On Sunday, 11 March 2018 at 02:21:30 UTC, Laeeth Isharc wrote:

On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
It would be nice if you could actually just copy-n-paste a C 
header into an extern(C) block in D and have it Just Work(tm), 
but practically all C headers are dependent on macros one way 
or another that it would require including an entire C 
processor inside the D compiler, which is not exactly an 
inviting proposition.


Watch this space...


And we have warp which is a C preprocessor written in D, just 
saying ;)

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

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

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

--- Comment #34 from Eyal  ---
Walter: Thanks, the RVO fixes are very useful and important - and will be part
of any future solution we have!

--

Re: D for microservices

[Tamas via Digitalmars-d]

On Thursday, 8 March 2018 at 22:53:11 UTC, aberba wrote:

On Thursday, 8 March 2018 at 09:35:08 UTC, Andrew Benton wrote:
On Thursday, 8 March 2018 at 07:54:29 UTC, Jacob Carlborg 
wrote:

On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote:

This guys says that vide.d works 
https://forum.dlang.org/thread/gikoeutmdyvolfshp...@forum.dlang.org


Yes, it's pretty straightforward:

1. Build on Ubuntu, or some other dist
2. Statically link the whole binary with LDC, then you don't 
need to use Musl

3. Run it on Alpine

--
/Jacob Carlborg


Looks like that works out much nicer than using alpine as the 
first stage right now.  I'm not sure anyone will be too upset 
about the extra 7MB.


Building directly in alpine will simplify automated builds too.


Simple Vibe.d app talking to Redis, packed into docker containers:
https://github.com/tam4s/hello-redis

The takeaway is that I could not use Alpine as a host image, 
because I could not build the app statically on ubuntu.


warning: Using 'dlopen' in statically linked applications 
requires at runtime the shared libraries from the glibc version 
used for linking

[Issue 18547] Win32: throwing exception in fiber crashes application

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

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

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

https://github.com/dlang/druntime/commit/a1a5ad8d70464534228839ad8f1f2a7938cb9524
fix issue 18547 - Win32: throwing exception in fiber crashes application

increase the default stack size because exception handling might need up to
16k. The actually used stack can depend on the version of DbgHelp.dll, the
existence of debug information and possibly other conditions.

https://github.com/dlang/druntime/commit/86cd40a036a67d9b1bff6c14e91cba1e5557b119
Merge pull request #2129 from rainers/issue18547

fix issue 18547 - Win32: throwing exception in fiber crashes application
merged-on-behalf-of: Petar Kirov 

--