On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.101+ -
> 1. Take advantage of D features to improve quality.

Great for thing with good test coverage. Will hopefully attract more contributors.

> 2. Go to full lazy semantic analysis of imports, rather than the current "analyze them all"

Good for compilation speed, but sound very work intensive.
Maybe do an 80/20 solution instead?

We have a few more important compiler issue, such as 313+314.

> 3. Rethink what "speculative instantiation" of templates means so we can have a coherent process of compiling them.

Longstanding issue, particularly for separate compilation and when compiling to multiple object files.

> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.

High priority task.

> 5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.

Sure

> 6. Convert the back end to D as well.

Waste of time IMO, there is nothing to gain here.

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.

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.

2015-07-20 22:28 GMT+02:00 Gary Willoughby via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:
>
>> I'm sad that this discussion on Evil Plans has so quickly turned into a deluge of posts bikeshedding a version number.
>>
>
> Hardly bikeshedding. The comments are merely pointing out that as it stands D doesn't follow any particular versioning style, making each release hard to understand in the big picture. No other language has these problems and usually use well documented, easily understandable versioning. a la http://semver.org
>

We do follow a versioning style: '2.MAJOR.PATCH'  (with major being 3 digits). It's not as good as SemVer, but better than it was few years ago, and I have faith we'll end up following SemVer at some point.

Following SemVer strictly wouldn't solve the real problem: We'll go from
2.068, 2.069. 2.070.. to 3.0.0, 4.0.0, 5.0.0 and will soon end up playing
catch up with Chrome.
To follow SemVer we'll have to separate breaking changes from bugfixes
(including regressions) from new feature, and most likely work with
separate branches.. Martin already started to work on this and we're in a
nicer spot now, but it requires manpower.
Since we don't have 2 consecutive releases that don't break code, I see no
point in changing the version scheme at this point other than satisfying
the purists.

Having a focus for releases will hopefully mitigate that problem. But so far most posts have been about "BTW we need that fixed" and "our versioning scheme is broken".

On Monday, 20 July 2015 at 21:02:38 UTC, 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

Agreed. Maybe we should change how we do versioning, maybe not. But it is disappointing that almost the entirety of the discussion has been on changing the versioning scheme rather than the cool stuff that the original post was about.

- Jonathan M Davis

On Monday, 20 July 2015 at 21:24:59 UTC, 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's the hold up on those anyway? I thought that Kenji had a PR that sorted them out. In fact, I thought that someone at dconf said something about those changes being merged in already (though maybe I'm misremembering). I take it that there were outstanding issues with the PR that have made it so that it hasn't gotten in yet? Or maybe it only fixed some of the issues?

Regardless, it's a serious issue, particularly in light of how easy it is to break existing code with unrelated changes thanks to how private is dealt with currently.

- Jonathan M Davis

On Monday, 20 July 2015 at 21:38:35 UTC, Jonathan M Davis wrote:
> What's the hold up on those anyway? I thought that Kenji had a PR that sorted them out. In fact, I thought that someone at dconf said something about those changes being merged in already (though maybe I'm misremembering). I take it that there were outstanding issues with the PR that have made it so that it hasn't gotten in yet? Or maybe it only fixed some of the issues?

We have a PR from Kenji, that fixes 313+314.
https://github.com/D-Programming-Language/dmd/pull/3407

It's a major change of the import system, so it needs a thorough review and we also need to mitigate the code breakage impact of this change.

> Regardless, it's a serious issue, particularly in light of how easy it is to break existing code with unrelated changes thanks to how private is dealt with currently.

Those 2 issues have nothing to do with visibility of imported private symbols. There is DIP22 and a few outstanding protection checks.

On Monday, 20 July 2015 at 21:02:38 UTC, 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

And I see this as typical "two steps forward, one step back" case which tends to be the trend in later D development. Meaningless versioning scheme makes hard to both implement breaking changes in industry-friendly manner (every single release becomes breaking) and reason about support cycle of specific feature set (major headache with gdc inclusion into gcc which means version freeze).

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.

I still have a lot WIP for the GC, RefCounted, and Unique.
So I hope you only mean dmd with this restriction.

On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:
> I just have one request.  We need to designate a supported version of the compiler (2.069?) as the base to which we convert and maintain compatibility for, and do not introduce any new features after that point.

I don't fully understand what you're asking for.
Can you tell us what problem you're trying to address instead of which solution to apply.