Beyond D2

Motivation

This can be used as a centralized place to discuss parts of D2's design that are controversial or suboptimal in retrospect. Also discussed here are features that would be worthy of consideration in a hypothetical successor for D2, let's call it D3 (or E!). This page came up from email thread http://forum.dlang.org/post/ygmtislwwhfftiqrujan@forum.dlang.org.

Desirable properties:

• move features & special syntax from language to library whenever possible
• increase syntax & feature orthogonality (no special case for strings, prefer explicit to implicit)
• increase DRY-ness of code
• design grammar to be easy to parse and provide reference compiler as a library
• feature AST macros to simplify a number of constructs
• prefer automatic attribute inference over manual annotation

Staying as close as possible to D2's syntax is not necessarily a goal, as automatic translation tools can easily take care of this: clarity of target language is a more important role.

Features to drop

• remove language builtins (sort / reverse / foreach_reverse / complex numbers), see http://dlang.org/deprecate.html

• get rid of opSlice/opSliceAssign etc:
  • a..b is instead syntax sugar for a Slice object:
  • rationale for opSlice, opSliceAssign, vs a..b being syntax sugar for a Slice struct? http://forum.dlang.org/post/mailman.551.1365290408.4724.digitalmars-d-learn@puremagic.com

• get rid of C-style expression lists in parenthesis; these would be reserved for tuples

• strings: stop conflating range of code points with range of code units:
  • "foo" represents a range of code points
  • "foo".rep represents a range of code units, eg: immutable(char)[]
  • This would remove a *lot* of special case code in phobos and make it easier to write generic code, eg, would remove need for distinguishing ElementType vs ForeachType
  • I've discussed this in email:"iteration over a string"
  • Andrei mentioned it here as well: http://forum.dlang.org/post/l3h49k$b6$1@digitalmars.com

 "It is my opinion that a better solution exists (in the form of making representation accessible only through a property .rep)"

• stop conflating paths with strings; would make a lot of code safer and cross platform; would still allow implicit conversion via alias this.
  • http://forum.dlang.org/post/op.wx7lqwvx54xghj@puck.auriga.bhead.co.uk + code

• get rid of @property

• get rid of /**/ since we have nesting /++/

• pragma(msg,) shouldn't insert "\n" (easy to add, impossible to remove)

• remove 'version(foo)' in favor of: static if(versions.foo), which would be more orthogonal. versions is an implicitly imported module that contains (for example):

 version.osx=true 
 version.posix=true
 version.windows=false
 //plus other versions defined on command line
=> no new syntax 

Safety

• default is @safe/@pure ; attributes are automatically inferred and exported in di interface files

Separate Compilation

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

Features to add

• AST macros
  • proposal: https://dl.dropboxusercontent.com/u/18386187/ast_macros.html#scroll_to_here
  • would enable many features; eg:
    • supersedes: "proposal: a new string litteral to embed variables in a string" http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com
    • supersedes: "feature request: __ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___)" http://forum.dlang.org/post/godmqvdatmjvkyjybkoa@forum.dlang.org

• python style named parameter arguments

• Yield return

• R-value references

• Safe references

• language syntax for tuples; unify syntax for compile time tuples with runtime tuples
  • could follow DIP32 but use (a,b) syntax instead; we would get rid of C-style expression lists to enable this

Arrays and Ranges

• multidimensional indexing and slicing:
  • https://github.com/D-Programming-Language/dmd/pull/443
  • http://homepages.uni-regensburg.de/~nen10015/documents/D-multidimarray.html

• builtin slices with begin..end:step or begin..end..step

Compilation

• proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com

• allow JIT code, to allow runtime eval statements (for REPL etc).

• 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

Tooling

• Incremental compilation support in rdmd: http://d.puremagic.com/issues/show_bug.cgi?id=9673
• improved dmd/rdmd command line: http://wiki.dlang.org/DIP41

Syntax changes

• full UFCS support: foo.mixin, foo.assert, foo.stringof, foo.typeof

• More lightweight syntax:
  • Go style a := b meaning auto a = b

• • semi-column optional

• • Go style lightweight if/while/etc expressions that don't require () around the if statement:

while x>=0 {...}

Language interop

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

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

---

Page originally created by Timothee Cour on 11/09/2013; copyright: public domain. TODO: add discussion/DIP/webpage links to each item