Is it time for D 3.0?

[Ecstatic Coder]

On Monday, 13 April 2020 at 09:17:48 UTC, Timon Gehr wrote:
> On 13.04.20 09:30, Kaitlyn Emmons wrote:
>> On Monday, 13 April 2020 at 07:13:37 UTC, Kaitlyn Emmons wrote:
>> 
>> 
>> In d3 can we make all functions and templates aliases to 
>> literals?
>> 
>> EG:
>> alias fun = (int x, int y) {
>>       // some fun >.>
>> }
>> 
>> alias funT = template(T){
>>       alias this = (T x, T y){
>>            // some T fun >o>
>>       }
>> }
>> 
>> Also can we merge the concept of alias this with the way 
>> templates work by declaring an alias with the same name as the 
>> template.
>> 
>> 
>> Also in d3 can we extend operator overloading to ALL aliases 
>> not just certain ones..
>> Eg i wana declare a namespace that overrides opDispatch
>> 
>> 
>
> Some of those suggestions are (to a large extent) backwards 
> compatible. The reason why operator overloading does not get 
> fixed is that there's a vocal group of people who think the 
> weird restrictions prevent "abuse". In reality, e.g., if all 
> you really wanted was to overload the '<' operator, opCmp is 
> just inefficient and error prone.
>
> Here's a small obvious improvement that would break code 
> massively: Introduce consistency between template/function 
> declaration and instantiation/call syntax, e.g.:
>
> auto fun!T(T x,T y)(T z){ ... }
>
> (One template parameter, curried function definition.)

While I agree that D could benefit from a new version with 
breaking changes, I think that it should focus on :
- keeping the language simple and easy to learn;
- integrating concurrency and a better garbage collection.

Languages like Go and Crystal have been designed with concurrency 
in mind (channels, etc) and an obvious "less is more" philosophy.

I use D mainly as a scripting language for file processing, and I 
really enjoy its current syntax.

I must say I'm deliberately using only a small imperative or 
object oriented subset of the language (slices, maps, regex, 
functions, classes, genericity), and **for my own needs** it's 
perfectly fine like that.

The only features I **personally** miss are related to Go-like 
concurrency with automatic parallelism, and an incremental 
garbage collector like in Nim and Unity.

So, if you want to shape a future version of D, maybe we could 
take some lessons from Go and Crystal, and instead of making D a 
better C++, it could make more sense to simply make D a better 
competitor to both these languages.

And MAYBE, we could then expect D to benefit from a very fast 
rise in popularity like those languages experienced when they 
were released.