Another DMD alpha, another set of previously valid code that no longer compiles. With 2.060 it was the TypeInfo constness changes in druntime, with 2.061 it is the dissalowance of rebindability of the this pointer. The latter did make it into the spec half a year ago, but recently it was actually dissallowed in the beta. Unlike many other features of the sort (e.g. octal literals) there is no warning or deprecation errors... code that use to compile simply does not anymore.

In this last case, in principle, we were lucky... the spec was changed. What about things like this: http://dlang.org/attribute.html#inout . Are those undocumented features liable to change at any time? What warning will there be when somebody decides to submit an inout bug and somebody else fixes it in a way that breaks existing code?

D1 is scheduled to be discontinued in a month, and every new version of DMD keeps changing D2 in code breaking ways (or worse, with backwards incompatible spec changes). I think that unless people responsible for these things get their act together and stabilize D2 against these issues, D1 support should be extended until that happens.

SiegeLord:

> I think that unless people responsible for these things get their act together and stabilize D2 against these issues, D1 support should be extended until that happens.

It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2.

Bye,
bearophile

On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:

> It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2.

With that kind of attitude D2 will never stabilize.

I remember two years ago I was told that once TDPL was published, the language would become stable. Two years later everything is just as in flux as it was back then. The welcome fixation of bugs is befouled with deliberate code breakage left and right. There is absolutely no guarantee of backwards compatibility between DMD versions. This situation is simply unheard of. Vast majority of respectable software inititives provide a stable version that guarantees source and possibly binary compatibility, and an unstable version that does not. They use versioning schemes where a match of some part of the version number assures compatibility.

Is there absolutely no concern for D users's code? It certainly seems like it. Maybe it would have made sense a decade ago when D was just starting... but D has been around for over 11 years now. To have screwed up so badly that after 11 years you still don't have a stable platform to write code for (well, you do with D1, but in a month there will not be that excuse) is mind boggling.

On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:
> SiegeLord:
>
>> I think that unless people responsible for these things get their act together and stabilize D2 against these issues, D1 support should be extended until that happens.
>
> It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2.
>
> Bye,
> bearophile

The problem we have with this situation is that language users will just run away to more stable languages.

Many people need upper management agreement for the set of languages they use, if suggesting D might cause them to risk their job, they won't do it.

--
Paulo

> Is there absolutely no concern for D users's code? It certainly seems like it. Maybe it would have made sense a decade ago when D was just starting... but D has been around for over 11 years now. To have screwed up so badly that after 11 years you still don't have a stable platform to write code for (well, you do with D1, but in a month there will not be that excuse) is mind boggling.

I tend to disagree a bit. First D is a very, very powerful language written by just a few people, with no commercial background, so I think it is quite reasonable that it takes more time to stabilize than much simpler languages, let's say python.

I also in general think, that fixing things is a good idea, even if breaking code, but it is really annoying if your code breaks, especially if you can not easily find the reason.

