Beyond D2

Motivation

This page can be used as a centralized place to discuss parts of D2's design that are controversial, undesirable or that could be improved, including those that are too late to fix in D2. Also discussed here are features that would be worthy of consideration in a hypothetical successor for D2 (D3? E? ). This page came up from email thread [1];

Questionable design choices

• is virtual by default a good idea with separate compilation model?

Features to improve

• improved dmd/rdmd command line: [DIP41: dmd/rdmd command line overhaul]

Features to drop

• can we get rid of C-style expression lists in parenthesis; these would be used for tuples
• can we get rid of @property?

Features to add

• AST macros
  • would enable many features; eg:
    • supersedes: "proposal: a new string litteral to embed variables in a string"
    • supersedes: "feature request: __ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___)"

• Compiler as a library (eg llvm/clang toolchain)

• Compiler written in D2, and then bootstrapped from their as done in rust and many other languages

• python style named parameter arguments

• Yield return

• R-value references

• tuples

More controversial features to add

• store code as AST,
  • The 1st idea is to get rid of styleguides completely and allow people to read/write code with their preferred style. Codes gets stored and exchanged as AST; clients read the AST and converts it on the fly as source code in the user's preferred formatting.
  • speeds up compilation: only currently modified code needs to get translation from source to AST
  • More future proof and eases refactoring

• Allow transparently including C headers in code as in Go; could use swig behind the scenes

---

[1] Related email thread: 'Maintain notes for D's successor? [Was: Re: Why the @ in @safe? & UDAs]'