D1.x series proposal [was: State of Play]
Leandro Lucarella
llucax at gmail.com
Thu Mar 26 14:46:10 PDT 2009
Tomas Lindquist Olsen, el 26 de marzo a las 19:13 me escribiste:
> >>>>> That's why I'd love to see some kind of D 1.1 (maybe LDC could be used
> >>>>> to
> >>>>> make an "unofficial" D 1.1 language), with a few minor non-breaking new
> >>>>> features over D 1.0, then D 1.2 could introduce some more, and so on.
> >>>>> This
> >>>>> way people can catch-up easly, with small simple iterations, and D1
> >>>>> wont
> >>>>> feel as a dead frozen language.
> >>>>
> >>>> I think this is bound to happen sooner or later.
> >>>
> >>> Well, then I'd love it happen sooner ;)
> >>
> >> We could start by figuring out what D 1.1 is ...
> >
> > It's D2 - const/invariant, yeaaah! :-P
>
> Sounds a little drastic to me.
Yes, I think small iterations are better. It's easier to catch-up and
start using new features for developers, it's less likely for something
to break, etc.
I think Python got the development model really right. From Wikipedia:
"Python 2.0 was released on 16 October 2000, with many major new features
including a full garbage collector and support for unicode. However, the
most important change was to the development process itself, with a shift
to a more transparent and community-backed process."
I don't think is a coincidence that since Python 2.0 the language has such
a fast growth. I think D can learn a lot from Python =)
Again from Wikipedia:
"Python 3.0, a major, backwards-incompatible release, was released on
3 December 2008 after a long period of testing. Many of its major
features have been backported to the backwards-compatible Python 2.6."
I've searched throgh the new D2 features page[1] and D2 changelog[2] and
started a wiki page to make a plan for (unofficial) D1.x language
series:
http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal
Here is a transcription for the lazy ones that don't want to switch to the
browser and to ease the discussion in the NG:
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:
o unittest (when -unittest is set)
o 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 =)
[1] http://www.digitalmars.com/d/2.0/features2.html
[2] http://www.digitalmars.com/d/2.0/changelog.html
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More information about the Digitalmars-d
mailing list