For this reason and others (more testing) I would also very much appreciate (I already suggested this before) to have a stable branch, that really only receives bug fixes and a new major version release every half a year or so (given D's speed of development). It should not be too frequent, because it will be a lot of work:

1. Document precisely any breaking changes for the new version + a
recommend way of updating (which was tested).
2. Provide tools that fix your code automatically. Wherever reasonable &
possible.

Because I think, the least you can do is to have a thorough discussion somewhere of what breaks and how to fix it. I would be very much less pissed by breaking changes, if I could at least look them up quickly and get a solution for it.

For point 2, we would start with some easy tools like search and replace
(for name changes and such) and improve them over time to parse
context, ... (e.g. like http://coccinelle.lip6.fr/sp.php  )
-> The easier and automated the upgrade path, the better.

Old version could be supported until the major version after the next one comes out. Encourage people to upgrade early and make it as easy as possible for them.

Are breaking changes of any kind documented somewhere at the moment?

The release model I have in mind:
1. Every few months a new minor release for both the unstable and the
stable version. (To get early and good testing for the unstable version
& to find out any unexpected breakings)
2. Every six/eight/twelve months: The current unstable will become the
new stable with all breakings perfectly documented & uprade scripts
written.

If it is too much work to support two stable versions, we could drop updates as soon as a new version comes out.

Breaking changes should still be avoided of course, but if needed they should be possible.

Best regards,

Robert

On 2012-11-28 02:38, SiegeLord wrote:
> Another DMD alpha, another set of previously valid code that no longer
> compiles. With 2.060 it was the TypeInfo constness changes in druntime,
> with 2.061 it is the dissalowance of rebindability of the this pointer.
> The latter did make it into the spec half a year ago, but recently it
> was actually dissallowed in the beta. Unlike many other features of the
> sort (e.g. octal literals) there is no warning or deprecation errors...
> code that use to compile simply does not anymore.
>
> In this last case, in principle, we were lucky... the spec was changed.
> What about things like this: http://dlang.org/attribute.html#inout . Are
> those undocumented features liable to change at any time? What warning
> will there be when somebody decides to submit an inout bug and somebody
> else fixes it in a way that breaks existing code?
>
> D1 is scheduled to be discontinued in a month, and every new version of
> DMD keeps changing D2 in code breaking ways (or worse, with backwards
> incompatible spec changes). I think that unless people responsible for
> these things get their act together and stabilize D2 against these
> issues, D1 support should be extended until that happens.

Welcome do D.

-- 
/Jacob Carlborg

On 2012-11-28 08:17, SiegeLord wrote:

> With that kind of attitude D2 will never stabilize.
>
> I remember two years ago I was told that once TDPL was published, the
> language would become stable. Two years later everything is just as in
> flux as it was back then.

TDPL was release way, way too soon. It was written before many of the features were even implemented. Then at a later stage "Whoops, this apparently doesn't work, we need to break TDPL".

The welcome fixation of bugs is befouled with
> deliberate code breakage left and right. There is absolutely no
> guarantee of backwards compatibility between DMD versions. This
> situation is simply unheard of. Vast majority of respectable software
> inititives provide a stable version that guarantees source and possibly
> binary compatibility, and an unstable version that does not. They use
> versioning schemes where a match of some part of the version number
> assures compatibility.

I think all this is mostly a project management issue. I don't think the breaking changes in them self is the biggest problem. See my post in another thread:

http://forum.dlang.org/thread/mailman.2250.1353947827.5162.digitalmars-d@puremagic.com?page=5#post-k94g19:2427kh:241:40digitalmars.com

-- 
/Jacob Carlborg

On Wednesday, 28 November 2012 at 07:52:54 UTC, Robert wrote:
>> Is there absolutely no concern for D users's code? It certainly seems like it. Maybe it would have made sense a decade ago when D was just starting... but D has been around for over 11 years now. To have screwed up so badly that after 11 years you still don't have a stable platform to write code for (well, you do with D1, but in a month there will not be that excuse) is mind boggling.
>
> I tend to disagree a bit. First D is a very, very powerful language
> written by just a few people, with no commercial background, so I think
> it is quite reasonable that it takes more time to stabilize than much
> simpler languages, let's say python.
>

Actually, this is true that D have little resources, and the work
done is really incredible. To be fair, D community is one of the
most technically competent I know of.

That being said, the problem isn't the amount of work, but how it
is managed. Thinking that D is not stable because of resource is
just avoiding to look at the truth.

On Wednesday, 28 November 2012 at 08:01:02 UTC, Jacob Carlborg wrote:

> I think all this is mostly a project management issue. I don't think the breaking changes in them self is the biggest problem.

After years of using D1 and D2, I've lowered my expectations about what can be changed for the better with D as long as the current captains are at the helm. You can change the language, but you can't change the person. Yes, ultimately if the project was managed better the code breaking issue would be mitigated for free, but that's not happening. Bad management is one of the invariants of D's history.

Given that invariant, I just want a tiny concession... I want my code not to break with every new version of DMD. If some breaking change must be introduced, I want ample warning, preferrably in the form of a compillation warning or a deprecation message, so I don't have to scamper to fix my code in a few weeks/days after each DMD release, but have the leisure to do it over a release cycle.

A quick aside about D1... it in fact has amazing stability. I recently compiled Kenta Cho's D games which were written before D 1.0... I only had to make a few changes here and there for it to compile with the most recent DMD1. Far less than the amount of changes I had to make when upgrading from 2.059 to 2.060 with the D2 codebase I maintain (Tango D2 and my personal projects). With D1 being discontinued, it is clear where the priorities lie... definitely not on stability of people's code.

And before people come and say that they have thousands of D2 commercial code that they don't mind breaking every release... let me suggest that perhaps for every 1 of you, there are 99 others who don't care for such nonsense?

On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
> Another DMD alpha, another set of previously valid code that no longer compiles. With 2.060 it was the TypeInfo constness changes in druntime, with 2.061 it is the dissalowance of rebindability of the this pointer. The latter did make it into the spec half a year ago, but recently it was actually dissallowed in the beta. Unlike many other features of the sort (e.g. octal literals) there is no warning or deprecation errors... code that use to compile simply does not anymore.
>
> In this last case, in principle, we were lucky... the spec was changed. What about things like this: http://dlang.org/attribute.html#inout . Are those undocumented features liable to change at any time? What warning will there be when somebody decides to submit an inout bug and somebody else fixes it in a way that breaks existing code?
>
> D1 is scheduled to be discontinued in a month, and every new version of DMD keeps changing D2 in code breaking ways (or worse, with backwards incompatible spec changes). I think that unless people responsible for these things get their act together and stabilize D2 against these issues, D1 support should be extended until that happens.

Now you understand why I stick to Java at work, and use D only for non mission-critical (small) projects. If I know that the project is going to have large code-base I *do not* use D (by D I always mean D2).

However, If I *had to* use D for a large-scale project I would do the following:

1) Make my own fork of DMD, Druntime and Phobos, and maintain them myself. Ie. merge only changes from the upstream that do not break my own project.
2) Use these forked projects to build my project.
3) Periodically, when time permits, I "jump" to the latest release of DMD, Druntime and Phobos. Naturally that would be a big job, to fix my broken projects code. But as I said, I have reserved a lot of time for this so I am fine with this.

This is how it is done in real world mostly. I know I did it in the past. I used an experimental branch of a certain C++ GUI toolkit in a large project. I did exactly what I explained above, and it was all right! :)