Last update March 26, 2009

D1 XProposal



Difference (last change) (no other diffs, normal page display)

Changed: 1c1,85
Describe the new page here.
==D1.x series proposal==

This proposal is intended to address the actual feel about D1 being obsolete and D2 being not ready for real life use. There a lot of new features in D2 that are simple, useful and easily backported to D1, but D1 is marked as frozen (or stable), so no new features are added. Worst, there is a very thin line between what is a new feature and a bugfix or a harmless addition, so sometimes D1 gets new features (like several new predefined version identifiers, .__vptr and .__monitor properties, extern(system), etc.). And it's much more easy for D1 to break when adding this kind of stuff, and suddenly the frozen D1 version is not stable anymore, and it doesn't provide anything new that is really interesting.

What would be nice is to have a language that evolves fast, with small iterations, but each iteration being really stable. This way developers can be more confident in the stability of the language concerning one particular version. If some code works with D1.034, then it should work with D1.045 without changes, or with any other D1.0xx.

Python has a very good development model, and D can learn a lot from it. Python versions are composed of 3 numbers, major version, minor version, and bugfix versions. Bugfix version should not introduce backward incompatible changes at all, only bugfixes. If your code works with Python 2.5.0, it will work with Python 2.5.3 too. Minor version releases happen every year, year and a half, and can include backward compatible changes or even backward incompatible changes as long as they are easy to stop and upgrade. Generally every backward incompatible change is added in 2 steps. The change is introduced in minor version X, but only enable if the developer asks for it (using from __future__ import feature, in the it can be a compiler flag, or a pragma). Any incompatibility with the new feature issue a warning (even when the new feature is not requested by the user). For example, if a new keyword is introduced, and you have a symbol with the same name as the new keyword, a warning is issued. In version X+1, the new feature is enabled by default, and if there any backward compatibility with the old version can be maintained, it kept but issues a deprecation warning. Finally, in X+2 all (deprecated) backward compatibility is removed. When a new major version is on the way, like with 3.0, all new features that can be ported to the previous major version, are ported and a new flag can be set to enable forward-compatibility warnings, to ease writing forward compatible programs.

D situation is a little different because D2 is already here, and it's too much ahead of D1. So a plan to backport features from D2 to D1 progressively should be done.

Here are the features proposed for D1.x series:

===D1.1===

This should be a transitional version, with as little changes as possible, just to try out how the new version is taken by the community. Only trivial changes are backported, specially the ones that improves forward-compatibility of code. Porting D1.0 programs to D should be trivial.

The proposed new features are:

* Add predefined versions:
** unittest (when -unittest is set)
** D_PIC (when -fPIC switch is used)
* Change result type of IsExpression? from int to bool.
* Change return type of opEquals from int to bool.
* Add warning when override is omitted.
* Make hidden methods get a compile time warning rather than a runtime one.
* Make special member functions _ctor, _dtor, etc., have two leading _ in order to not conflict with the user identifier space (maybe include an alias, if that's possible, to the old names and issue a warning if they are used).
* Deprecate html source files.
* Deprecate VolatileStatement?.
* Deprecate invariant, pure, nothrow, shared and other "stable" new D2 keywords as "free identifiers" (issue a deprecation warning if they are used).
* Make opAssign no longer overloadable for class objects (issue a deprecation warning if it's overloaded).
* Class and struct invariant declarations may have a () (issue a warning if () are omitted).
* Extend enums to allow declaration of manifest constants.
* Add new syntax for string literals (delimited, heredoc, D tokens).
* Make the 'this' parameter to struct member functions a reference type, rather than a pointer.
* Change __FILE__ and __LINE__ so they work as parameter default initializers.


===D1.2===

This version can introduce some bigger changes, for example:

* Remove old _ctor, _dtor, etc. aliases (from D1.1).
* Remove html source files support.
* Remove VolatileStatement?.
* Make invariant, pure, nothrow, shared and other "stable" new D2 keywords reserved identifiers.
* Make opAssign no longer overloadable for class objects.
* Class and struct invariant declarations must have a ().
* Use druntime to finally allow Tango-Phobos? compatibility (maybe this one should go to D1.1 even when I think it's not that trivial)
* Add C++ interface for plugins.
* Add isSame and compiles to __traits.
* Add typeof(return) type specifier.
* Allow static arrays to be lvalues.
* Allows implicit casting of StructLiterals? if each of its arguments can be implicitly cast.
* Add pragma startaddress.
* Allow .tupleof access private fields of a struct/class.
* Add partial ordering rules to disambiguate function overloading.
* Allow template alias be literals.
* Allow function templates deduce the return type if they are declared with auto.
* Don't match non-lvalues to ref and out parameters when overloading.
* Evaluate std.math.sin, cos, tan at compile time if the argument is a constant.

===D1.3===

This version can be focused on even bigger changes, and struct improvements:

* Implement Overload Sets for functions and templates.
* Add Constraints to templates.
* Add struct constructors.
* Add struct destructors and postblits.
* Add nested structs.
* Add overloadable unary * operation as opStar().

===General notes===

Full closure should be backported to D1.x too, but I don't remember if the problem about heap allocation is fully fixed yet (scope can be used to avoid heap allocation in function parameters I think but I don't remember if that solved all problems). If it's all working good, maybe it should be part of D1.2 o r D1.3.

OpDot? and __thread storage class are other features that can be ported to D1.x, but they are marked as experimental even in D2 (at least they were marked as experimental when first added to D2), so I guess they have to wait until they are at least somehow stable in D2.

Ranges (and foreach range support) could be backported to D1.x too in the future, but, again, they are not that stable yet, so they should wait a little to think about that.

On each new D1.x version, new keywords that are stable enough in D2 should be added as reserved words, so people can write code more forward-compatible with D2. New version identifier like {D Version1 1}? (maybe something else if it's unofficial) should be added to indicate the current version of the compiler.

Standard library (Phobos) changes should be ported too, but there are so many that it's harder to make a plan for it, and some code will depend on which new features are introduced so extra care should be taken when deciding what to put where. But most changes should be ported sooner than later for, again, forward-compatibility.

Finally, the "safe" stuff (module(system) and -safe switch) could be added in the future too, but there is not much about that for now there is no point in making plans for them =)

D1.x series proposal

This proposal is intended to address the actual feel about D1 being obsolete and D2 being not ready for real life use. There a lot of new features in D2 that are simple, useful and easily backported to D1, but D1 is marked as frozen (or stable), so no new features are added. Worst, there is a very thin line between what is a new feature and a bugfix or a harmless addition, so sometimes D1 gets new features (like several new predefined version identifiers, .__vptr and .__monitor properties, extern(system), etc.). And it's much more easy for D1 to break when adding this kind of stuff, and suddenly the frozen D1 version is not stable anymore, and it doesn't provide anything new that is really interesting.

What would be nice is to have a language that evolves fast, with small iterations, but each iteration being really stable. This way developers can be more confident in the stability of the language concerning one particular version. If some code works with D1.034, then it should work with D1.045 without changes, or with any other D1.0xx.

Python has a very good development model, and D can learn a lot from it. Python versions are composed of 3 numbers, major version, minor version, and bugfix versions. Bugfix version should not introduce backward incompatible changes at all, only bugfixes. If your code works with Python 2.5.0, it will work with Python 2.5.3 too. Minor version releases happen every year, year and a half, and can include backward compatible changes or even backward incompatible changes as long as they are easy to stop and upgrade. Generally every backward incompatible change is added in 2 steps. The change is introduced in minor version X, but only enable if the developer asks for it (using from __future__ import feature, in the it can be a compiler flag, or a pragma). Any incompatibility with the new feature issue a warning (even when the new feature is not requested by the user). For example, if a new keyword is introduced, and you have a symbol with the same name as the new keyword, a warning is issued. In version X+1, the new feature is enabled by default, and if there any backward compatibility with the old version can be maintained, it kept but issues a deprecation warning. Finally, in X+2 all (deprecated) backward compatibility is removed. When a new major version is on the way, like with 3.0, all new features that can be ported to the previous major version, are ported and a new flag can be set to enable forward-compatibility warnings, to ease writing forward compatible programs.

D situation is a little different because D2 is already here, and it's too much ahead of D1. So a plan to backport features from D2 to D1 progressively should be done.

Here are the features proposed for D1.x series:

D1.1

This should be a transitional version, with as little changes as possible, just to try out how the new version is taken by the community. Only trivial changes are backported, specially the ones that improves forward-compatibility of code. Porting D1.0 programs to D should be trivial.

The proposed new features are:

  • Add predefined versions:
    • unittest (when -unittest is set)
    • D_PIC (when -fPIC switch is used)
  • Change result type of IsExpression? from int to bool.
  • Change return type of opEquals from int to bool.
  • Add warning when override is omitted.
  • Make hidden methods get a compile time warning rather than a runtime one.
  • Make special member functions _ctor, _dtor, etc., have two leading _ in order to not conflict with the user identifier space (maybe include an alias, if that's possible, to the old names and issue a warning if they are used).
  • Deprecate html source files.
  • Deprecate VolatileStatement?.
  • Deprecate invariant, pure, nothrow, shared and other "stable" new D2 keywords as "free identifiers" (issue a deprecation warning if they are used).
  • Make opAssign no longer overloadable for class objects (issue a deprecation warning if it's overloaded).
  • Class and struct invariant declarations may have a () (issue a warning if () are omitted).
  • Extend enums to allow declaration of manifest constants.
  • Add new syntax for string literals (delimited, heredoc, D tokens).
  • Make the 'this' parameter to struct member functions a reference type, rather than a pointer.
  • Change __FILE__ and __LINE__ so they work as parameter default initializers.

D1.2

This version can introduce some bigger changes, for example:

  • Remove old _ctor, _dtor, etc. aliases (from D1.1).
  • Remove html source files support.
  • Remove VolatileStatement?.
  • Make invariant, pure, nothrow, shared and other "stable" new D2 keywords reserved identifiers.
  • Make opAssign no longer overloadable for class objects.
  • Class and struct invariant declarations must have a ().
  • Use druntime to finally allow Tango-Phobos? compatibility (maybe this one should go to D1.1 even when I think it's not that trivial)
  • Add C++ interface for plugins.
  • Add isSame and compiles to __traits.
  • Add typeof(return) type specifier.
  • Allow static arrays to be lvalues.
  • Allows implicit casting of StructLiterals? if each of its arguments can be implicitly cast.
  • Add pragma startaddress.
  • Allow .tupleof access private fields of a struct/class.
  • Add partial ordering rules to disambiguate function overloading.
  • Allow template alias be literals.
  • Allow function templates deduce the return type if they are declared with auto.
  • Don't match non-lvalues to ref and out parameters when overloading.
  • Evaluate std.math.sin, cos, tan at compile time if the argument is a constant.

D1.3

This version can be focused on even bigger changes, and struct improvements:

  • Implement Overload Sets for functions and templates.
  • Add Constraints to templates.
  • Add struct constructors.
  • Add struct destructors and postblits.
  • Add nested structs.
  • Add overloadable unary * operation as opStar().

General notes

Full closure should be backported to D1.x too, but I don't remember if the problem about heap allocation is fully fixed yet (scope can be used to avoid heap allocation in function parameters I think but I don't remember if that solved all problems). If it's all working good, maybe it should be part of D1.2 o r D1.3.

OpDot? and __thread storage class are other features that can be ported to D1.x, but they are marked as experimental even in D2 (at least they were marked as experimental when first added to D2), so I guess they have to wait until they are at least somehow stable in D2.

Ranges (and foreach range support) could be backported to D1.x too in the future, but, again, they are not that stable yet, so they should wait a little to think about that.

On each new D1.x version, new keywords that are stable enough in D2 should be added as reserved words, so people can write code more forward-compatible with D2. New version identifier like {D Version1 1}? (maybe something else if it's unofficial) should be added to indicate the current version of the compiler.

Standard library (Phobos) changes should be ported too, but there are so many that it's harder to make a plan for it, and some code will depend on which new features are introduced so extra care should be taken when deciding what to put where. But most changes should be ported sooner than later for, again, forward-compatibility.

Finally, the "safe" stuff (module(system) and -safe switch) could be added in the future too, but there is not much about that for now there is no point in making plans for them =)


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

Edit text of this page (date of last change: March 26, 2009 22:40 (diff))