What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?

I haven't seen a Vision/20xxHy for a while.

What features (and breaking changes) are on the horizon for when the next generation D 3.x begins?

There are plenty of languages out there that have intriguing features that may (or may not) be good candidates to consider for D 3.x.

Rust with its type state, which allow for a strong memory ownership model for a non-GC language.  Although I think it adds considerably to the learning curve struggle to grapple with, at least for Rust novices such as myself.

Swift and Kotlin, both of which have syntax similarities aimed at preventing certain common categories of bugs.

OCaml and family (e.g., F#, and I include Haskell as a kissing cousin of the ML family) that embrace functional-first functional programming.

C++17 and C++2a, as one of the frontrunner languages that's evolving in amazing ways (but sometimes odd ways), and its goal of backwards compatibility really has made for some awkward and awful syntax.  Take Spirit for example:  that's both awe-inspiring combined with an amazing abuse of operator overloading.

Both C# and Java have been evolving and adding new and interesting functionality.  Some just gloss and polish and sugar, but some language features are very interesting.

Then there's always Lisp and family.

Thoughts?  Plans?  Roadmap?

On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
>
> Thoughts?  Plans?  Roadmap?

(I may have mentioned this before, but I can’t find a relevant old post. Apologies if I’m repeating myself.)

I would like to see D move ahead in performance terms. Being faster than C/C++ is a very tall order since compilers tends to use common backend machinery and possibly other bits and pieces - I don’t know.

I would like to see ideas for features that support killer optimisations and better use of hardware - need ideas for this though. For example, D’s SIMD and parallelism support are excellent. Pure could be another.

I see hope for this because it seems to me that D possibly has more freedom to evolve than say C++ and especially C.

On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
> Thoughts?  Plans?  Roadmap?


I followed the forum long enough, to understand the community (I think)
D is a small community of developers, who cannot afford to grant wishes

Other communities, who have a large poll of contributors, and large number of users, might be more accommodating for user wishes (or grant user wishes, if a specific wish become popular enough, like if thousands of users ask for the same features. This is not a scenario that could happen in D)

In the D community, if you want something code it, if you cant, very little chance someone will grant you your wish

I think, there are some big projects within D, the betterC , Ownership and Borrowing  and maybe few others

I think those are the big two at the moment, the future of D or D roadmap, is more or less those two projects

Other than that, I think the biggest challenges are making sure all features fit and work together nicely and marketing, making D more popular grow the community etc ...

On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:
>
> Other than that, I think the biggest challenges are making sure all features fit and work together nicely and marketing, making D more popular grow the community etc ...

I think developers want stability and not a language that chases for the next compiler technology trend as soon as it pops up.

Also a good base of nice libraries is just as important as the language itself.

On Sun, Aug 30, 2020 at 05:32:32PM +0000, Eljay via Digitalmars-d wrote:
> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
[...]

Walter & others who make decisions have repeatedly stated that there will be no D3.  Not in the foreseeable future, anyway.  But I'm not sure if things have changed since.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On Monday, 31 August 2020 at 14:42:04 UTC, IGotD- wrote:
> On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:
>>
>> Other than that, I think the biggest challenges are making sure all features fit and work together nicely and marketing, making D more popular grow the community etc ...
>
> I think developers want stability and not a language that chases for the next compiler technology trend as soon as it pops up.

If it were only a question of figuring out "what developers want" and then implementing it, language design would be easy. :)

The messy truth is that different developers want different things, and no group of developers ever agrees completely on what they do or don't want. I mean, think about how much people argue about tabs vs. spaces, or vim vs. emacs. Do you really think these same people are going to come to a clear consensus about stability vs. innovation?

On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
>
> Do you really think these same people are going to come to a clear consensus about stability vs. innovation?

That's the impression I get from reading this forum. DIPs that are small tweaks that breaks nothing or very little often get positive feedback. DIPs that makes big breaking changes or tries fork in a new piece of technology often has more controversy around it. Now, you would say that this is completely natural but still I haven't seen that big enthusiasm regarding the bigger changes. That's my observation when it comes to D. When it comes to other languages, I don't know but they are often governed in some other fashion like C++.

