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

On Monday, 13 April 2020 at 07:30:54 UTC, Kaitlyn Emmons wrote:

In D3 can we PLEASE merge class and struct.. such a bad design right there.. we have alias this and mixins and crazy shit to make structs do anything we want and then we have classes which honestly could be implemented at this point as a struct template in library..


Also in D3 can we make all type voldemort types except for fundamental types like int/void ect..

Just embrace the inference.. it the direction D wants to go anyways

On Monday, 13 April 2020 at 07:43:10 UTC, Kaitlyn Emmons wrote:
> Also in D3 can we make all type voldemort types except for fundamental types like int/void ect..
>
> Just embrace the inference.. it the direction D wants to go anyways

By that i mean, define types as the return from a function.. and scrap constructors all together ..

alias SomeStruct = (int x, int y){
      r = struct {
           X = x;
           Y = y;
      }
      return r;
}

On Monday, 13 April 2020 at 07:13:37 UTC, Kaitlyn Emmons wrote:
> Oh and in D3 can we clean up "is"? Its like the syntax version of mom spaghetti.
> D2 has fallen into the same trap c++ has.. never cleaning up old bad features!

You can't be serious... Just grep for "Removed" or deprecated in the changelog, you have a hit on almost any release. v2.091.0 removed class deallocator (provided, they already error-ed out before). 2.089.0 deprecated some case of shadowing, along with a few change which could break user code (e.g. mixin + extern(C)). And the release before that, the list is just too long to cite: https://dlang.org/changelog/2.088.0.html

And that is just language changes. Runtime and Phobos receive a lot of cleanups too.

> PLEASE BREAK MY CODE!! A BETTER LANGUAGE IS WORTH CODE BREAKAGE..

"Better" is not an absolute metric, unfortunately. What is better for you will be worse for someone else. I've seen it repeated countless time, someone tries to get rid of a language feature that is not "worth their weight", only to have someone that uses this feature come up with an argument why it is worth its weight.

We had a few cases were language fixes were *definitely* worth it. The `case`-implicit-fallthrough deprecation comes to mind immediately. We had other cases were, while the change was welcomed, it forced *a lot* of downstream users to change their (working) code. That's not something we should do too often.

> how is that not obvious.. if we cared about not having to rewrite code we would all still be using cpp.. just BREAK D2 already!! DAMN.. its old and getting stale..
>
> I just wanted to say that cus this thread will most likely die out like the n other threads about this topic.. nothing ever gets done.. even though there has been strong desire for D3 in the community for like 6 years now or something.. WALTER THIS IS ON YOU! MAKE THE DECISION TO KILL D2 PLEASE WE BEG YOU <3

This is so out of touch with the reality of software development it sounds almost like a troll.

On Monday, 13 April 2020 at 08:01:49 UTC, Mathias LANG wrote:
> This is so out of touch with the reality of software development it sounds almost like a troll.

I been following this community for like 6 years now and i remember when i joined people were asking for D3.. the troll is the fact people still discussing it and nothing has been done

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

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.

On Saturday, 11 April 2020 at 04:07:53 UTC, Kaitlyn Emmons wrote:
> So in D3 can we scrap the CTFE engine all together and just write a real D interpreter!
>
> I suggest this actually be written FIRST before a compiler.. and then make compilation a feature of the interpreter! Flip the paradigm and unleash the true capabilities of meta programming!!

If I were designing and implementing a language from scratch right now, that's exactly what I'd do.

On Monday, 13 April 2020 at 15:27:46 UTC, Atila Neves wrote:
> If I were designing and implementing a language from scratch right now, that's exactly what I'd do.

Here is one funny approach:

1. implement an interpreter/JIT
2. run it
3. create a core dump when hitting the first I/O instruction
4. use a program that turns the core dump into an executable

Voila. Compilation finished.

;""}

On Monday, 13 April 2020 at 08:47:23 UTC, Kaitlyn Emmons wrote:
> On Monday, 13 April 2020 at 08:01:49 UTC, Mathias LANG wrote:
>> This is so out of touch with the reality of software development it sounds almost like a troll.
>
> I been following this community for like 6 years now and i remember when i joined people were asking for D3.. the troll is the fact people still discussing it and nothing has been done

I'm c++ programmer and not familiar with Dlang enough. I only observed language features
and time over time read forum discussions about dlang past and future.

I will try to summarize many different opinions about D.

Marketing and purpose.

Some people wrote posts about problems "to sell" D to programmers like modern languages(Rust, Go, Java). It's not clear which niches Dlang was designed to cover.

It can't be used for high frequency trading or other niches where performance is matter, because has dependency on GC in language structure and infrastructure (classes).
Bad support for non-gc methods in standard library. But there are cool features for template metaprogramming, mixins, good compile time evaluation support. Cool reflection is also big thing(c++ just on the road, but D has support reflection much earlier).

On the other hand there are many general purpose languages with GC(Java, C# etc). And why programmers should take D instead? Yes, there are no corporations like Oracle, Microsoft behind D and small community. Oldstyle "stop the world" GC does not add popularity to Dlang.

I also saw some programmers use D as scripting language or language for prototypes because you can program, compile fast and good syntax, infrastructure(packet manager, build system) are helpful.

In fact dlang is old, but still unpopular.

Approaches and leadership.

There are many memory management features like refcounting, gc, owner/borrow semantic from Rust in D. However these features are not integrated in language, libraries. May be choose one and design, implement, test it to be ready? Because community is small and everyone do what interested in and try to move lang in different ways. I see that like a "box of unfinished projects".

Were there any discussions about dlang fork?

On my opinion Dlang has features to be popular system and scripting language. It needs not many cool unfinished things, but well implemented. And lang needs development plan with priorities.

P.S.
Sorry for my bad english.
I wrote all this because i'm tired to write simple things hard way in c++, but does not see any good alternatives.
And as i know initial purpose on Dlang development was re-engineering of c++.