[Issue 15485] switch with no case compiles

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org
 Resolution|INVALID |FIXED

--- Comment #3 from Iain Buclaw  ---
Don't even need to bother raising a bug in gdc (by the way this is fixed, not
invalid).

--

Re: [Semi-OT] I don't want to leave this language!

[ketmar via Digitalmars-d-learn]

On Wednesday, 7 December 2016 at 02:38:50 UTC, bpr wrote:
It's a counterfactual at this point, but I would guess that if 
D had left out the GC in 2010 when D2 came out it would have 
been ahead of C++ in many ways and perhaps would have been able 
to peel off more C++ programmers


c++ programmers want c++. anything that is not c++ will be bashed 
to death. there is absolutely no reason to kill one of the key D 
features only to attract 2.5 c++ coders. actually, we already 
have That One C++ Programmer We Need onboard -- Andrei. ;-)

Re: Should we warn if we detect null derefernces or void value uses ?

[ketmar via Digitalmars-d]

On Wednesday, 7 December 2016 at 06:47:56 UTC, burjui wrote:
Yes, but we should issue an error, like Andrei said. A language 
is only as useful as it's best implementation, so diagnostics 
like that are essential. Data-flow analysis shouldn't even be 
optional or lacking in any modern compiler.


you know, D has variable initialization with default values. that 
allows to skip DFA, and still be sure that variable is 
initialized.


also, that thing can be done in *backend*, if it is really 
necessary, along with eliminating needless loads. such 
warning/error absolutely unnecessary in frontend, it only adds 
more code to maintain, and slows down compiling.

[Issue 16047] Range violation in setting multi-dimensional AA entries

[via Digitalmars-d-bugs]

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

MichaelZ  changed:

   What|Removed |Added

 CC||dlang@bregalad.de

--

Re: Should we warn if we detect null derefernces or void value uses ?

[burjui via Digitalmars-d]

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:

Hi Guys,
What is your opinion, should we warn if we unambiguously detect 
something that is clearly unwanted ?


int fn(int y)
{
  int x = void;
  ++x;
  return x+y;
}

 This requires data-flow analysis (The same kind that tells you 
if you are skipping a statement)
And will slow down compilation a little if we enable such a 
warning.


Yes, but we should issue an error, like Andrei said. A language 
is only as useful as it's best implementation, so diagnostics 
like that are essential. Data-flow analysis shouldn't even be 
optional or lacking in any modern compiler.

Re: How about a bounty for a new windows installer using inno setup ?

[Thomas Mader via Digitalmars-d]

On Tuesday, 6 December 2016 at 17:28:25 UTC, Jim Hewes wrote:

On 12/6/2016 12:21 AM, Thomas Mader wrote:


You can also create a WiX installer out of an InnoSetup 
installer.
I think it's more important to decide upon the feature set, 
readability

and the time needed to build an installer.
Have you experience with both? I only have experience with 
NSIS and
InnoSetup and in InnoSetup the feature set for Windows is 
really good

and the readability is good.


I started out by using InstallShield some years ago and got 
battle scars there. I don't recommend that. I used NSIS a 
little because a company we partnered with required it but I'm 
no authority on NSIS or Inno.


It really depends on how complicated your particular install is 
and where you expect it to go in the future. If you're just 
copying a few files then anything will work. I don't mean to 
make too big a deal out of it if the requirements are really 
simple.


Personally I think it's better in the long run to generate an 
MSI for several reasons you can probably look up 
yourself---security, ability to rollback (installation is a 
transaction), appears in Programs and Features, transforms, etc.


I wouldn't advise doing the coding part externally in D this 
makes
things much more complicated than it should be. Stick with 
what's

supported by the tool.


I'm not suggesting you necessarily use D together with 
something like NSIS. But you do want to have a one-button 
automated build process, not just for convenience but for 
repeatability. That's important. Soon you will want to get away 
from the tool's own GUI and run things programmatically.


After having not-so-good experiences with InstallShield I 
looked at things like SCons and msbuild, which was just coming 
out at the time. (This was a while ago). I tried msbuild but it 
didn't have modules to support many of the things I needed to 
do. Things like code-signing with a verisign signature, 
injecting data and files into exe resources, etc. Fortunately 
you can build your own custom modules using C# which is what I 
tried. But the process of transferring variables back and forth 
from the script to C# for every custom module was painful and I 
thought, "if I just do this all in C# it will be much easier". 
So I switched. I used C# not only to call on the WiX tools to 
run them, but to easily manipulate pathname and filename 
strings, which were different because I needed to build 
different configurations for different customer companies. And 
I also needed to build different combinations of language 
localization. I could use .NET to build a nice GUI for 
selecting configurations, and C# to call the Windows API when 
needed, move files around, anything.


You may also run into issues when you need to do complicated 
updates and there are already earlier versions in the field. 
You may want to remove features, but your installer has to both 
update existing users in addition to supporting new users. It's 
hard to predict the future though so I won't say much about it 
except that it helps to have a more powerful tool when you run 
into such situations.


The scripting-type tools are tempting because they're easy and 
no one wants to spend any time on installers. It's usually 
something that people hope to just slap on at the end and it 
often gets underestimated. But as I said, maybe it IS easy if 
you're just copying files and you will only ever have one 
configuration. So it depends.


Jim


Nice writeup.
In our company we used NSIS and are switching over to InnoSetup. 
Most of the work is already done, just a few apps need to be 
moved.
I think no one really wants NSIS because of readability issues. 
It's assembler like language is too low level and many common 
functions are just missing.


InnoSetup on the other hand gives you everything you could ever 
want. I never missed a thing because pretty much everything is 
right there and if you happen to have very special needs you can 
do it quite nicely with the pascal scripting ability. You can 
call every Windows API function you just need to wrap it if it is 
not provided in one way or another via the InnoSetup API.

I don't think you need to do that for the D Installer though.

Our installers need to handle quite a few things.
- Signing and timestamping of exes, dlls, Installer and 
Uninstaller
- SendTo Handler registration (Windows doesn't provide a common 
SendTo directory so you need to handle it quite complicated for 
each users individual SendTo directory if you don't want to write 
a proper SendTo COM thing)

- Registration of a COM server
- Differentiate between 32 and 64 bit installs
- User elevation for Installs and Uninstalls but Updates are done 
for the current User (We still use Inno for our Updates too but 
move away from that because it's not at all transactional and 
cannot be undone in the middle of the update)

- Create MSI Installer from InnoSetup Installer via Wix

The update case could be better supported 

Re: [Semi-OT] I don't want to leave this language!

[Picaud Vincent via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:
So, while there are certainly folks who would prefer using D as 
a better C without druntime or Phobos, I think that you're 
seriously overestimating how many folks would be interested in 
that. Certainly, all of the C++ programmers that I've worked 
with professionally would have _zero_ interest in D as a better 
C.


- Jonathan M Davis


Considering scientific/numerical applications, I do agree with 
Ilya: it is mandatory to have zero overhead and a 
straightforward/direct interoperability with C. I am impressed by 
the Mir lib results and I think "BetterC" is very 
attractive/important.


-- Vincent

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 December 2016 at 23:55:06 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:

Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.


Sounds like you have your concat implementation right there ;)


not really, concat needs to be smart about allocation and memory 
reuse.

when used on char arrays the memory access will be different.
and use more instructions.

Re: DMD 2.072.1 MSVC build seems to be failing

[Walter Bright via Digitalmars-d]

On 12/6/2016 7:38 PM, Lewis wrote:

On Wednesday, 7 December 2016 at 02:49:14 UTC, Walter Bright wrote:

Those files were converted to glue.d, etc., but obviously the VS build was not
updated. Please file a bugzilla issue for it.


Done, thanks!

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



Good! Next, you can also file a PR to fix it! Should be pretty simple.

[Issue 16949] [Reg 2.073] confusing @safe error message for fields with unsafe destructors

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #1 from Walter Bright  ---
Already fixed:

C:\cbx\bug>..\dmd test7 -transition=safe
test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system
destructor 'test7.A.~this'

