On Monday, 20 July 2015 at 21:49:01 UTC, Martin Nowak wrote:
> Those 2 issues have nothing to do with visibility of imported private symbols. There is DIP22 and a few outstanding protection checks.

I thought that one of them did. Clearly, I misremembered. Regardless, both of those issues and DIP22 definitely need to be sorted out, and it is kind of embarrassing that it's taken this long, but we're not exactly the quickest with getting stuff done... :(

- Jonathan M Davis

On Monday, 20 July 2015 at 21:25:22 UTC, ZombineDev wrote:
> On Monday, 20 July 2015 at 20:53:09 UTC, Temtaime wrote:
>> DMD is a problem for all the D ecosystem.
>> It supports only x86, has a proprietary backend license, generates very, very slow and ugly code.
>>
>> Only one feature : it's faster than ldc for example and it's only because 1.5 humans want to optimize ldc.
>>
>> DMD should be dropped in favor of ldc.
>
> By your logic we should also drop support for Windows, since currently only DMD supports Windows well. It would be really stupid to focus on only one backend. Being backend agnostic is a far better objective. Why should anyone be tied to using _only_ LLVM? For example, AFAIK, GDC has far superior support for embedded platforms. Also having a reference implementation _different_ from GDC and LDC has advantages on its own.
> DMD's backend isn't holding back GDC or LDC in any way. Nowadays there are quite few changes in that area so DMD's backend isn't stealing manpower that would otherwise go to LDC or GDC. Surprisingly, in the last few months I have the impression that DMD has far less codegen bugs than LDC and GDC, though I maybe wrong.

because versions are released with GDC and LDC lagging 2-3 versions behind, when DMD is unusable for production quality codegen.

2.068 is almost out and GDC and LDC both only support 2.066. Until D decides to adopt either GDC or LDC as a real backend, this will never be fixed.

On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:
> because versions are released with GDC and LDC lagging 2-3 versions behind, when DMD is unusable for production quality codegen.
>
> 2.068 is almost out and GDC and LDC both only support 2.066. Until D decides to adopt either GDC or LDC as a real backend, this will never be fixed.

Unifying the frontend will go a long way towards fixing this problem, and Daniel is working on that right now. He's aiming to make it so that the frontend is identical across all three compilers so that the ldc and gdc developers don't have to fork it like they do now.

- Jonathan M Davis

On 7/20/2015 12:52 PM, Brian Rogoff wrote:
> Is there a timeline for this Evil Plan?

Not really, other than ASAP.


> What about bug fixes during the
> 2.068-2.069 period; are these deprioritized in favor of the translation?

That's right. Trying to fix bugs while translating doesn't work very well. The idea is to get a 2.068 workalike to use as a baseline. Regressions can, of course, still be pushed to the 2.068 line.

That said, one can still post PR's for fixes. No reason to stop doing that.


> It's pretty exciting!

Me too!

On 7/20/2015 2:02 PM, Andrei Alexandrescu wrote:
> I, too, think we devote too much attention to the picayune. There's a lot of
> interesting stuff in Walter's post, yet most discussion focused on a side
> remark. -- Andrei

Yah, it was a throwaway comment I thought of while I was typing in the post. I should have known better :-)

On 7/20/2015 2:24 PM, Martin Nowak wrote:
> On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
>> 2.101+ -
>
> This sounds like workload for the rest of the year.
> Are you sure that the CTFE interpreter and compilation speed are the 2 most
> important issues?
> They are definitely very high priority, but I'd also like us to address all the
> import (313+314) and protection issues (DIP22) this year.

What is high priority is certainly debatable, but what is most clear to me is that transitioning to D source code has finally bubbled to the top of the stack. I strongly believe that D source code will enable us to simplify the front end and improve its quality substantially, which will help with everything else we want to improve.

And if it doesn't, we should be reevaluating what we're doing with D :-)

On 7/20/2015 2:51 PM, Martin Nowak wrote:
> I still have a lot WIP for the GC, RefCounted, and Unique.
> So I hope you only mean dmd with this restriction.

Right, the library should not be affected.

On 7/20/2015 1:52 PM, Tofu Ninja wrote:
> Also seems like the compiler as a library is not too far away, is that going to
> be apart of the plan eventually?

Yes.


>> 2. Go to full lazy semantic analysis of imports, rather than the current
>> "analyze them all"
> What effects will this have? Faster compile times? Smaller binaires?

Yes.


>> 3. Rethink what "speculative instantiation" of templates means so we can have
>> a coherent process of compiling them.
> Sounds complicated... what effects will this have? Simpler internals? What
> effects for end user?

Mainly fewer compiler bugs.


> This all seems very not evil.

Not evil enough? I have failed!


> One question I have, are there any plans for a language clean up of sorts, there
> are a bunch of little features and some big that don't really make sense
> anymore. D is starting to feel like it's going down the road of c++ with lots of
> baggage and unwillingness to get rid of old features even if they are
> discouraged from use, all for the sake of backwards compatibility. I know D has
> been getting progressively more reserved about breaking changes, do you see that
> changing any time in the future? 1 year? 3 years? Would automatic conversion
> tools make you more willing to break things?

I think we're kinda stuck there.

On 7/20/2015 1:58 PM, Martin Nowak wrote:
> Releasing ddmd with dmd's current backend results in a ~20-30% slowdown s we'd
> have to compile ddmd with gdc or ldc to make this feasible.

First we have to make sure we know why it is slower.

On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:
>>
>> because versions are released with GDC and LDC lagging 2-3 versions
behind, when DMD is unusable for production quality codegen.
>>
>> 2.068 is almost out and GDC and LDC both only support 2.066. Until D
decides to adopt either GDC or LDC as a real backend, this will never be fixed.
>
>
> Unifying the frontend will go a long way towards fixing this problem, and
Daniel is working on that right now. He's aiming to make it so that the frontend is identical across all three compilers so that the ldc and gdc developers don't have to fork it like they do now.
>

Hardly. All he can take credit for is removing the virtual method interface and replacing them with visitors (which can be described as no small job, but benefitted more towards ddmd).

Everything else has been a slow, tedious three year job from yours truly to remove all x86-isms and platform-specific handling out of the frontend.

There are a more than a few last leg things to be done, some are in PRs raised by me, but or not being looked at, or understood properly.

Example, I moved underscore prefixing hacks for OSX out of the frontend (every single one broke GDC ABI in one way or another) and into Target. Then Walter slams it for being pointless refactoring.

Target is a concept raised at DConf 2013 where I bounced the idea that all uses of global.params.isXXX should be removed from the frontend as all are there to only address a perk of DMD when targeting that platform.  The end goal then becomes to make it so that instead of asking 'Is my target OSX?', what the frontend should be asking is 'Does the target add prefixes to symbols?'

I shouldn't have to explain why the latter benefits all.

Iain