On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad
wrote:
1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.
That's very vague. Unless you have concrete cases along with
possible solutions, nobody can follow your "plan".
6. Extend support to critical platforms like WebAssembly/asm.js
I agree. Nim are doing a good job at that as far as I know.
I have some prototypes for my own use, but not sure what
relevance that has? Pull requests would require decision making
and policy changes, and be utterly pointless without it.
Design/policy changes will have to start with the project
leaders, that's the only way. End-users do not directly affect
language features.
In D you can make a contribution as a user, but it has to be
concrete and backed up by valid arguments. General statements and
common places won't change anything.
Unlike Go and Rust, D has grown out of experience with
programming in general, it's based on what worked in other
languages and what didn't. Go and Rust address certain narrowly
defined areas (Go more so than Rust I think). Given D's history
there is, of course, some waste lying around (as is in any
software after ~10 years) that has to be cleaned up and I would
welcome any concrete, practical input from your side. Start with
simple things first. Any hands-on help is welcome.