C:\cbx\bug>..\dmd test7
test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system
destructor 'test7.A.~this'

--

[Issue 13314] BinaryHeap assumes Store has dup property

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/fba056a8df961138859561a6f4ea3d9447efbd6d
fix issue 13314

https://github.com/dlang/phobos/commit/9eb35e11b39ed54fea8b6f4fc18503c86bddc05a
Merge pull request #4929 from somzzz/issue_13314

fix issue 13314  - BinaryHeap assumes Store has dup property

--

Re: DMD 2.072.1 MSVC build seems to be failing

[Lewis via Digitalmars-d]

On Wednesday, 7 December 2016 at 02:49:14 UTC, Walter Bright 
wrote:
Those files were converted to glue.d, etc., but obviously the 
VS build was not updated. Please file a bugzilla issue for it.


Done, thanks!

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

[Issue 16954] New: MSVC build fails on DMD 2.072.1 release

[via Digitalmars-d-bugs]

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

  Issue ID: 16954
   Summary: MSVC build fails on DMD 2.072.1 release
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: musicalje...@gmail.com

I downloaded and installed a fresh copy of DMD 2.072.1, opened
dmd2/dmd/vcbuild/dmd.sln, and tried to build. I got several compilation errors
related to missing files, in particular:

1>c1xx : fatal error C1083: Cannot open source file: '..\glue.c': No such file
or directory
1>c1xx : fatal error C1083: Cannot open source file: '..\msc.c': No such file
or directory
1>c1xx : fatal error C1083: Cannot open source file: '..\toir.c': No such file
or directory

According to Walter in
https://forum.dlang.org/post/odrwelyfjvhysggee...@forum.dlang.org some files in
the build have been translated to .d files, but the VS build probably hasn't
been updated accordingly.

--

Re: [Semi-OT] I don't want to leave this language!

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, December 07, 2016 02:38:50 bpr via Digitalmars-d-learn wrote:
> On Tuesday, 6 December 2016 at 22:47:34 UTC, Jonathan M Davis
> > We get plenty of folks who aren't big C/C++ programmers who are
> > interested in D. Yes, the majority seem to have a C++
> > background, but we also get folks from C#, python, ruby, etc.
>
> It would be nice to see a breakdown. From where I sit, it appears
> that most of the interest in D is from C++ users, and it doesn't
> appear that D popularity is rising so much. Any data that belies
> that sad assessment?

As I understand it, the downloads have been increasing year over year. At
least some years, Andrei has given some statistics on the state of D in his
dconf talk. And per his stats, forum/newsgroup activity was going up too,
though I get the impression that at least in the main newsgroup, it may have
actually dropped off (whereas Learn seems like it's been growing). That's
just my impression though. I'm sure github activity has gone up over time
though.

It's my understanding that D's usage has continued to grow but that it isn't
growing super fast, whereas languages such as Go and Rust do seem to have
grown very quickly (probably at least in part due to the companies behind
them). But other languages have taken a long time to catch on and still
ended up being very successful with large user bases (e.g. that's what
happened with python).

It's also hard to gauge how much D is really being used. The number of
companies saying that they're using D seems to have increased, but there are
who-knows how many folks using D who haven't said anything, and we really
don't have much to go on besides the downloads, which only capture a portion
of the D's users and even then only tells you how often dmd was downloaded,
not how many people it was or if they're new users or whatnot. And
downloading dmd from dlang.org is not the only way to get it.

There are definitely things that we can be and should be doing to improve
D's traction (like better supporting @nogc in Phobos), but I don't think
that we're doing badly. And often, the problem seems to be more of a PR one
than anything technical (e.g. I think that we're finally pretty much beyond
the issues caused by the confusion over Tango vs Phobos in D1, but it took a
long time). And honestly, much as there are technical problems related to
the GC, the far bigger problem seems to be the PR issues related to it.
Sadly, the simple fact that we _have_ a GC has been a PR problem, regardless
of the actual state of things. But regardless, we do seem to be gaining
traction, even if it's not as quickly as we might like.

- Jonathan M Davis

Re: [Semi-OT] I don't want to leave this language!

[bachmeier via Digitalmars-d-learn]

On Wednesday, 7 December 2016 at 02:24:56 UTC, bpr wrote:
If I really *want* to use a GC, say I'm writing a server and I 
believe that a well tuned GC will allow my server to stay alive 
much longer with less fragmentation, I'll probably skip D and 
pick Go or maybe (hmmm...) even Java because their GCs have had 
a lot of engineering effort.




Writing a server is quite narrow compared to the "programmers who 
are comfortable working in a GC-ed language" that I was 
responding to.


I wonder what percentage of Ruby programmers have thought 
about garbage collection ever.


Why would a Ruby or Python programmer unconcerned with 
performance want to switch to D? I'm sure there are some who 
would, but I'd imagine they're rare.


Maybe some prefer D as a language? The same argument could be 
used against any language. Performance is far from the only 
reason to use D.

Re: DMD 2.072.1 MSVC build seems to be failing

[Walter Bright via Digitalmars-d]

On 12/6/2016 6:15 PM, Lewis wrote:

I like to build DMD with MSVC because it complies a little faster than the
shipped executable. I downloaded and installed a fresh copy of DMD 2.072.1,
opened dmd2/dmd/vcbuild/dmd.sln, and tried to build. I got several compilation
errors related to missing files, in particular:

1>c1xx : fatal error C1083: Cannot open source file: '..\glue.c': No such file
or directory
1>c1xx : fatal error C1083: Cannot open source file: '..\msc.c': No such file or
directory
1>c1xx : fatal error C1083: Cannot open source file: '..\toir.c': No such file
or directory

I tried fiddling a bit with removing these files from the project, and I could
get the first stage of the build to pass, but then I ran into linker errors
later on. I don't know enough about how this project is set up, so I figured I'd
just ask.

Any ideas what's going on? Did the VS project simply not get updated for the new
release, or am I missing something in my build procedure? I can build my old
installation of 2.071.0 without issue.


Those files were converted to glue.d, etc., but obviously the VS build was not 
updated. Please file a bugzilla issue for it.

Re: [Semi-OT] I don't want to leave this language!

[bpr via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 22:47:34 UTC, Jonathan M Davis 
wrote:
On Tuesday, December 06, 2016 22:13:54 bpr via 
Digitalmars-d-learn wrote:

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis

wrote:
Sure, there are folks who would prefer not to have to deal with 
the GC but throw out the runtime and std lib? You lose out on 
too much for it to be at all worth it for many folks. At that 
point, C++11/14/17 looks far more appealing, especially as it 
continues to improve.


It's a counterfactual at this point, but I would guess that if D 
had left out the GC in 2010 when D2 came out it would have been 
ahead of C++ in many ways and perhaps would have been able to 
peel off more C++ programmers and achieve the momentum that Rust 
appears to have now. Yes, it would be missing some features on 
account of omitting GC, but D2 -GC in 2010 is still much better 
than C++ 2011. As C++ absorbs D features, the case for D seems 
weaker.


We get plenty of folks who aren't big C/C++ programmers who are 
interested in D. Yes, the majority seem to have a C++ 
background, but we also get folks from C#, python, ruby, etc.


It would be nice to see a breakdown. From where I sit, it appears 
that most of the interest in D is from C++ users, and it doesn't 
appear that D popularity is rising so much. Any data that belies 
that sad assessment?

Re: [Semi-OT] I don't want to leave this language!

[bpr via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 22:23:25 UTC, bachmeier wrote:

On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
Those programmers who are comfortable working in a GC-ed 
language will likely eschew D because D's GC is really not 
that great.


So someone working with Ruby is not going to want to work with 
D because of GC performance?


Ruby programmers are probably not concerned with performance at 
all ever. It's a slow interpreted language with a GIL. But if 
you're on a Rails project, that's what you'll use.


If I really *want* to use a GC, say I'm writing a server and I 
believe that a well tuned GC will allow my server to stay alive 
much longer with less fragmentation, I'll probably skip D and 
pick Go or maybe (hmmm...) even Java because their GCs have had a 
lot of engineering effort.


I wonder what percentage of Ruby programmers have thought about 
garbage collection ever.


Why would a Ruby or Python programmer unconcerned with 
performance want to switch to D? I'm sure there are some who 
would, but I'd imagine they're rare.

DMD 2.072.1 MSVC build seems to be failing

[Lewis via Digitalmars-d]

I like to build DMD with MSVC because it complies a little faster 
than the shipped executable. I downloaded and installed a fresh 
copy of DMD 2.072.1, opened dmd2/dmd/vcbuild/dmd.sln, and tried 
to build. I got several compilation errors related to missing 
files, in particular:


1>c1xx : fatal error C1083: Cannot open source file: '..\glue.c': 
No such file or directory
1>c1xx : fatal error C1083: Cannot open source file: '..\msc.c': 
No such file or directory
1>c1xx : fatal error C1083: Cannot open source file: '..\toir.c': 
No such file or directory


I tried fiddling a bit with removing these files from the 
project, and I could get the first stage of the build to pass, 
but then I ran into linker errors later on. I don't know enough 
about how this project is set up, so I figured I'd just ask.


Any ideas what's going on? Did the VS project simply not get 
updated for the new release, or am I missing something in my 
build procedure? I can build my old installation of 2.071.0 
without issue.


Thanks!

Re: Large .init for class containing void-initialized struct

[Basile B. via Digitalmars-d]

On Wednesday, 7 December 2016 at 00:20:11 UTC, Ali Çehreli wrote:

tl;dr; go to the TLDR section below. :)

[...]

struct S {
int i = void;
double d = void;
ubyte[10_000] a = void;
}

class C {
S s = void; // (Same result even without the =void)
}

void main() {
}

[...]
04446260 3633 T 
_D4core4time8Duration13_toStringImplMxFNaNbNfZAya

04505140 3707 T _d_arraysetlengthiT
06681456 00010032 V _D6deneme1C6__initZ

Now we have a 10032 byte C.init.

Is there a rationale for this or is this an implementation 
quality issue? Is there a bug already? I could not find one.


Also, I failed to find the "= void" documentation e.g. not on 
the struct spec page.


Thank you,
Ali


Non initialized classes just don't work. Because of the hidden 
classes fields an initializer is **always** needed. What happens 
in your example is that the initializer size is sub optimal.


A naive make without emplace():


import std.traits, std.c.stdlib;

CT make(CT, A...)(A a)
{
auto memory = malloc(__traits(classInstanceSize, CT));
version(none) 
emplace!Foo(memory[0..__traits(classInstanceSize, CT)]);

static if (__traits(hasMember, CT, "__ctor"))
(cast(CT) (memory)).__ctor(a);
return cast(CT) memory;
}

class Foo{void foo(){}}

void main()
{
Foo foo = make!Foo;
foo.foo;
}


crashes with a segfault

[Issue 15485] switch with no case compiles

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Krejcirik  ---
This has been an error in dmd since 2.068. GDC bugs should be reported to
https://bugzilla.gdcproject.org/

--

Re: [Semi-OT] I don't want to leave this language!

[Timothee Cour via Digitalmars-d-learn]

My 2 cents: for most applications, hotspots tend to be in a tiny percentage
of the code (ie 90/10 rule where 10% of code accounts for 90% execution
time, although my experience in large projects is even more unbalanced) ;
throwing away druntime or GC for the whole codebase based on performance
concerns amounts to (evil) early optimization.

It's far more productive to use a profiler and carefully optimize only the
parts that need to be (possibly using betterc, @nogc, ldc and optimized
compiler flags for those hotspots only).

What could be done better would be to remove friction when linking in
shared objects produced by dmd and ldc (eg, extern(D) functions have
different number of underscores in dmd vs ldc).

On that note, even if dmd is 50x slower than ldc for certain blas mir
routines, it's still valuable to have mir supported by dmd as we can always
swap in the slow parts during production runs, but we'd benefit with fast
compile time during development time,



On Tue, Dec 6, 2016 at 3:08 PM, aberba via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
>
>> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis
>>
>
> I would guess that the vast majority of interest shown in Rust is from
>> people who essentially want a better C or C++, with no runtime/GC. So, I
>> think Ilya's point is very plausible. D with no GC, but with modules,
>> templates, overloading, CTFE, and some other features might have been more
>> tempting to the no-GC crowd, which includes many hardcore C++ programmers.
>>
>> Those programmers who are comfortable working in a GC-ed language will
>> likely eschew D because D's GC is really not that great.
>>
>
>
> I don't really get the issue with D's GC, Phobos and DRuntime. JavaScript
> is really popular and getting really popular everyday (I mean Nodejs). Same
> as Python, PHP, Ruby (startups), etc. But they are not exactly betterC.
> Most of them don't even give native code speed.
>
> When using D, I just want to get my app working and running. That is why
> more packages (vibe.d, mail, request, mysql-lited, etc) matter to me. The
> level you are trying to raise D is way over-kill IMO :). It's good though
> for those who need it. But most of us don't judge languages that way.
>

Re: Large .init for class containing void-initialized struct

[ketmar via Digitalmars-d]

On Wednesday, 7 December 2016 at 00:20:11 UTC, Ali Çehreli wrote:
Is there a rationale for this or is this an implementation 
quality issue? Is there a bug already? I could not find one.


Also, I failed to find the "= void" documentation e.g. not on 
the struct spec page.


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

at least.

i.e.: known inefficiency, but nobody feels that it is important 
enough to get to the top of the list.

Re: Large .init for class containing void-initialized struct

[Stefan Koch via Digitalmars-d]

On Wednesday, 7 December 2016 at 00:20:11 UTC, Ali Çehreli wrote:

tl;dr; go to the TLDR section below. :)

