March 26, 2009
On Thu, Mar 26, 2009 at 10:02 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> Which leads me to: If I was to help with a D 1.1 implementation, only features that would not change any semantics of valid D1 code would go in.
>
> But they always do. Many of the complaints about D1 breaking things is the result of bug fixes to D1 inadvertently breaking something unexpected.
>

True.

However, now that the DMD source is available, that can change. All we need is for it be put in a public repository (svn, hg etc). Then people would be able to see what you're doing and test the fixes. Catching bugs early in the process, as well as providing pretty much guaranteed code review. I know I'd be subscribing my RSS reader to the changelog at least.
March 26, 2009
On Thu, Mar 26, 2009 at 10:05 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> I don't necessarily want a 100% stable language. In fact I don't. But
>> obviously asking for both is just silly.
>> The only thing I'm not happy about is if code that used to work, still
>> compiles, but no longer works. This is where the real problem is and
>> I've seen it several times. MinWin, APaGeD and probably others.
>
> What do you suggest?
>
> It's why there's a "last stable version" of D1 on the website. With any software package, if you always download the latest version but another package was only tested with a different version, it's likely to have problems.

I'm not sure about what to do with the damage done already. I think it
came across worse than I meant it to.
In the future I think this can largely be solved by my public source
repository proposal.

>
March 26, 2009
On Thu, 26 Mar 2009 17:27:25 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> what needs to be done:
>>  1. Make Tango build on top of druntime.  I just merged from trunk yesterday, which was about 300 files, so most likely there will be compile issues ;)
>> 2. Const-ify everything.  Some parts are already done.
>> 3. Make all opApply's scoped properly.
>>  Not sure what happens after that, but step 2 alone is a ton of work.  In addition, there are some blocker bugs in DMD (1645 and 2524 right now) that prevent a complete port.
>>  When the shared/unshared paradigm is released, there's probably another ton of work to do :)
>
> You can already used shared/unshared. The semantics aren't implemented, but the type system support for it is.

But is it enforced?  Basically, I want to focus on one new language aspect at a time.  As far as I know, with the current D compiler, I can access a global not marked shared from multiple threads, no?  When shared/unshared is actually implemented, each thread gets its own copy, right?  It's still a fuzzy concept to me, and it seems like a waste of time to try and write code to use features that don't yet exist.  The longer I can put it off, the better.

The only impact I've seen so far is that singletons in Tango were sometimes named 'shared', so I had to change the names because of the reserved keyword.

-Steve
March 26, 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)
----------------------------------------------------------------------------
March 26, 2009
Walter Bright, el 26 de marzo a las 14:05 me escribiste:
> Tomas Lindquist Olsen wrote:
> >I don't necessarily want a 100% stable language. In fact I don't. But
> >obviously asking for both is just silly.
> >The only thing I'm not happy about is if code that used to work, still
> >compiles, but no longer works. This is where the real problem is and
> >I've seen it several times. MinWin, APaGeD and probably others.
> 
> What do you suggest?
> 
> It's why there's a "last stable version" of D1 on the website. With any software package, if you always download the latest version but another package was only tested with a different version, it's likely to have problems.

This is another problem with D, the lack of a public SCM repository for, at least, the fronend. Now each DMD release is really a "nightly snapshot" without any real-world testing (I guess). That's another reason why "stable" DMD release keep breaking.

If one could download a snapshot every once in a while and give it a try, most breaking changes should be detected *before* the actual release. Or maybe alpha or beta versions should be released.

When I see a compiler version 1.041, I see a stable release number, not a beta, or release candidate or nightly snapshoot, but sadly that is what it is. Maybe that is a big source of confusion.

Maybe an improvement on version numbering scheme can be very useful in
this regard, even for people looking at D2.0, D2.032 really looks like
a stable release. D2.0alpha032, for example, is really ugly but at lease
looks more like an alpha release =)
D1.041rc2, looks like a release candidate, not a final version, and if it
breaks something, I wouldn't be as surprised as if D1.041 breaks.

Anyway, I will be glad if you take a look at the D1.x series proposal =) http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
March 26, 2009
Leandro Lucarella wrote:
> This is another problem with D, the lack of a public SCM repository for,
> at least, the fronend. Now each DMD release is really a "nightly snapshot"
> without any real-world testing (I guess). That's another reason why
> "stable" DMD release keep breaking.
> 
> If one could download a snapshot every once in a while and give it a try,
> most breaking changes should be detected *before* the actual release. Or
> maybe alpha or beta versions should be released.
> 
> When I see a compiler version 1.041, I see a stable release number, not
> a beta, or release candidate or nightly snapshoot, but sadly that is what
> it is. Maybe that is a big source of confusion.

But that's why the download page divides the downloads into "latest" and "stable." If you want "stable", why download "latest"?

http://www.digitalmars.com/d/download.html

Furthermore, before release, it is made available to the DWT and Tango teams to see if it breaks them. If I made it generally available, how is that different from the "latest" on the download page? There's even a "bundle" version that comes with various libraries tested and verified with it.
March 26, 2009
On Thu, 26 Mar 2009 12:17:04 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

> Denis Koroskin wrote:
>> One of the breaking changes that I recall was that you made Posix
>> identifier built-in and thus any custom Posix versioning became an
>> error. Not sure if it was introduced in 1.041, though, but it is
>> still a breaking change.
>
> It was more of a build system change, but I get your point. It shows that even trivial changes are a bad idea for D1.
>

Isn't there a very simple way to get the best of both... allow these versions to be re-set if they are valid for the platform. e.g. still allow me to -version=Posix on linux, but fail on Windows (ignoring that Windows can have some posix compliance).

The same could be done for the rest of the pre-set ones. It could also be an easy way for programmers to enforce compiling only with supported configurations.
March 26, 2009
Tomas Lindquist Olsen wrote:
> However, now that the DMD source is available, that can change. All we
> need is for it be put in a public repository (svn, hg etc). Then
> people would be able to see what you're doing and test the fixes.
> Catching bugs early in the process, as well as providing pretty much
> guaranteed code review. I know I'd be subscribing my RSS reader to the
> changelog at least.

I think that's a good idea.
March 26, 2009
== Quote from Leandro Lucarella (llucax@gmail.com)'s article
>
> 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.

Who is going to do these backports?  Personally, I'd rather think about
moving my code to D2 in one jump than in a bunch of incremental
steps, each requiring a custom compiler.
March 26, 2009
Steven Schveighoffer wrote:
> On Thu, 26 Mar 2009 17:27:25 -0400, Walter Bright 
>> You can already used shared/unshared. The semantics aren't implemented, but the type system support for it is.
> 
> But is it enforced?

No, it is just type-checked.

> Basically, I want to focus on one new language aspect at a time.  As far as I know, with the current D compiler, I can access a global not marked shared from multiple threads, no?

That's correct.

> When shared/unshared is actually implemented, each thread gets its own copy, right?

Of unshared data, right, each thread gets its own copy. The default will be __thread for globals.