On 2015-07-20 06:02, Walter Bright wrote:

> 2.069 - translate to D.

This should absolutely be our main focus, to finish the D port.

-- 
/Jacob Carlborg

On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:
> On a serious note though, the versioning could be better, and I think
> the current suggested version bump from Walter is a missed opportunity
> to set things right.  To quote anther project leader though: "Let’s
> face it - what’s the point of being in charge if you can’t pick the
> bike shed color without holding a referendum on it?"

I'm sad that this discussion on Evil Plans has so quickly turned into a deluge of posts bikeshedding a version number.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 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.
>
> Perhaps we should name this 2.100, to signify such a milestone.
>
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than the current "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means so we can have a coherent process of compiling them.
> 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.
> 5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.
> 6. Convert the back end to D as well.

It'll be fantastic to get a lot of that done. The CTFE improvements in particular are likely to be huge. It'll be interesting to see how much faster some of the compiler improvements will get done once we don't have to worry about maintaining it in C++ anymore.

One big item that we've never quite managed to get far with is removing opEquals, opCmp, toString, and toHash from Object:

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

Without that, attributes on classes are kind of borked - particularly with regards to const. As it is, druntime is violating the type system by casting away const to compare const Objects.

Making that work without breaking code is going to require some changes in both dmd and druntime (probably including the work on AAs that Martin's been working on), and it'll likely be fairly interesting to pull off, but I think that it's pretty clear that we need to find a way to do it if we don't want classes to be too restrictive with regards to attributes - both with regards to which ones are permitted and which ones are required.

- Jonathan M Davis

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.

Is there a timeline for this Evil Plan? What about bug fixes during the 2.068-2.069 period; are these deprioritized in favor of the translation?

It's pretty exciting! I hope that after the compiler is all D-ified, there'll be some work on building DMD from source so that it becomes a much simpler process.

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

On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:
> On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:
>> On a serious note though, the versioning could be better, and I think
>> the current suggested version bump from Walter is a missed opportunity
>> to set things right.  To quote anther project leader though: "Let’s
>> face it - what’s the point of being in charge if you can’t pick the
>> bike shed color without holding a referendum on it?"
>
> I'm sad that this discussion on Evil Plans has so quickly turned into a deluge of posts bikeshedding a version number.

The fact that you consider this bikeshedding is quite a highlight of the problem alone.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

How is this evil? This seems very good :)

> 2.068 - resolve remaining regressions and release
>
> 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.

YAY, I have been wanting to learn how the compiler works for a while but have been to lazy and don't want to look at so much c++, having to be in D will make diggin into it so much more attractive.

Also seems like the compiler as a library is not too far away, is that going to be apart of the plan eventually?

> Perhaps we should name this 2.100, to signify such a milestone.

Your the boss, I dont gaf what the version numbers are.

> 2.101+ -
> 1. Take advantage of D features to improve quality.

Again, yay...

> 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?

> 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?

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

Oh god yes

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

No idea what this is referring to..

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

<3

This all seems very not evil.

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?

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.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 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.

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.

On 7/20/15 4:42 PM, Dicebot wrote:
> On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:
>> On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:
>>> On a serious note though, the versioning could be better, and I think
>>> the current suggested version bump from Walter is a missed opportunity
>>> to set things right.  To quote anther project leader though: "Let’s
>>> face it - what’s the point of being in charge if you can’t pick the
>>> bike shed color without holding a referendum on it?"
>>
>> I'm sad that this discussion on Evil Plans has so quickly turned into
>> a deluge of posts bikeshedding a version number.
>
> The fact that you consider this bikeshedding is quite a highlight of the
> problem alone.

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