I use the following command line to identify large symbols. 
Given a binary named 'deneme', the following command line (at 
least on Linux) produces the 30 largest symbols in the 'deneme' 
binary that actually take space in application's memory:


[...]

I think this is a bug.

Why is the classInit generated at all ?
We don't guarantee  blit construction of classes./

Large .init for class containing void-initialized struct

[Ali Çehreli via Digitalmars-d]

tl;dr; go to the TLDR section below. :)

I use the following command line to identify large symbols. Given a 
binary named 'deneme', the following command line (at least on Linux) 
produces the 30 largest symbols in the 'deneme' binary that actually 
take space in application's memory:


  nm --print-size --size-sort --radix=d deneme | tail -30 | grep -v " B "

A test program:

struct S {
int i;
double d;
ubyte[10_000] a;
}

void main() {
}

According to the command line above, the largest symbol in that program 
is S.init:


[...]
04446100 3633 T 
_D4core4time8Duration13_toStringImplMxFNaNbNfZAya

04504980 3707 T _d_arraysetlengthiT
04511312 00010016 R _D6deneme1S6__initZ

So, the S.init object in that binary is 10016 bytes and that makes sense.

Now, request S.init not be generated by initializing the members with void:

struct S {
int i = void; // (Actually, this =void is not required)
double d = void;
ubyte[10_000] a = void;
}

void main() {
}

Great: Now the large S.init is not a part of the binary: (Well, I think 
it's still in the BSS section but it does not take space in the memory):


[...]
04446100 3633 T 
_D4core4time8Duration13_toStringImplMxFNaNbNfZAya

04504980 3707 T _d_arraysetlengthiT

The largest symbol is now something else: _d_arraysetlengthiT. Here 
comes the trouble...


TLDR:

Use the void-initialized struct as a class member and that class gets a 
huge C.init:


struct S {
int i = void;
double d = void;
ubyte[10_000] a = void;
}

class C {
S s = void; // (Same result even without the =void)
}

void main() {
}

[...]
04446260 3633 T 
_D4core4time8Duration13_toStringImplMxFNaNbNfZAya

04505140 3707 T _d_arraysetlengthiT
06681456 00010032 V _D6deneme1C6__initZ

Now we have a 10032 byte C.init.

Is there a rationale for this or is this an implementation quality 
issue? Is there a bug already? I could not find one.


Also, I failed to find the "= void" documentation e.g. not on the struct 
spec page.


Thank you,
Ali

[Issue 16952] REG: rdmd --eval='writeln();' keeps failing at almost every release, needs a test

[via Digitalmars-d-bugs]

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

--- Comment #2 from Timothee Cour  ---
filed https://issues.dlang.org/show_bug.cgi?id=16953: auto-tester doesn't run
rdmd_test (causes a number of regressions in each release)

--

[Issue 16953] New: auto-tester doesn't run rdmd_test (causes a number of regressions in each release)

[via Digitalmars-d-bugs]

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

  Issue ID: 16953
   Summary: auto-tester doesn't run rdmd_test (causes a number of
regressions in each release)
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

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

