I've started writing some code for the first time in years; and the time away and distance really gave me some fresh perspective.

I started writing D because that's what I prefer, and I was shaken with the
realisation that the situation is just so much worse than I was ever
willing to admit to myself.
This is a small greenfields app, and I want to develop it quickly... so I
told myself that I'd try and use phobos.
...but it needs to run on microcontrollers, so I need to compile tiny code
and avoid GC and stuff. Better-C seems like a good plan, except that phobos
is just not compatible.
So, I figured I'd just use phobos and worry about fixing up allocation
semantics later when I want to release on hardware, so I can dev the
business logic on PC quickly.
Seems like a plan, except phobos is just BAD. API's are inconsistent and
mostly horrible. Nothing is intuitive, and also I realise I'm writing
myself into a huge overhaul when I want to forge a microcontroller build
later.

The biggest slap in the face though, which is honestly unexcusable 20 years on, is that D still has no real meaningful container library! How can a modern language not have a library of containers that let me organise my data?!

I realised that the best and most usable containers are actually the stdcpp containers I was implementing years ago! But the thing that held up that work was that we STILL don't have any way to implement move semantics! There was a SAOC project to implement rvalue references which would open D up to implementing container libraries; but sadly the author just disappeared one day never to be seen again. Nobody else ever moved on that issue.

Walter: It's been too long, there are still no containers, which is embarrassing and stdcpp is still blocked on this. I strongly urge you to drop whatever you are doing and finally implement an rvalue reference so we can *finally *implement move semantics, and with that, we can have a container library worthy of the language (I'll even start by finishing stdcpp which is blocked on that issue).

On Tuesday, 27 February 2024 at 02:28:32 UTC, Manu wrote:
> I've started writing some code for the first time in years; and the time away and distance really gave me some fresh perspective.
>
> I started writing D because that's what I prefer, and I was shaken with the
> realisation that the situation is just so much worse than I was ever
> willing to admit to myself.
> This is a small greenfields app, and I want to develop it quickly... so I
> told myself that I'd try and use phobos.
> ...but it needs to run on microcontrollers, so I need to compile tiny code
> and avoid GC and stuff. Better-C seems like a good plan, except that phobos
> is just not compatible.
> So, I figured I'd just use phobos and worry about fixing up allocation
> semantics later when I want to release on hardware, so I can dev the
> business logic on PC quickly.
> Seems like a plan, except phobos is just BAD. API's are inconsistent and
> mostly horrible. Nothing is intuitive, and also I realise I'm writing
> myself into a huge overhaul when I want to forge a microcontroller build
> later.
>
> The biggest slap in the face though, which is honestly unexcusable 20 years on, is that D still has no real meaningful container library! How can a modern language not have a library of containers that let me organise my data?!
>
> I realised that the best and most usable containers are actually the stdcpp containers I was implementing years ago! But the thing that held up that work was that we STILL don't have any way to implement move semantics! There was a SAOC project to implement rvalue references which would open D up to implementing container libraries; but sadly the author just disappeared one day never to be seen again. Nobody else ever moved on that issue.
>
> Walter: It's been too long, there are still no containers, which is embarrassing and stdcpp is still blocked on this. I strongly urge you to drop whatever you are doing and finally implement an rvalue reference so we can *finally *implement move semantics, and with that, we can have a container library worthy of the language (I'll even start by finishing stdcpp which is blocked on that issue).

I long suspected the lack of different containers is because the built-in fixed-size array, dynamic array, and associative array are sufficient for getting most applications up and running quickly for those who are fine with linking in Phobos and D-Runtime.
Perhaps in the same way that many folks using Python stick to lists and dictionaries for any small program. For folks with C++ backgrounds, more containers for performance trade-offs would indeed be nice to have to select from (e.g. unordered_map, map, etc.).

std.container (as you probably know, but others may not so I'll link it here - https://dlang.org/phobos/std_container.html) does have a few data structures like std.array as a start (API similar to std::vector). I agree the container list could be expanded and would benefit greatly from move semantics (i.e. using rvalue reference) -- this is probably the one thing I miss from D in C++.

I don't know the history regarding rvalue reference with D, but I did find [1][2] useful. Read through the dip and watching the talk as we speak.

Curious your thoughts on containers:
1. Should we effectively mirror the cpp containers?
2. Add more specific ones (e.g. std.container.concurrent.array? std.container.lockfree, std.container.intrusive)?
3. Add more (e.g. std.graph, std.directedgraph, etc.)?

^ Question above are to help kickstart some of the discussion as I hear about rumblings of Phobos 3.

Regarding the API:
I believe there are rumblings of allocators here. Wonder if we again take the C++ approach?

e.g. `auto arr = Array!(int, allocatorType)(1,2,3);
// second parameter we specify allocator type/policy/strategy.

I also *think* some proposal is in progress here -- others can comment to confirm.


[1] Found your previous dip here. https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
[2] Andrei's talk 2019 talk: https://www.youtube.com/watch?v=aRvu2JGGn6E

We are aware of all of this.

Move semantics are still on someones radar (I've forgotten who), it was wanted by Weka.io. The problem is the design of move semantics itself and motivation. Neither of which are contingent on Walter. Wait for DIP process to reopen shortly.

A new standard library is currently in the works of being planned.
It is lead by Adam Wilson who has buy in from both Walter and Atila.
This ties into a new planned edition system for ensuring stability of language.

https://github.com/LightBender/PhobosV3-Design

Shared library support has improved quite a bit, dmd is still WIP for druntime, but Rainer has gotten dmd's core capabilities working now.
I believe I have successfully designed the user experience surrounding it, although that has been implemented or accepted just yet. Which will help prevent linker errors in all common scenarios.

Hi Manu! Good to hear from you!

We do have a DIP on move semantics I wrote a while back:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md

but other demands always seem to get in the way. I'd appreciate your advice on the DIP.

> I realised that the best and most usable containers are actually the stdcpp
> containers I was implementing years ago!

It's not surprising that the containers you worked on are the most useful to you!

I'm curious about what containers are needed for a microcontroller?

Since an overhaul of Phobos is underway, I'm especially interested in your takes on unintuitive/horrible aspects. I don't want to bias your response with my thoughts on the matter.

On Tuesday, 27 February 2024 at 07:20:46 UTC, Walter Bright wrote:

> We do have a DIP on move semantics I wrote a while back:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md
>
> but other demands always seem to get in the way.

ImportC was not a demand!

On Tuesday, 27 February 2024 at 02:28:32 UTC, Manu wrote:
>
> Walter: It's been too long, there are still no containers,

Btw will be interesting to know the list of containers you demand.
Because many times people spoke about containers, but there are hundreds of them (as Mike mentioned some families. I would also add probabilistic containers to the party)..

People from industry are usually talking like "containers from std are good only for simple things. If you want to solve some real and hard problem - you have to implement your specific/custom version of the container exactly for your particular problem set".

So containers from std should be just simple to use and integrated well.. but if you need performance/low memory footprint, you will implement it from scratch anyway.

And I think it is worth to mention https://code.dlang.org/packages/ikod-containers - nogc, safe containers that worked well for me. It has a few structures, but could be base for other implementations.

@Rikki:

This answer sounds like "come back in 10 years" :)

On 27/02/2024 9:44 PM, Sergey wrote:
> @Rikki:
> 
> This answer sounds like "come back in 10 years" :)

Lol yes, if you want it to be all tidy with answers to many use cases with clear solutions it's like that.

If however you want hope that things are going to change and we won't keep doing what we've done, then it is hopeful too!