Difference between revisions of "Beyond D2"

From D Wiki
Jump to: navigation, search
Line 1: Line 1:
 
== Motivation ==
 
== 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.  
+
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 (D3? E? ).  
+
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.
 
This page came up from email thread http://forum.dlang.org/post/ygmtislwwhfftiqrujan@forum.dlang.org.
  
== Contentious points ==
+
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
  
* is virtual by default a good idea with separate compilation model?
+
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 ==
 
== Features to drop ==
  
* drop built-ins: foreach_reverse, sort
+
* remove language builtins (sort / reverse / foreach_reverse / complex numbers), see http://dlang.org/deprecate.html
  
 
* get rid of opSlice/opSliceAssign etc:
 
* get rid of opSlice/opSliceAssign etc:
 
** a..b is instead syntax sugar for a Slice object:
 
** a..b is instead syntax sugar for a Slice object:
** rationale for opSlice, opSliceAssign, vs a..b being syntax suger for a Slice struct? http://forum.dlang.org/post/mailman.551.1365290408.4724.digitalmars-d-learn@puremagic.com
+
** 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:
 
* strings: stop conflating range of code points with range of code units:
Line 28: Line 36:
 
** http://forum.dlang.org/post/op.wx7lqwvx54xghj@puck.auriga.bhead.co.uk + code
 
** http://forum.dlang.org/post/op.wx7lqwvx54xghj@puck.auriga.bhead.co.uk + code
  
* can we get rid of @property?
+
* 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 ==
 
== Features to add ==
Line 61: Line 87:
 
* proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com
 
* proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com
  
* allow JIT (to be used sparingly), to allow runtime eval statements.
+
* allow JIT code, to allow runtime eval statements (for REPL etc).
  
 
* Compiler as a library (eg llvm/clang toolchain)  
 
* Compiler as a library (eg llvm/clang toolchain)  
Line 68: Line 94:
  
 
== Tooling ==
 
== 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
 
* improved dmd/rdmd command line: http://wiki.dlang.org/DIP41
* Incremental compilation support in rdmd: http://d.puremagic.com/issues/show_bug.cgi?id=9673
 
  
 
== Syntax changes ==
 
== Syntax changes ==
* get rid of C-style expression lists in parenthesis; these would be reserved for tuples
+
* full UFCS support: foo.mixin, foo.assert, foo.stringof, foo.typeof
* Go style a := b meaning auto a = b
+
 
* semi-column optional
+
* More lightweight syntax:
* Go style lightweight if/while/etc expressions that don't require () around the if statement:
+
** 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:
 
<syntaxhighlight lang="d">
 
<syntaxhighlight lang="d">
 
while x>=0 {...}
 
while x>=0 {...}
 
</syntaxhighlight>
 
</syntaxhighlight>
* full UFCS support: foo.mixin, foo.assert, foo.stringof, foo.typeof
 
  
 +
== Language interop ==
 +
* Allow transparently including C headers in code as in Go; could use swig behind the scenes
  
 
== More controversial features to add ==
 
== More controversial features to add ==
Line 88: Line 119:
 
** More future proof and eases refactoring
 
** More future proof and eases refactoring
  
* Allow transparently including C headers in code as in Go; could use swig behind the scenes
 
  
 
----
 
----
 
Page originally created by Timothee Cour on 11/09/2013; copyright: public domain.
 
Page originally created by Timothee Cour on 11/09/2013; copyright: public domain.
 
TODO: add discussion/DIP/webpage links to each item
 
TODO: add discussion/DIP/webpage links to each item

Revision as of 04:38, 10 November 2013

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

  • 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)"
  • 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

  • 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

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

Compilation

  • 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

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