New std discussion thread

[crazymonkyyy]

Whos wants to work on what? Where is it? How much are ranges changing?

[aberba]

What are ranges should change? @crazymonkyyy

[crazymonkyyy]

I would like to kill the range hierarchy for requiring you to implement double linked list functions and 20 other functions to make an array work and believe there should be an index in there somewhere

[quickfur]

Changing the range API now would break a lot of existing code. I'm not 100% against it, but it has to give reasonable benefits to justify such a breakage.

One thing that could alleviate the problem is to find a better way to express range operations that allows you to be more concise. But if you want to provide bidirectional iteration, I don't see any real way of avoiding having to implement methods for accessing and iterating the front/back ends of the range. This is really only needed for ranges that don't implement opIndex; IIRC Phobos already automatically gives you bidirectional range operations by default once your range implements opIndex, so if you're feeling lazy that's all you need to do anyway.

[crazymonkyyy]

IIRC Phobos already automatically gives you bidirectional range operations by default once your range implements opIndex,

what?

[adamdruppe]

Changing the range API now would break a lot of existing code. I'm not 100% against it, but it has to give reasonable benefits to justify such a breakage.

We can keep the legacy behavior if you import the old modules and change the protocol if you import new ones. Provide an adapter template for converting one to the other. So it is possible to do without massive breakage as long as we provide a transition path.

But I'm skeptical of the value too. Of course, I think the main benefits of ranges are actually the basic input ranges - you hit diminishing returns fast as you add more and more features. Regardless though just remember we can change things if we want, and .... my preference is to minimize breakage from upstream D (at least without an easy migration path to a clear win), it is still on the table if the benefits are sufficiently compelling.

[quickfur]

Yeah, I honestly don't use things like bidirectional range very often. Theoretically such things exist, but in practice they are quite rare, and even when you have such a range it's rare that you want to make use of the bidirectional features anyway. Usually if you need anything more than a forward range, you should just implement opIndex and call it a day. Bidirectional ranges just don't seem to bring enough benefits to justify the additional complexity.

[quickfur]

I did not hear of this. What's changing with ranges?

[adamdruppe]

There's been discussion on the discord looking at possibly redesigning ranges, including some discussion about going back to some of the const range concepts. One idea was to add a possible tail to types that you can separate from const:

const(MyRange)~ tailConse;

and the const would then be passed in to reference types inside the struct as a tail const thing too. Would also work on classeS:

const(Object)~ tailConst;
tailConst = rebind; // fine

stuff like that.

[quickfur]

Hmm. I vaguely remember being involved in the discussions surrounding this.

What it basically entails is a language-supported construct in which const MyTemplate!(T) is treated as equivalent to MyTemplate!(const T). Not sure exactly how this would be implemented, haven't worked out all its consequences yet. But once you have this, tail const ranges become an easy consequence. But this construct will be much more powerful: it will let you implement tail-const containers in general, that today we can't implement. And it may solve some longstanding problems more widespread use of const as well.

If we do this right, we might be able to kill inout with fire as well...

[crazymonkyyy]

bumping; phoboes v3 is officially useless(even trivail breaking changes need to be justified by pulling teeth, they will copy v2 function by function over years and have nothing different)
if anyone is interested in changing the range api in a new algorthims/data stuctures lib, ping me somewhere

[bachmeil]

Yeah, I was disappointed to see how hopeless the situation is. I responded to someone else that it wouldn't be a good idea to add a web server, JSON library, XML library, etc. initially because that would be too big of an undertaking. Adam Wilson jumped into the conversation, called me arrogant, told me to shut up, and then wrote out a bunch of arguments that showed he had no idea what he was talking about. It looks to me like it's going to be yet another one of those things that starts with big ideas/hype but no realistic plan for completion. A few years later people will start asking "Where's Phobos v3?" and they'll get shouted at in response. Convincing Adam Wilson of anything will be harder than convincing Walter.

I've basically given up on D at this point. The language is good enough for 2024, but I'd be lying if I said it has a future. I've been seriously considering jumping ship to another language after seeing how they're proceeding with Phobos. This fork gives the language a chance, but it's going to need to attract a lot of contributors.

