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.