>> Regarding the issue that this stuff comes up again and again: We do have a 
>> test in rdmd_test.d [1], and it does catch this. I think the problem is that 
>> the auto-tester doesn't run rdmd_test.

and past related bugs:
https://issues.dlang.org/show_bug.cgi?id=15175  rdmd --loop and --eval now
complain about std.stream deprecation warnings
https://issues.dlang.org/show_bug.cgi?id=13288  rdmd --eval fails because it
still imports std.metastrings
https://issues.dlang.org/show_bug.cgi?id=10352 Regression (2.063): --eval is
broken in RDMD

--

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:

Yes there is...


Thanks.

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:

Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.


Sounds like you have your concat implementation right there ;)

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:

On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:

Go ahead.
Many features should already be working correctly.

The missing important ones are slices and concat.


Ok, great.

I was thinking about benchmarking parser generators such as 
Pegged.


Is there another way of concatenating strings than with the 
builtin ~ operator?


Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.


But keep in mind function calls are unsupported right now.
Meaning you have to put everything in one function.
However function calls should be working some time soon.
I am still in the middle of restructuring how blocks or handled, 
because right now I will miscompile for-loops with continues in 
them.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:

Go ahead.
Many features should already be working correctly.

The missing important ones are slices and concat.


Ok, great.

I was thinking about benchmarking parser generators such as 
Pegged.


Is there another way of concatenating strings than with the 
builtin ~ operator?


Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.

[Issue 16952] REG: rdmd --eval='writeln();' keeps failing at almost every release, needs a test

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to Timothee Cour from comment #0)
> it seems to break at every release, probably a symptom there's a test
> missing:
> 
> dmd --version
> DMD64 D Compiler v2.072.1
> rdmd '--eval=writeln();'
> Error: module cstream is in file 'std/cstream.d' which cannot be read

So that people don't go and try to fix this: This specific instance has already
been fixed in master.

Regarding the issue that this stuff comes up again and again: We do have a test
in rdmd_test.d [1], and it does catch this. I think the problem is that the
auto-tester doesn't run rdmd_test.


[1]
https://github.com/dlang/tools/blob/3a32331303e2e62f429b8136ba0de0e9a9294722/rdmd_test.d#L135-L138

--

Re: [Semi-OT] I don't want to leave this language!

[aberba via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis


I would guess that the vast majority of interest shown in Rust 
is from people who essentially want a better C or C++, with no 
runtime/GC. So, I think Ilya's point is very plausible. D with 
no GC, but with modules, templates, overloading, CTFE, and some 
other features might have been more tempting to the no-GC 
crowd, which includes many hardcore C++ programmers.


Those programmers who are comfortable working in a GC-ed 
language will likely eschew D because D's GC is really not that 
great.



I don't really get the issue with D's GC, Phobos and DRuntime. 
JavaScript is really popular and getting really popular everyday 
(I mean Nodejs). Same as Python, PHP, Ruby (startups), etc. But 
they are not exactly betterC. Most of them don't even give native 
code speed.


When using D, I just want to get my app working and running. That 
is why more packages (vibe.d, mail, request, mysql-lited, etc) 
matter to me. The level you are trying to raise D is way 
over-kill IMO :). It's good though for those who need it. But 
most of us don't judge languages that way.

[Issue 16952] REG: rdmd --eval='writeln();' keeps failing at almost every release, needs a test

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
Summary|rdmd --eval='writeln();'|REG: rdmd
   |keeps failing at every  |--eval='writeln();' keeps
   |release, needs a test   |failing at almost every
   ||release, needs a test
   Severity|critical|regression

--

[Issue 16952] New: rdmd --eval='writeln();' keeps failing at every release, needs a test

[via Digitalmars-d-bugs]

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

  Issue ID: 16952
   Summary: rdmd --eval='writeln();' keeps failing at every
release, needs a test
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

it seems to break at every release, probably a symptom there's a test missing:

dmd --version
DMD64 D Compiler v2.072.1
rdmd '--eval=writeln();'
Error: module cstream is in file 'std/cstream.d' which cannot be read


dmd --version
DMD64 D Compiler v2.071.2
rdmd '--eval=writeln();'
Error: module syserror is in file 'std/syserror.d' which cannot be read

and also earlier versions:
https://issues.dlang.org/show_bug.cgi?id=15175  rdmd --loop and --eval now
complain about std.stream deprecation warnings
https://issues.dlang.org/show_bug.cgi?id=13288  rdmd --eval fails because it
still imports std.metastrings
https://issues.dlang.org/show_bug.cgi?id=10352 Regression (2.063): --eval is
broken in RDMD

--

[Issue 8829] std.algorithm.find fails to take advantage of SortedRange

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

[Issue 5236] [patch] std.format.formattedRead/unformatValue does not support the raw reading of integer types

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/17d13e20666d388aba04357d98f7ed092b58bccb
Issue 5236 - [patch] std.format.formattedRead/unformatValue does not support
the raw reading of integer types

https://github.com/dlang/phobos/commit/26f4aec45c75e0b6831a1d77614bbca25b5c4068
Issue 5236 - [patch] std.format.formattedRead/unformatValue does not support
the raw reading of integer types

https://github.com/dlang/phobos/commit/73406665c11c102d4c52e1f12ef9caa1c9ce50ff
Issue 5236 - [patch] std.format.formattedRead/unformatValue does not support
the raw reading of integer types

--

[Issue 8829] std.algorithm.find fails to take advantage of SortedRange

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/8b29f206ae8828cf5656881b16e725850c91b728
Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

https://github.com/dlang/phobos/commit/d6519853e1c603169d15c30a1f32aa7c557d6a9d
Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

https://github.com/dlang/phobos/commit/818d51200754ace7c766c6692a27d95c8e4eafc7
Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

https://github.com/dlang/phobos/commit/752b2ca210f8e6f1b7d1c3887f23c1e5a382a85d
Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

https://github.com/dlang/phobos/commit/e4b82503b8517d533271469797b4a3773ae38527
Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

https://github.com/dlang/phobos/commit/98a7c44aafb7e0547fb4b6845e0724597bc81b81
Merge pull request #4907 from RazvanN7/Issue_8828

Issue 8829 - std.algorithm.find fails to take advantage of SortedRange

--

Re: [Semi-OT] I don't want to leave this language!

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, December 06, 2016 22:13:54 bpr via Digitalmars-d-learn wrote:
> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis
>
> wrote:
> > So, while there are certainly folks who would prefer using D as
> > a better C without druntime or Phobos, I think that you're
> > seriously overestimating how many folks would be interested in
> > that. Certainly, all of the C++ programmers that I've worked
> > with professionally would have _zero_ interest in D as a better
> > C.
>
> I would guess that the vast majority of interest shown in Rust is
> from people who essentially want a better C or C++, with no
> runtime/GC. So, I think Ilya's point is very plausible. D with no
> GC, but with modules, templates, overloading, CTFE, and some
> other features might have been more tempting to the no-GC crowd,
> which includes many hardcore C++ programmers.

Sure, there are folks who would prefer not to have to deal with the GC but
throw out the runtime and std lib? You lose out on too much for it to be at
all worth it for many folks. At that point, C++11/14/17 looks far more
appealing, especially as it continues to improve. And @nogc and sane memory
use largely solves the GC problem for many programs. There are some places
where we need to improve the situation (like with lambdas and the GC), but
for most programs, it's totally workable as-is without giving up on all of
the features provided by the runtime and Phobos.

