Last update November 8, 2015

Language Devel



There is a lot of discussion about where D is heading and how it is going to get there. And what you should know is all this discussion occurs on the newsgroup. Don't expect the content on the Discussion and Ideas page to be the most up-to-date. The D Conference page contains information related to past and possible future conferences related to D.

If you are interested in keeping a general idea about what is happening you will find the Planet D's RSS feed to be very nice as it follows many D related blogs. Another area that has been getting some movement has been on reddit D_Language

Table of contents of this page
History   
Roadmap   
Tool chain issues   
DMD Compiler Stability   
Standard Library Development   
Future Directions   
Contributing   
Specification   
DMD   
Related   

History    

"D was conceived starting in December 1999 by Walter Bright of DigitalMars as a successor to C and C++, and has grown and evolved with helpful suggestions and critiques by friends and colleagues. Take a look at the D language."

Roadmap    

The development plan for D involves three relatively independent components: toolchain issues, compiler stability, and standard library development. The near term priorities for each component are:

Tool chain issues    

  • 64 bit DMD compiler (released Feb 2011 for Linux [DMD 2.052], June 2011 for FreeBSD [DMD 2.054] Dec 2011 for OSX [DMD 2.057])
  • Windows linker ('Optlink') issues
  • Shared library support
  • Debugger support
  • Other tool-chain issues S

DMD Compiler Stability    

Bugs are fixed according to the following priority list:

  1. Wrong-code regression
  2. ICE regression
  3. Wrong-code bugs marked 'blocker' or 'critical' (typically involving back-end code generation)
  4. Compiler segfault
  5. ICE or wrong code, non-obscure situation
  6. Error messages with missing line number
  7. Regression, non-obscure (most recently introduced get highest priority)
  8. ICE or wrong code, more obscure situation
Additional effort will be given to the following areas:

  • Incomplete functionality - particularly bugs associated with:
    • struct destructors
    • associative arrays
    • alias this
    • inout
    • @safe
  • Blockers for standard library development
  • Discrepancies between the compiler and "The D Programming Language"
Known language changes which must occur before language is considered 'final':

  • alias this, inout, SafeD? aren't fully implemented, and will probably require language changes/clarifications.
  • Built-in struct functions (opEquals, toString, etc) need more thought.
  • Possible changes to modifiers for function parameters (in, out, inout, ref, auto ref)
  • Work last kinks out of qualified constructors and destructors
  • Low-level threading support with shared; change language to match TDPL (that means e.g. shared/synchronized methods is at class level, not method level).
  • [DONE] Minor touches such as user-defined operator '$', @disable etc.

Standard Library Development    

There is currently no plan to freeze standard library development. Several modules are scheduled for deprecation in the short term.

  • Define allocator abstraction
  • Overhaul std.container to use it; add classic containers to std.container (doubly-linked list, hash, deque)
  • Define streaming abstraction
  • Add high-level networking
  • Redesign/Replace
    • std.json
    • std.process
    • std.stream
    • std.variant
    • std.xml
  • Many other changes and additions
In order for something new to get accepted into the standard library it must be reviewed by the community and discussed on the D news group. The review process followed is the same used by the boost library http://www.boost.org/community/reviews.html

There is a specific page for the status of review queue.

Future Directions    

These are issues which Walter at one time agreed will happen.

Known D1.0, applies to D2 as well:

  • [done, DMD1.048 and 2.033] Unimplemented features -- contract inheritance.
  • [done, DMD1.072 and 2.057] Most operations should work in CTFE (classes, exceptions, etc).
  • Private, protected, package must work! ( Bugzilla:313, Bugzilla:314, and Bugzilla:143)
Known D2.0, Language:
  • [DMD 2.036] Pass static arrays by value.
  • [DMD 2.036] Move AAs from language into library.
  • [DMD 2.037] Safe D (@safe, @trusted, @system)
  • [DMD 2.037] Bugs in Bugzilla marked with [tdpl].
  • [DMD 2.037] opDispatch() (based on Bugzilla:2868)
  • [DMD 2.037] Property syntax using @property.
  • [DMD 2.041] Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*").
  • [DMD 2.041] Remove "length" from array index expressions ( Bugzilla:3474).
  • [DMD 2.043] Fix the array stomping issue.
  • [DMD 2.044] Create complex types in std.complex.
  • [DMD 2.050] Remove C-style function declarations.
  • [DMD 2.057] opDollar.
  • [DMD 2.057] Remove typedef.
  • [DMD 2.061] Support user-defined attributes.
  • Support multiple alias this.
  • Remove complex and imaginary types from language into std.complex
  • Remove floating point NCEG operators.
  • All unit tests from TDPL must pass. ( TDPL Bugs)
  • For AA use opEquals instead of opCmp
  • Remove builtin array properties .sort and .reverse
  • Clean up is(XXX) and __traits(XXX) syntax, especially things like is(foo bar == super). (Could be done via meta.XXX proposal, Bugzilla:3702).
Known D2.0, Phobos (Longer timescale):
  • [std.concurrency, added DMD 2.042] Message passing for Phobos. It will be limited but safe.
  • [std.container, designed late May] Collections
  • Phobos I/O: The intent is to make all of I/O range-based such that e.g. files and other streams can be combined through std.range and std.algorithm in various ways.
Pending decision from Walter:
  • built-in toString() needs to be improved or discarded (Eg, change signature to void toString(void delegate(const char[] s) put, const char[] formatstr))
  • Inheriting constructors.
  • postconditions with exceptions
  • array operations for user-defined types
  • Move 'delete' from language to library.
Areas which need to be fixed:
  • [DMD 2.055 Strongly pure functions implicitly return immutable] construction of immutable and const objects.
  • a solid approach to unicity, moving, duplication, and marshaling.
  • unification of overloading across templates and non-templates.
  • Attempt to simplify the language, moving features to the standard library where possible.
  • Enums of reference types. They probably need to be forbidden.
Unknown status:
  • [Done 30 April -- Tango code is off-limits for Phobos] The Tango license issue needs to be sorted to the extent that Andrei and Walter feel they can safely look at the Tango code; OR we can decide that's not going to happen, and change the strategy for the Tango/Phobos? relationship.
  • removing "Substitution failure is not an error" Bugzilla:1951 (? Does D actually have SFINAE???)
Known to be deferred to D3.0:
  • AST macros.
  • Bartosz Milewski's race-free type system.
Previously proposed, but now dropped: Some old lists. Neither of these appear to stayed up-to-date with the latest happenings.

Contributing    

Specification    

DMD    

DMD is the Digital Mars D compiler, the official reference compiler. See Pull Requests for details about obtaining latest DMD source code via github.

Related    


FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: November 8, 2015 12:08 (diff))