[crazymonkyyy]

I've basically given up on D at this point. The language is good enough for 2024, but I'd be lying if I said it has a future.

I think science in general is dead, and computer science was one of the last the rot(which is why we had tech booms after the 80's); I agree with stepov and andrie that you need templates for the best possible algorthims

the template languges are c++, d and rust; rust is a meme and doing nothing
c++ has some of the same problems even if they have mircosofts manpower
There airnt many interesting langues, or many languges with reasonable compile times

heres my current proof of concept lib I was making cause I need something and for agruements https://github.com/crazymonkyyy/raylib-2024/blob/master/lib/minstd.d
its hard and not a one man job

[adamdruppe]

it wouldn't be a good idea to add a web server, JSON library, XML library, etc. initially because that would be too big of an undertaking.

but OpenD already comes with all those lol

Though yeah, getting contributors over here isn't gonna be easy. There's a lot of people watching but odds are most of them are also skeptical and won't want to make any kind of commitment unless it looks strong and that is a bit of a chicken and egg thing. Still, we'll see, I'll eventually web the website finished and stuff like that and... I don't really like spamming the internet with stuff but it might be worth keeping up the attention and seeing if there's any new people who can get interested.

Even if it works tho it is gonna take a while to get anywhere.

[bachmeil]

but OpenD already comes with all those lol

That's just it. Those libraries already exist, and they're not open to reusing what's already out there. It's all about taking on a fun engineering challenge whether or not it pushes the language forward.

getting contributors over here isn't gonna be easy

Probably true, but maybe not if they bungle the Phobos update. I can't be the only one shaking my head (at least one other person is).

Even if it works tho it is gonna take a while to get anywhere.

I think cleaning up some of the low-hanging fruit, like eliminating the need for Dub and automatically generating DLL bindings on Windows, will show what's possible with a project focused on usability rather than fun (over)engineering challenges. There's a big advantage to having the easier compiler, because you get the new users.

[bachmeil]

There airnt many interesting langues, or many languges with reasonable compile times

I need a language for numerical computing for academic research. Languages like C++, Go, Rust, Zig, Nim, etc. bring nothing useful to the table for me, and they'll always be inferior to D for my purposes. My choices right now are:

1. Julia. Makes the most sense on the surface, but there are some fundamental issues, including the need to build a lot of the infrastructure I already have with D.
2. OpenD. Hard to judge at this very early stage.
3. My own version of D, which adds some features to the D syntax and prohibits a few things that shouldn't be done, inspired by what Typescript did for Javascript. It would eliminate the need for explicit Dub usage and have numerical computing functionality out of the box. I've been playing around with this for a long time, years before this fork. The obstacle is the time needed to learn the D compiler's parsing and semantic analysis.

[whitebyte]

Bump. Are there any plans of doing something with std.signals? It's honestly just awful. I tried them and quickly switched to DlangUI builtin signals, which is OK for apps that use DlangUI, but not for others. The fact that a signal can only be a class member and only added through a mixin is IMO a very bad design

[adamdruppe]

What would your ideal usage examples look like?

[whitebyte]

Well I'm pretty happy with dlangui signals so far (https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d). The only caveat is Caution: unlike std.signals, does not disconnect signal from slots belonging to destroyed objects

[adamdruppe]

ok yeah, that is just a list of delegates. stopping on return value feels weird to me, i think i'd prefer to only allow void, but otherwise it is pretty straightforward.

That caveat is there to simplify the impl and allow it to take non classes. The reason the std.signals only allows classes is that it depends on the GC finalizer to disconnect and that won't happen with the other ones. There's other concerns too like passing a struct method then returning from the function is gonna bork that but.... i still think the simple array is the best way so basically that same dlangui thing.

[whitebyte]

stopping on return value feels weird to me, i think i'd prefer to only allow void

I'm cool with that

[GrimMaple]

Well I'm pretty happy with dlangui signals so far (https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d). The only caveat is Caution: unlike std.signals, does not disconnect signal from slots belonging to destroyed objects

FWIW, if you think they are good enough, you can just copy & paste dlangui signals to https://github.com/opendlang/d and PR -- the license is compatible