If you really need absolute pedal-to-the-metal performance and can't afford
to ever have the GC stop the world, you still don't need to actually throw
away the runtime and std lib. You're just a lot more restricted in what you
can do with them. So, tossing out druntime and Phobos entirely seems rather
extreme. It may very well make really good sense for a subset of D programs,
but I have a hard time believing that it's anything more than a small
subset.

> Those programmers who are comfortable working in a GC-ed language
> will likely eschew D because D's GC is really not that great.

We get plenty of folks who aren't big C/C++ programmers who are interested
in D. Yes, the majority seem to have a C++ background, but we also get folks
from C#, python, ruby, etc.

- Jonathan M Davis

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:

Go ahead.
Many features should already be working correctly.

The missing important ones are slices and concat.


Ok, great.

I was thinking about benchmarking parser generators such as 
Pegged.


Is there another way of concatenating strings than with the 
builtin ~ operator?

Tutorial: Form upload in vibe.d

[aberba via Digitalmars-d-announce]

https://aberba.github.io/2016/form-upload-in-vibe-d/

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:

Go ahead.
Many features should already be working correctly.


This https://github.com/UplinkCoder/dmd/commits/newCTFE I presume?

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 December 2016 at 21:40:47 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 16:27:38 UTC, Stefan Koch wrote:
I just implemented a bytecode cache, however the bytecode 
generation is so fast now that we only safe a couple micro 
seconds by using the cache.

It is not noticeable at all :P.


I can't wait to try this out.


Go ahead.
Many features should already be working correctly.

The missing important ones are slices and concat.

Re: [Semi-OT] I don't want to leave this language!

