On Fri, May 19, 2023 at 06:37:05PM +0000, IGotD- via Digitalmars-d wrote:
> On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:
> > 
> > There are some features that are essential to be able achieve the vision D wants to achieve (pay as you go)
> > 
> 
> I think the problem with the D community is that they are not bold enough.  If you have an idea just do it, don't wait for any approval from Walter or the maintainers because they are going to say no anyway or not saying anything at all. If you have made a PR that is popular, the maintainers have no power to stop it which will only lead to that D eventually will be forked.

+1. I was just a random nobody who found D online, ran into problems, and decided that instead of waiting for somebody else to fix my problems for me, I'll fix them myself and submit PRs.  Then when my PRs were getting ignored, I pestered the maintainers until they responded. When they didn't respond I made a louder noise.  Eventually, I made a loud enough noise that one fine day Andrei suddenly decided to give me the keys to the kingdom, so to speak, and I became one of the Phobos committers.  Haven't really been doing much these days with that, though, but still.  Taking the initiative is what will change things; sitting around hoping somebody else will do the work generally ends in disappointment. Besides, fixing it yourself will get you the solution faster (there was a period of time I was using my local modification of the dmd toolchain 'cos upstream was b0rken and I couldn't wait for the fix to be officially merged), and on top of that earns you creds with the maintainers and the community.


> One problem with this is that writing compilers requires knowledge but if you have the knowledge, don't wait for Walter (he's busy with importC anyway) or the maintainers. If you are waiting for some plan, approval whatever, just forget it. Instead work with the community and the community can sort out what changes works and which don't.
[...]

I'd say, if you don't have the knowledge, why not spend the time to acquire it?  Regardless of the outcome, this knowledge will be very useful to you wherever you may end up. Understanding how compilers actually work will help you understand why programming languages are the way they are, and how to exploit this to your own advantage instead of chafing every time something doesn't work your way.

Don't sit around waiting for the bull to end up where you want it to; grab the bull by its horns and *make* it go where you want.


T

-- 
When solving a problem, take care that you do not become part of the problem.

On Friday, 19 May 2023 at 19:03:42 UTC, H. S. Teoh wrote:
> 
> ..
> Don't sit around waiting for the bull to end up where you want it to; grab the bull by its horns and *make* it go where you want.
>
>
> T

+1

And here is an example (of someone taking the bull by the horn):

https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

Now, the motivations for the person that did this, was just so see 'how it could be done', and not necessarily because that person wanted that feature. Nonetheless, stagnation on a long, and very fiercly discussed issue, over many years, finally made some progress.

In the meantime, Walter and Magic Mike just made videos about how D will never, ever, ever, ever... allow you to have class private members within a module (like I can do in Swift).

Fortunately, somebody followed the Nike Theory : Just do it!, and.. dada! It was done!

Now, unfortunately, D has no 'experimental' release, so programmers who like how this *helps them* better express their code, never got a chance to use it - and still don't.

It was never a wild, ridiculous concept either. Just the option to have a private member to a class within a module! I mean... jezzzz! And soo..... much obstruction, like I've never seen before, on any issue, ever discussed in the D forums!

All it took for it to happen, was someone to 'Just do it!'.

I cannot recall IVY being a motivating force behind it.

Please, more action, less obstruction, and ... less talk about ideal visions of oneself.

That's the end of my gripes... for now.

On Saturday, 20 May 2023 at 00:49:09 UTC, Theo wrote:
>
> Now, unfortunately, D has no 'experimental' release, so programmers who like how this *helps them* better express their code, never got a chance to use it - and still don't.
>

This is exactly what I would think would be helpful, a new branch for experimental and disruptive features. A branch that is outside the control of the maintainers or at least they don't care about it. A branch where D can evolve and diverge from D2.

The best would be if the branch could be located at the official D repo at github but safest would be it should be hosted in a separate fork. The question is how we can replicate the CI system in order to suit the needs.

On 5/19/2023 4:43 AM, GrimMaple wrote:
> Unfortunately, big compiler changes, like mentioned above deprecation of alias this,

Maybe we should un-deprecate that. I appreciate your feedback on it.

> or ImportC for that matter, weren't hidden behind a preview switch. Heck, ImportC didn't even go through DIP process!
ImportC didn't go through the DIP process because it is not a D language feature - it's a compiler feature!

On 5/19/2023 4:43 AM, GrimMaple wrote:
> Besides that, D suits game developemnt really well, thanks to its easily controllable garbage collection and access to low level features to speed up your code when necessary. And while the GC implementation is sometimes lacking, just having a GC that you can decide when to run, gives you a great coding speed advanatage over C/C++, where you would spend most of your time thinking about proper memory management (shared pointers aren't proper memory management).

The GC has a surprise advantage that nobody really thought of. It enables much more CTFE to be done. It's hard to do meaningful CTFE without memory allocation, and GC is perfectly suited to that task.

On 21/05/2023 8:33 AM, Walter Bright wrote:
> The GC has a surprise advantage that nobody really thought of. It enables much more CTFE to be done. It's hard to do meaningful CTFE without memory allocation, and GC is perfectly suited to that task.

It makes a lot of sense looking at it in hindsight.

The GC is just a fancy pants memory allocator after all.

So the fact that we use the "GC language extensions" in CTFE is kinda irrelevant. It could just as easily work with malloc + free if somebody wanted to implement it.