Hopefully that includes proper built in Tagged Union, non OOP people need that otherwise we are stuck in C's era of programming

We can, and we should do better (import std.sumtype is embarrassing when other languages have it built in without template soup, i still refuse to touch it)

Awesome! hopefully they become built in and more integrated

This one will be tricky, done well means it scale from 0 to hearo, meaning i should be able to use it without the need of a GC

Hopefully it's not one of these import std.concurency: async, await, frame;

That's awesome to hear, metaprogramming is one of D's strength

On the tooling part:

A language server is long overdue..

https://pkg.go.dev/golang.org/x/tools/gopls
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html
https://rust-analyzer.github.io/

The one we have right now (serve-d) is nice, but uses the same backend as every other projects (DCD), and this project haven't evolved in years, the moment you step into template territory, it falls short T get(T)() { return T.init } auto myInt = get!int; it'll not know what myInt is.. wich is a shame when that feature is D's signature

A better debugging story is also essential, without having to use external (incomplete) files like: https://github.com/Pure-D/dlang-debug

msvc, clang, gcc: they should know what D types are, and they should be able to step properly into D syntax without the need of the user to do weird things

Zig is a young language and yet has a better debugging story

Onto the phobos/druntime:

That's nice to hear that the goal is to reduce inter module dependencies

Core APIs should be made independent and VERY simple, this allows them to be easily ported to other platforms, easier to extend

I am sad that no word on the Allocator API, moving forward i personally think APIs that use memory should be required to ask for an Allocator and do their allocation using it, and only it

A default GCAllocator could be used if none provided, this allows users of all kind to enjoy the APIs without having to complain about the GC or their inability to integrate the APIs in their game engine for example

--

Overall this document is super encouraging, thanks for making it, D finally have a long term roadmap!

Hopefully this allows everyone to align and coordinate their efforts

I wish i could help, i tried, but language programming is definitely not my cup of tea, hopefully you guys are not sick of my suggestions

A language is about allowing user to express their intent, making it easier for them to achieve that goal is a priority, compiler internal difficulties should not prevent language improvements, compiler internals doesn't exist from the user point of view

On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:

GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo

You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone

Which becomes a strength again!

On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:

Sure, I agree with you. I think I was just being pedantic. :)

On Tuesday, 5 July 2022 at 11:49:20 UTC, ryuukk_ wrote:

It should not be resolved like this. Functions that does not return memory should just be nogc.

Functions that return allocated memory that are nogc should use RAII and prevent GC pointers from pointing to it. So you need a new type system.

Or just overload on @system.

You also want to get rid of destructors on GC objects and replace it with a finalizer that isnt sensitive to order.

On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:

Feel free to consider it a strength, when in reality it is a flaw against established market players.

https://www.microej.com/

https://www.wildernesslabs.co/

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.astrobe.com/

On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote:

People also use nodejs and npm, what is your point?

If you invest in the future you must take the pragmatic approach and give options

Those are not Oracle's products, companies took the JVM for what it is as a foundation and built their products

They haven't picked the default Oracle JDK and the default concurrent GC

D should enable similar stories with what it has and can provide, read on the challenges TinyGO faced, if D provides the tools for companies to experiment with it, with a proper set of efficient and minimal Core APIs, that alone makes it a proper and more efficient alternative solution

On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote:

Thanks for the explaination. I agree with all of this.

I think we should get into habit to start a new thread for branching discussions with much lower bar than we currently do. Myself included.

On Sunday, 3 July 2022 at 20:16:35 UTC, Ola Fosheim Grøstad wrote:

It is pretty easy to convert those to native endian and back with functions in std.bitmanip. I recently did so to have a program to recognise files in all of those five.

Also the Phobos functions are of high quality. They work extremely well with the range API (other than having to live with autodecoding), they are well documented and they are comprehensive enough for almost any task. I don't recall having ever considered another library for handling Unicode.

And I think there is still pretty much value in handling UTF-16 strings because that's what many other languages use. With the current vision, Phobos V2 won't handle UTF16 in place. We'll have to convert it to UTF8 before manipulation, which is probably not optimal. And if the string functions have to deal with two formats anyway, also supporting UTF32 on top of them probably does not make much difference.

That said, I don't feel strongly about this because if we kick UTF16 and UTF32 functions out of Phobos, they still are presumably available in Undead.

On Wednesday, 6 July 2022 at 15:43:25 UTC, ryuukk_ wrote:

My point is that GC hate is not a fixed problem in D, and the vision does little to fix it.

Meanwhile the language communities that embraced GC in embedded deployment, are at least 20 years ahead in production deployments versus D, where no GC keeps being a reason to rejoice, like the the comment I replied to.

The future was when Andrei book came out.