[bachmeier via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
Those programmers who are comfortable working in a GC-ed 
language will likely eschew D because D's GC is really not that 
great.


So someone working with Ruby is not going to want to work with D 
because of GC performance? I wonder what percentage of Ruby 
programmers have thought about garbage collection ever. I could 
see an argument that there are existing frameworks or some other 
reason to prefer another language, but it is highly unlikely that 
GC would be the reason that both C++ and Ruby programmers would 
not want to use D.

Re: [Semi-OT] I don't want to leave this language!

[bpr via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:
So, while there are certainly folks who would prefer using D as 
a better C without druntime or Phobos, I think that you're 
seriously overestimating how many folks would be interested in 
that. Certainly, all of the C++ programmers that I've worked 
with professionally would have _zero_ interest in D as a better 
C.


I would guess that the vast majority of interest shown in Rust is 
from people who essentially want a better C or C++, with no 
runtime/GC. So, I think Ilya's point is very plausible. D with no 
GC, but with modules, templates, overloading, CTFE, and some 
other features might have been more tempting to the no-GC crowd, 
which includes many hardcore C++ programmers.


Those programmers who are comfortable working in a GC-ed language 
will likely eschew D because D's GC is really not that great.

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 16:27:38 UTC, Stefan Koch wrote:
I just implemented a bytecode cache, however the bytecode 
generation is so fast now that we only safe a couple micro 
seconds by using the cache.

It is not noticeable at all :P.


I can't wait to try this out.

Re: [Semi-OT] I don't want to leave this language!

[bachmeier via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 20:01:38 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:
So, while there are certainly folks who would prefer using D 
as a better C without druntime or Phobos, I think that you're 
seriously overestimating how many folks would be interested in 
that. Certainly, all of the C++ programmers that I've worked 
with professionally would have _zero_ interest in D as a 
better C.


- Jonathan M Davis


My experience is completely orthogonal. --Ilya


There is a theorem that all programming language discussions on 
the internet start with the assumption that real programming is 
exactly the same as the programming done by the author.

Re: Impressed with Appender - Is there design/implementation description?

[Jon Degenhardt via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 15:29:59 UTC, Jonathan M Davis 
wrote:
On Tuesday, December 06, 2016 13:19:22 Anonymouse via 
Digitalmars-d-learn wrote:

On Tuesday, 6 December 2016 at 10:52:44 UTC, thedeemon wrote:

[...]

> 2. Up until 4 KB it reallocates when growing, but after 4 KB 
> the array lives in a larger pool of memory where it can 
> often grow a lot without reallocating, so in many scenarios 
> where other allocations do not interfere, the data array of 
> appender grows in place without copying any data, thanks to 
> GC.extend() method.


I always assumed it kept its own manually allocated array on a 
malloc heap :O


No. The main thing that Appender does is reduce the number of 
checks required for whether there's room for the array to 
append in place, because that check is a good chunk of why ~= 
is expensive for arrays.

[...]


Thanks everyone for the explanations. I should probably look into 
my data and see how often I'm reaching the 4kb size triggering 
GC.extend() use.


--Jon

Re: wrong isInputRange design

[rumbu via Digitalmars-d]

On Monday, 5 December 2016 at 21:51:28 UTC, pineapple wrote:

On Sunday, 4 December 2016 at 11:18:56 UTC, rumbu wrote:

---


If you really wanted an `isInputRange` that behaves like you're 
wanting, it's only a 6 line template that you would have to 
interject in your code.


enum bool isInputRange(T) = is(typeof({
T range = T.init;
if(range.empty){}
auto element = range.front;
range.popFront();
}));

https://github.com/pineapplemachine/mach.d



My post was about a wrong design decision which generates a 
compiler error just with one symbol import. If I didn't know how 
to solve this, I would probably post in the learn section :)


After I read the Jonathan's explanations, I understood that it's 
my fault, one must guess which is the proper way to use a 
standard library, so I didn't bother to continue the discussion.


Anyway, you have a very nice library that just proves my point 
that a better design is possible: the "asrange" solution for 
arrays is very elegant.


Finally, for my library I decided to completely ignore the range 
concept, I just check for isIterable and do my processing in a 
foreach loop.

Re: [Semi-OT] I don't want to leave this language!

[Ilya Yaroshenko via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:
So, while there are certainly folks who would prefer using D as 
a better C without druntime or Phobos, I think that you're 
seriously overestimating how many folks would be interested in 
that. Certainly, all of the C++ programmers that I've worked 
with professionally would have _zero_ interest in D as a better 
C.


- Jonathan M Davis


My experience is completely orthogonal. --Ilya

X86-64 calling conventions

[rumbu via Digitalmars-d]

I know already that the D calling convention x86-64 is not the 
same as the one of the corresponding C compiler (register order 
is reversed on Windows and Linux) - details here: 
http://forum.dlang.org/post/mailman.1981.1415996395.9932.digitalmar...@puremagic.com



But even with extern(C), there is something wrong on x86-64 when 
passing arrays as parameters.


In x86-32, the D calling convention is clear for arrays (even 
that's not documented, credits go to the std.bigint creator - Don 
Clungston):


void foo(uint[] x, uint p1, uint p2) will be translated to

push x.ptr;
push x.length;
push p1;
push p2;
call foo;

In a "naked" asm context, it's easy to access parameters
p2 = [ESP + 4]
p1 = [ESP + 8]
x.length = [ESP + 12]
x.ptr = [ESP + 16]

---

Now, on x86-64 (Windows), following the same schema, I expected 
something like this:


mov RCX, x.ptr;
mov RDX, x.length;
mov R8, p1;
mov R9, p2;
(standard Windows x86-64 calling convention)

Instead, the compiler generates something very strange:

mov R8, p2   //somehow ok, third parameter (even I expected to be 
the fourth)
mov RDX, p1  //somehow ok, second parameter (even I expected to 
be the third)

mov [RBP-0x10], x.length //why?
mov [RBP-0x08], x.ptr //why?
lea RCX, [RBP-0x10] //pointer to x.length?

Finally we have:
p2 = R8
p1 = RDX
x.length = [RCX]
x.ptr = ?

Now the questions:

1. Is there any intention to correct the registry reversing 
behaviour for extern(D)?

2. Will someone fully document the ABI for x86-32 and x86-64?
3. How do I find in a naked asm context on x86-64 the starting 
address of an array passed as parameter?


Thanks.

Re: What's the oldest Mac targeted by D programmers?

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 6 December 2016 at 14:28:37 UTC, Walter Bright wrote:

dmd generates SSE code for OSX 32.


Unfortunately Windows + 32-bit is disproportionately important 
for my line of work.

Re: What's the oldest Mac targeted by D programmers?

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 6 December 2016 at 16:00:43 UTC, Nick Sabalausky 
wrote:


"Latest is greatest" has become such a sacred cow in the tech 
sector that far too few developers these days understand basic 
common-sense logic like that.


I guess it's all about if you control the target hardware. It 
would be different for scientific software.

Re: CTFE Status

[Andrei Alexandrescu via Digitalmars-d]

On 12/06/2016 11:27 AM, Stefan Koch wrote:

On Monday, 5 December 2016 at 18:47:13 UTC, Stefan Koch wrote:

On Monday, 5 December 2016 at 16:47:33 UTC, Andrei Alexandrescu wrote:

On 12/05/2016 11:28 AM, Stefan Koch wrote:

It looks like the performance wins brought by the new ctfe engine might
be higher then I predicted.


That's awesome!! -- Andrei


After discovering this performance bottleneck I have now changed my
mind about how I will tackle concatenation of arrays and strings in
particular.
All con-cat operations should be done as intrinsic calls.
Because tight cooperation with the CTFE-Memory-Management-Subsystem is
needed.


I just implemented a bytecode cache, however the bytecode generation is
so fast now that we only safe a couple micro seconds by using the cache.
It is not noticeable at all :P.


Just give us time :o). -- Andrei

[Issue 16951] New: trying to call opCall with alias opCall this, without parentesis fails to compile, when used as a single statement

[via Digitalmars-d-bugs]

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

  Issue ID: 16951
   Summary: trying to call opCall with alias opCall this, without
parentesis fails to compile, when used as a single
statement
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: var.spool.mail...@gmail.com

struct A
{
alias opCall this;
int opCall() { return 0; }
}

void main()
{
A a;
// a; // Error: var has no effect in expression (a)

// some working examples but with some issues
auto a1 = a;  // calls copy constructor
int a2 = a;   // calls opCall
a.writeln;// toString
a.someIntFun; // opCall
}

those issues can be partialy solved by adding @property to opCall

struct A
{
alias opCall this;
@property int opCall() { return 0; }
}

void main()
{
A a;
// a; // still Error: var has no effect in expression (a)

auto a1 = a;  // copy constructor
int a2 = a;   // opCall
a.writeln;// opCall
a.someIntFun; // opCall
}

dont know if its a bug or not but would be nice if the commented line would
compile.

--

Re: How about a bounty for a new windows installer using inno setup ?

[Jim Hewes via Digitalmars-d]

On 12/6/2016 12:21 AM, Thomas Mader wrote:


You can also create a WiX installer out of an InnoSetup installer.
I think it's more important to decide upon the feature set, readability
and the time needed to build an installer.
Have you experience with both? I only have experience with NSIS and
InnoSetup and in InnoSetup the feature set for Windows is really good
and the readability is good.


I started out by using InstallShield some years ago and got battle scars 
there. I don't recommend that. I used NSIS a little because a company we 
partnered with required it but I'm no authority on NSIS or Inno.


It really depends on how complicated your particular install is and 
where you expect it to go in the future. If you're just copying a few 
files then anything will work. I don't mean to make too big a deal out 
of it if the requirements are really simple.


Personally I think it's better in the long run to generate an MSI for 
several reasons you can probably look up yourself---security, ability to 
rollback (installation is a transaction), appears in Programs and 
Features, transforms, etc.



I wouldn't advise doing the coding part externally in D this makes
things much more complicated than it should be. Stick with what's
supported by the tool.


I'm not suggesting you necessarily use D together with something like 
NSIS. But you do want to have a one-button automated build process, not 
just for convenience but for repeatability. That's important. Soon you 
will want to get away from the tool's own GUI and run things 
programmatically.


After having not-so-good experiences with InstallShield I looked at 
things like SCons and msbuild, which was just coming out at the time. 
(This was a while ago). I tried msbuild but it didn't have modules to 
support many of the things I needed to do. Things like code-signing with 
a verisign signature, injecting data and files into exe resources, etc. 
Fortunately you can build your own custom modules using C# which is what 
I tried. But the process of transferring variables back and forth from 
the script to C# for every custom module was painful and I thought, "if 
I just do this all in C# it will be much easier". So I switched. I used 
C# not only to call on the WiX tools to run them, but to easily 
manipulate pathname and filename strings, which were different because I 
needed to build different configurations for different customer 
companies. And I also needed to build different combinations of language 
localization. I could use .NET to build a nice GUI for selecting 
configurations, and C# to call the Windows API when needed, move files 
around, anything.


You may also run into issues when you need to do complicated updates and 
there are already earlier versions in the field. You may want to remove 
features, but your installer has to both update existing users in 
addition to supporting new users. It's hard to predict the future though 
so I won't say much about it except that it helps to have a more 
powerful tool when you run into such situations.


The scripting-type tools are tempting because they're easy and no one 
wants to spend any time on installers. It's usually something that 
people hope to just slap on at the end and it often gets underestimated. 
But as I said, maybe it IS easy if you're just copying files and you 
will only ever have one configuration. So it depends.


Jim

Re: [Semi-OT] I don't want to leave this language!

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, December 06, 2016 13:36:20 Ilya Yaroshenko via Digitalmars-d-
learn wrote:
> On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu
>
> wrote:
> > On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:
> >> On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana
> >>
> >> wrote:
> >>> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
> >>> Phobos/Druntime are pretty good for a lot of projects.
> >>
> >> In theory
> >
> > And what seem to be the issues in practice with code that is
> > not highly specialized? -- Andrei
>
> If code is not highly specialized there is no reason to spent
> resources to use C/C++/D. A company will be happy with Python,
> Java, C#, Go and Swift. If one need to have C/C++ programming
> level he can not use D because DRuntime. Only a subset of D can
> be used. And current problem that we have not BetterC paradigm in
> D specification. So, only crazy companies will consider D for
> large projects. Current D is successful in small console text
> routines.
>
> If a system PL can not be used as C for highly specialized code,
> it is not a real system PL.
>
> DRuntime and Phobos is going to compete with Java and Go. It is
> suicide for D, IMHO. In other hand, BetterC is a direction where
> D can be populated among professionals and replace C/C++.

While I am quite sure that there are use cases where folks would be unhappy
with druntime and Phobos and want to avoid them, there are definitely
companies using D with druntime and Phobos right now, and personally, I've
never worked at a company where anything about druntime or Phobos would have
been a showstopper in switching to D. The showstopper would be in convincing
them to use a new language rather than one that they were already familiar
with. C++ works for them, and they're not interested in switching. And
honestly, pushing for a subset of D that didn't have the functionality in
druntime and Phobos would just make it an even harder sell. At that point,
they're _really_ not interested in using D. C++11/14/17 quickly and easily
wins out in that fight.

So, while there are certainly folks who would prefer using D as a better C
without druntime or Phobos, I think that you're seriously overestimating how
many folks would be interested in that. Certainly, all of the C++
programmers that I've worked with professionally would have _zero_ interest
in D as a better C.

- Jonathan M Davis

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 5 December 2016 at 18:47:13 UTC, Stefan Koch wrote:
On Monday, 5 December 2016 at 16:47:33 UTC, Andrei Alexandrescu 
wrote:

On 12/05/2016 11:28 AM, Stefan Koch wrote:
It looks like the performance wins brought by the new ctfe 
engine might

be higher then I predicted.


That's awesome!! -- Andrei


After discovering this performance bottleneck I have now 
changed my mind about how I will tackle concatenation of arrays 
and strings in particular.

All con-cat operations should be done as intrinsic calls.
Because tight cooperation with the 
CTFE-Memory-Management-Subsystem is needed.


I just implemented a bytecode cache, however the bytecode 
generation is so fast now that we only safe a couple micro 
seconds by using the cache.

It is not noticeable at all :P.

Re: What's the oldest Mac targeted by D programmers?

[Nick Sabalausky via Digitalmars-d]

On 12/06/2016 08:11 AM, Guillaume Piolat wrote:


optimizing for the users which
already have the fastest machines is not going to make a difference
while optimizing for the lower end does.


Very wise. "Latest is greatest" has become such a sacred cow in the tech 
sector that far too few developers these days understand basic 
common-sense logic like that.

Re: wrong isInputRange design

[jmh530 via Digitalmars-d]

On Monday, 5 December 2016 at 21:51:28 UTC, pineapple wrote:


https://github.com/pineapplemachine/mach.d


I love that a few of the subfolders have a Readme.md so that I 
don't have to dig in to anything to get an overview.

Re: Impressed with Appender - Is there design/implementation description?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, December 06, 2016 13:19:22 Anonymouse via Digitalmars-d-learn 
wrote:
> On Tuesday, 6 December 2016 at 10:52:44 UTC, thedeemon wrote:
> > It's rather simple, just take a look at its source code in
> > std.array.
> > It's an ordinary linear array partially filled with your data.
>
> [...]
>
> > 2. Up until 4 KB it reallocates when growing, but after 4 KB
> > the array lives in a larger pool of memory where it can often
> > grow a lot without reallocating, so in many scenarios where
> > other allocations do not interfere, the data array of appender
> > grows in place without copying any data, thanks to GC.extend()
> > method.
>
> I always assumed it kept its own manually allocated array on a
> malloc heap :O

No. The main thing that Appender does is reduce the number of checks
required for whether there's room for the array to append in place, because
that check is a good chunk of why ~= is expensive for arrays. And using ~=
isn't all that bad. It's just that it adds up, and when you're clearly going
to be doing a lot of appending when you first create a dynamic array, it's
just more efficient to use Appender and avoid the extra overhead that ~=
has. What Appender does with put is actually pretty close to what druntime
does with ~=. It's just that Appender can just look at the member variable
to know the capacity of the dynamic array, whereas ~= has to look it up by
looking at the data for the memory block that the dynamic array currently
points to.

All Appender really is is a way to make appending to dynamic arrays more
efficient. It doesn't do anything magical with data structures. At present,
this is what it's member variables look like

private alias T = ElementEncodingType!A;
private struct Data
{
size_t capacity;
Unqual!T[] arr;
bool canExtend = false;
}

private Data* _data;

The magic is in that extra capacity variable, but otherwise, you're
basically dealing with the same array appending you get out of ~=.

> Hence a practice of using .dup and .idup on the .data member when
> you're happy with the result?

That isn't necessary. I don't think that I ever do it. If you want to keep
appending with Appender, and you want a dynamic array that has its own
memory to grow into without being affected by Appender, then it would make
sense to use dup/idup, but that's true any time that you append to a dynamic
array. And you might want dup/idup to get a dynamic array with a different
type of mutability than the dynamic array in the Appender just like you
might want with a naked dynamic array, but since you define the mutability
with Appender, you'd usually just change the array type that you
instantiated Appender with.

- Jonathan M Davis

Re: What's the oldest Mac targeted by D programmers?

[Walter Bright via Digitalmars-d]

On 12/6/2016 5:11 AM, Guillaume Piolat wrote:

No opinion. My whole segment runs on SSE.

Zero interest in AVX here, because optimizing for the users which already have
the fastest machines is not going to make a difference while optimizing for the
lower end does. Hence it's critically important that 32-bit builds use SSE
instead of FPU (because denormals) but that's another question and already
addressed by LDC.

For DMD I'd more interested in yet improving raw compile-time speed, quality,
and working 32-bit SSE intrinsics in core.intrinsic (did that changed? D_SIMD
wasn't here in 32-bit).


dmd generates SSE code for OSX 32.

[Issue 16758] Variant.opIndex result not modified after opAssign

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16758] Variant.opIndex result not modified after opAssign

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/cdd2acb0d58b38659260348d4fb78d2aba6db51c
Fix Issue 16758 - Variant.opIndex result not modified after opAssign

Add VariantN.opIndexOpAssign.
Also undocument & tweak test for const(Variant).opIndex.

https://github.com/dlang/phobos/commit/94d3786d6995dbc2fafdba1408dd6d7974d91625
Merge pull request #4923 from ntrel/variant-opIndexOpAssign

Fix Issue 16758 - Variant.opIndex result not modified after opAssign

--

Re: [Semi-OT] I don't want to leave this language!

[Ilya Yaroshenko via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu 
wrote:

On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:
On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana 
wrote:

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
Phobos/Druntime are pretty good for a lot of projects.


In theory


And what seem to be the issues in practice with code that is 
not highly specialized? -- Andrei


If code is not highly specialized there is no reason to spent 
resources to use C/C++/D. A company will be happy with Python, 
Java, C#, Go and Swift. If one need to have C/C++ programming 
level he can not use D because DRuntime. Only a subset of D can 
be used. And current problem that we have not BetterC paradigm in 
D specification. So, only crazy companies will consider D for 
large projects. Current D is successful in small console text 
routines.


If a system PL can not be used as C for highly specialized code, 
it is not a real system PL.


DRuntime and Phobos is going to compete with Java and Go. It is 
suicide for D, IMHO. In other hand, BetterC is a direction where 
D can be populated among professionals and replace C/C++.


Ilya

Re: Impressed with Appender - Is there design/implementation description?

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 10:52:44 UTC, thedeemon wrote:
It's rather simple, just take a look at its source code in 
std.array.

It's an ordinary linear array partially filled with your data.


[...]

2. Up until 4 KB it reallocates when growing, but after 4 KB 
the array lives in a larger pool of memory where it can often 
grow a lot without reallocating, so in many scenarios where 
other allocations do not interfere, the data array of appender 
grows in place without copying any data, thanks to GC.extend() 
method.


I always assumed it kept its own manually allocated array on a 
malloc heap :O


Hence a practice of using .dup and .idup on the .data member when 
you're happy with the result?

Re: What's the oldest Mac targeted by D programmers?

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:


This leads to the question is AVX support a minimum 
configuration for Macs? Can AVX instruction generation become 
the default for OSX?


No opinion. My whole segment runs on SSE.

Zero interest in AVX here, because optimizing for the users which 
already have the fastest machines is not going to make a 
difference while optimizing for the lower end does. Hence it's 
critically important that 32-bit builds use SSE instead of FPU 
(because denormals) but that's another question and already 
addressed by LDC.


For DMD I'd more interested in yet improving raw compile-time 
speed, quality, and working 32-bit SSE intrinsics in 
core.intrinsic (did that changed? D_SIMD wasn't here in 32-bit).

Re: [Semi-OT] I don't want to leave this language!

[Andrei Alexandrescu via Digitalmars-d-learn]

On 12/5/16 3:49 PM, e-y-e wrote:

If you don't mind me saying, I think Mir could be one of the best things
for the future of D (along with LDC) and I'd be glad to help it on its way.


Yes, Mir is awesome! I keep on thinking of ways to make it better 
supported by the language and infra. -- Andrei

Re: [Semi-OT] I don't want to leave this language!

[Andrei Alexandrescu via Digitalmars-d-learn]

On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:

On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
Phobos/Druntime are pretty good for a lot of projects.


In theory


And what seem to be the issues in practice with code that is not highly 
specialized? -- Andrei

Re: Impressed with Appender - Is there design/implementation description?

[thedeemon via Digitalmars-d-learn]

On Sunday, 4 December 2016 at 20:03:37 UTC, Jon Degenhardt wrote:
I've been using Appender quite a bit recently, typically when I 
need append-only arrays with variable and unknown final sizes. 
I had been prepared to write a custom data structure when I 
started using it with large amounts of data, but very nicely 
this has not surfaced as a need. Appender has held up quite 
well.


I haven't actually benchmarked it against competing data 
structures, nor have I studied the implementation. I'd be very 
interested in understanding the design and how it compares to 
other data structures. Are there any write-ups or articles 
describing it?


--Jon


It's rather simple, just take a look at its source code in 
std.array.
It's an ordinary linear array partially filled with your data. 
When your data fills it up, it gets resized to make more space. 
Just two interesting points:


1. When it needs to grow it uses a formula like k = 1 + 10 / 
log2(newsize) for the growth factor (but with a limit of k <= 2), 
which means up to 16 KB it doubles the size each time, then tries 
to grow by a factor of 2/3, then by lower and lower factors.


2. Up until 4 KB it reallocates when growing, but after 4 KB the 
array lives in a larger pool of memory where it can often grow a 
lot without reallocating, so in many scenarios where other 
allocations do not interfere, the data array of appender grows in 
place without copying any data, thanks to GC.extend() method.

Re: Set Intersection of SortedRanges

[Nordlöw via Digitalmars-d-learn]

On Monday, 5 December 2016 at 22:10:34 UTC, Nordlöw wrote:

Has anybody already done this?


This gives good guidance on three different approaches.

http://stackoverflow.com/questions/2400157/the-intersection-of-two-sorted-arrays/4601106#4601106

Luckily we already have galloping search in Phobos :)

I'll do a couple of benchmarks.

Re: What's the oldest Mac targeted by D programmers?

[Walter Bright via Digitalmars-d]

On 12/6/2016 1:31 AM, Johan Engelen wrote:

AVX2 is not listed in machdep.cpu.features, at least not on my machine; you need
to look in the machdep.cpu.leaf7_features list.

https://csharpmulticore.blogspot.nl/2014/12/how-to-check-intel-avx2-support-on-mac-os-x-haswell.html


Bummer. Seems like I have nothing that does AVX2.

Worse, my motherboard will not support the AMD Carrizo processor (the only AMD 
AVX2 one) so upgrading means a new computer.


Grumble, grumble.

Re: What's the oldest Mac targeted by D programmers?

[John Colvin via Digitalmars-d]

On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:
I've been experimenting with code generation in DMD for the AVX 
instruction set, in particular the replacement of SSE 16 byte 
vectors with AVX 16 byte vectors (no, not the 32 byte ones!).


In my experiments on my machines, two of them support the AVX 
instruction set,

one of which is my Mac Mini, as determined by this program:

  import core.stdc.stdio;
  import core.cpuid;

  void main() {
printf("%d %d\n", core.cpuid.avx, core.cpuid.avx2);
  }

or by running:

  sysctl -a | grep machdep.cpu.features

and looking for AVX1.0.

My Mac Mini sez:

  ~> sysctl -a | grep machdep.cpu.features
  machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC 
SEP MTRR PGE
  MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM 
PBE SSE3
  PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM 
SSE4.1 SSE4.2

  xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

My older MM clearly does not support AVX2, though.

This leads to the question is AVX support a minimum 
configuration for Macs? Can AVX instruction generation become 
the default for OSX?


No. Avx arrived in sandy bridge, early 2011. The first sandy 
bridge processors to land in Macs were shortly after that. macOS 
Sierra supports hardware back to late 2009 and the OS X versions 
we support work on even earlier hardware.


See everymac.com for apple hardware details.

As far I can tell, -march= / -mcpu= options with native as a 
valid specification is the standard, sane way to deal with this.

Re: What's the oldest Mac targeted by D programmers?

[Johan Engelen via Digitalmars-d]

On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:


My Mac Mini sez:

  ~> sysctl -a | grep machdep.cpu.features
  machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC 
SEP MTRR PGE
  MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM 
PBE SSE3
  PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM 
SSE4.1 SSE4.2

  xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

My older MM clearly does not support AVX2, though.


AVX2 is not listed in machdep.cpu.features, at least not on my 
machine; you need to look in the machdep.cpu.leaf7_features list.


https://csharpmulticore.blogspot.nl/2014/12/how-to-check-intel-avx2-support-on-mac-os-x-haswell.html

-Johan

What's the oldest Mac targeted by D programmers?

[Walter Bright via Digitalmars-d]

I've been experimenting with code generation in DMD for the AVX instruction set, 
in particular the replacement of SSE 16 byte vectors with AVX 16 byte vectors 
(no, not the 32 byte ones!).


In my experiments on my machines, two of them support the AVX instruction set,
one of which is my Mac Mini, as determined by this program:

  import core.stdc.stdio;
  import core.cpuid;

  void main() {
printf("%d %d\n", core.cpuid.avx, core.cpuid.avx2);
  }

or by running:

  sysctl -a | grep machdep.cpu.features

and looking for AVX1.0.

My Mac Mini sez:

  ~> sysctl -a | grep machdep.cpu.features
  machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE
  MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3
  PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2
  xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

My older MM clearly does not support AVX2, though.

This leads to the question is AVX support a minimum configuration for Macs? Can 
AVX instruction generation become the default for OSX?

Re: D with CygWin

[unDEFER via Digitalmars-d]

So it was not finish :-(

mkdir("C:\\cygwin\\home\\undefer\\TEST") is working
mkdir("/home/undefer/TEST") creates directory and hangs, doesn't 
pass control to the next instruction.


DirEntry("/") works in my simple program, but doesn't work in big 
program..


windbg, gdb doen't help at all.

It is failure :-(

Re: [Semi-OT] I don't want to leave this language!

[Ilya Yaroshenko via Digitalmars-d-learn]

On Monday, 5 December 2016 at 20:49:50 UTC, e-y-e wrote:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
wrote:

[...]


You know from the 15th December I will have a month of free 
time, and I would love to get myself up to speed with Mir to 
contribute to it. If you don't mind me saying, I think Mir 
could be one of the best things for the future of D (along with 
LDC) and I'd be glad to help it on its way.


Awesome! The main directions are:
 1. stdC++ analogs implementation in betterC Dlang subset
 2. betterC analogs of existing Phobos modules. We can reuse 
DRuntime / Phobos code for initial commits.

 3. Various numeric / sci software.
 4. GPU algorithms. This require dcompute to be a part of LDC.

Thank you,
Ilya

Re: [Semi-OT] I don't want to leave this language!

[Ilya Yaroshenko via Digitalmars-d-learn]

On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
Phobos/Druntime are pretty good for a lot of projects.


In theory

Re: How about a bounty for a new windows installer using inno setup ?

[Thomas Mader via Digitalmars-d]

On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote:

On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote:

On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote:
How about a bounty for a new windows installer using inno 
setup ?


There are several issues related to the nsis-based windows 
installer
(even on bugzilla). The problem that happened last Fall with 
a virus
false detection may happen again. "Braddr" proposed to handle 
digital

signatures in case it would involve payment.

Programming an installer is a small job but it has a long 
term impact

on the user experience. Worth 100€ imo.


Any particular reason to use Inno Setup over for example Wix 
Toolset?



In my last job I worked on installers (which I didn't like but 
someone had to do it.) I recommend WiX over Inno. The main 
reason is that WiX produces an MSI and Inno doesn't. An MSI is 
just a data file, not an executable, and is thus better for 
security. I normally wrapped the MSI in a bootstrap exe. But we 
had one customer that was part of the government and wouldn't 
accept anything but an MSI.
If you want, you can generate the XML with a program. I just 
didn't because I figured it was easier to modify if you can 
directly see the XML. My install builder was actually a 
combination of C# and WiX. I never found scripts to be flexible 
enough and it's just one more language to know.


Jim



You can also create a WiX installer out of an InnoSetup installer.
I think it's more important to decide upon the feature set, 
readability and the time needed to build an installer.
Have you experience with both? I only have experience with NSIS 
and InnoSetup and in InnoSetup the feature set for Windows is 
really good and the readability is good.
I wouldn't advise doing the coding part externally in D this 
makes things much more complicated than it should be. Stick with 
what's supported by the tool.

Re: [Semi-OT] I don't want to leave this language!

[Andrea Fontana via Digitalmars-d-learn]

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:
Good D code should be nothrow, @nogc, and betterC. BetterC 
means that it must not require DRuntime to link and to start. I 
started Mir as scientific/numeric project, but it is going to 
be a replacement for Phobos to use D instead/with of C/C++.


Completly disagree. You're speaking about scientific projects, 
maybe.

Phobos/Druntime are pretty good for a lot of projects.

Andrea