On Monday, 31 August 2020 at 19:11:40 UTC, IGotD- wrote:
> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
>>
>> Do you really think these same people are going to come to a clear consensus about stability vs. innovation?
>
> That's the impression I get from reading this forum. DIPs that are small tweaks that breaks nothing or very little often get positive feedback. DIPs that makes big breaking changes or tries fork in a new piece of technology often has more controversy around it. Now, you would say that this is completely natural but still I haven't seen that big enthusiasm regarding the bigger changes. That's my observation when it comes to D. When it comes to other languages, I don't know but they are often governed in some other fashion like C++.

From what I recall, DIP 1028, "Make @safe the Default", which proposed perhaps the most significant breaking change of any DIP ever, got a lot of positive feedback, *except* for the controversial part about extern(C) functions. So it seems to me like a substantial portion of the D community is happy to embrace breaking changes, as long as they're handled well and bring a enough of a benefit.

For a less controversial example, DIP 1024, "Shared Atomics", also introduced breaking changes, and was also received positively.

On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via Digitalmars-d wrote:
> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
> > 
> > Do you really think these same people are going to come to a clear consensus about stability vs. innovation?
> 
> That's the impression I get from reading this forum. DIPs that are small tweaks that breaks nothing or very little often get positive feedback. DIPs that makes big breaking changes or tries fork in a new piece of technology often has more controversy around it. Now, you would say that this is completely natural but still I haven't seen that big enthusiasm regarding the bigger changes. That's my observation when it comes to D. When it comes to other languages, I don't know but they are often governed in some other fashion like C++.

>From my POV, the controversies usually involve 3 main factors:

- The desire not to break existing code: this used to be a smaller
  problem, but these days it seems we're treading on eggshells whenever
  something might potentially break code;

- The desire for major new features with breaking changes, to rid the
  language of unwanted baggage and add desirable features that we can't
  currently add because it conflicts with the way things are currently
  done.

- The desire to balance the previous two by making smaller changes --
  but the change gets seen as anemic and not going far enough to be
  actually useful and justify the cost.


I've mentioned before (though I'm not 100% sure how practical it would be with D) that one way to move forward is to introduce a language versioning mechanism to D, such that each module declares which language version it was written in. The compiler would internally have multiple versioned components that represent selected "frozen" states of the language, which would be selected by this version directive so that it retains the old semantics of the language. Ideally, this would allow us to retain complete backward compatibility (at least up to the point this versioning system was introduced) while allowing newer language versions to break things as necessary to implement new features. Since the versioning will apply by module, one can incrementally upgrade code to newer language versions without being forced to fix everything all at once upon installing a newer compiler.

Of course, there's bound to be cases where an older language version is fundamentally incompatible with a newer version; in such cases perhaps it can be a compile error if a newer module interacts with an older module in a way that falls under such incompatibilities. The idea being to catch this at compile-time instead of breaking stuff at runtime.

IOW, it's what Andrei has been repeating about adding rather than changing. Add new versions of the language in the same compiler, instead of changing the meaning of the current version of the language.


T

-- 
Don't get stuck in a closet---wear yourself out.

On Monday, 31 August 2020 at 19:33:45 UTC, H. S. Teoh wrote:
> On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via Digitalmars-d wrote:
>> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
>>
> IOW, it's what Andrei has been repeating about adding rather than changing. Add new versions of the language in the same compiler, instead of changing the meaning of the current version of the language.

Could you use a compatibility layer? Say you have a module that is pre safe by default, you could have a component that annotates it so it's safety is explicit and then it can be passed to the new safe by default compiler.

Like the error with ints being truncated on assignment (cant remember what the proper name for it was), you could have a component that just inserts casts where needed, and then it could be passed to the newer compiler.

You wouldn't even need compiler versioning, the module could just declare the specific feature it's not updated to yet, and that would cause it to be run through the compatibility process.. Eg..

version(notSafeByDefault);