The D Programming Language Vision Document

[monkyyy]

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
> Feedback is welcome.

>Metaprogramming

This section is... light on details and does little to clear up 
if you share my goals.

My current take on this is that I believe something with c 
feature ser + templates are the future, their foundation 
extremely shaky and awful with c++ appearing to make it powerful 
by accident, and that I should be wherever there is the most 
sugar to make it livable.

This will mostly involve me wanting an endless stream of new 
features to play with. But this contradicts the earlier section 
about simplicity and avoiding complex features.

Templates generally get ugly syntax, alias when you want to store 
first class type, static if's everywhere, _______traits; so Id 
suggests that's updated to be complex features that affect 
standard code but generally be open to experimental features in 
the template space; so that templates are generally going to get 
the short end of the stick design-wise but that but open to 
exploring out the foundation meta programming needs.

>Phobos and DRuntime

You don't comment on how v2 should be organized.

Currently, I believe to write functional-style code your going to 
import 5 different std libs and at least algorithm and range. Is 
that going to continue or be fixed?

I find the naming conflicts of "write" to be fairly awful and 
makes `import std;` undoable and even if you always write out 
your imports, studio and file are often going to be used 
together. Will that be fixed?

etc. etc.

the goals of std v2 probably could get its own document.

>Stronger ecosystem
>Community management
>All D users and contributors must feel comfortable participating 
>in the D community.
>There is a divide between those who believe in a "kitchen sink" 
>standard library and those who support a minimal standard 
>library backed up by a large ecosystem. We must find a balance 
>that makes sense for the D programming language.

Id suggest dropping std.experimental and get a std.community sort 
of thing going.

Where given snar did sumtypes as a subtype lib, then got into 
std.experimental, had to follow your process and whatever; and 
then finally got merged into std.

Instead, I'd suggest that snar makes an important lib, it gets 
noticed by the community, std.community.sumtype will point at 
snar's github either auto-downloaded or batched with compiler 
releases.

Have whatever legal disclaimer that std.community is not your 
responsibility, is kinda bad style to overuse and should be 
verified yourself. But have a curated list of community projects 
that have a soft thumbs up and that are easy to use. While 
dropping the std.experimental take that everyone says is a bad 
experience.