On Wednesday, 28 November 2012 at 08:51:02 UTC, Dejan Lekic wrote:
> 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! :)

I fully agree.

This only works however, if the overhead is not too much and management is ok with it.

--
Paulo

On 11/28/12, SiegeLord <none@none.com> wrote:
> with 2.061 it is the dissalowance of rebindability
> of the this pointer.

We can still revert this pull since 2.061 was not officially released yet. I think we've simply missed Walter's comment which you linked to: http://d.puremagic.com/issues/show_bug.cgi?id=780#c3

On 28 November 2012 09:47, Paulo Pinto <pjmlp@progtools.org> wrote:

> 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.
>

If D stabilised on exactly the feature set it offers right now (or even 3
months ago), I wouldn't be interested. The lowest level is brittle, and the
high level is still missing a couple of little details (rvalues -> ref is
the key one for me).
D's fluidity is actually one of it's biggest selling points as far as I'm
concerned. D seems to accept that mistakes can be fixed and improvements
can be made, and it should embrace that to an extent, or you end up with
C++ long term.

I think the best approach is one that others have suggested, 2 branches, 'stable' which is maintained for 6-12 months, and only receives non-breaking fixes after they've been tested for a while, and 'dev', which users accept may receive breaking changes at any time. Those users will be happy to adapt their code as the language moves forward, as I am.

You choose the branch that applies to your business, and then you have no
reason to complain. The current situation where one branch adopting either
policy (and seemingly changing which policy it subscribes to from day to
day) will alienate the other camp, and is obviously unworkable.
Under a 2 branch system, the stable crew will still have to update from
time to time, but they can do it in one lump far less often, and that
should cause a lot less trouble for them.

D should have 3 version digits:
D2.6.1, the second digit representing the last 'stable' codepoint.

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.
>

I feel this personally.

On Wednesday, 28 November 2012 at 08:40:32 UTC, SiegeLord wrote:
> 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.

I have a different concession. I come here on a regular basis to see if the issues hampering some long-overdue work that is important to me (and arguably to the community) have been resolved. There has been great progress thanks to Kenji Hara, Don and others but a couple of critical issues still remain (like this one http://d.puremagic.com/issues/show_bug.cgi?id=5380). I don't give a darn whether fixing the language and tools breaks other people's code. It is *their* code that is wrong and should be changed. We should not need to clutter ours with the ugliest of workarounds because people didn't care to think about what they were doing. If they can't or don't want to do the right thing, let them stick to the buggy compiler builds that work for them.

>
> 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?

SiegeLord:

> With that kind of attitude D2 will never stabilize.

Currently in D there are unfinished parts like vector operations that are not finished, shared that maybe needs to be redesigned, foreach loops and switch statements that need some design fixes, but also its standard library has rebindable, emplace, Typedef, Nullable and Algebraic that are not good enough and need improvements or rethinking. Plus some missing collections and memory allocators. Plus there are several corner cases that must be addressed, I am following Bugzilla closely and if you want I can list you one hundred of significant bugs. Fixing some of those "bugs" will break user D2 code. Not fixing those bugs will be a worse fate.

D is a quite complex language, composed of many parts, and Walter is not just designing a language and developing a front-end, but he's also keeping its back-end, there is also the standard library, and the garbage collector. And the amount of work force is limited. So D develops and stabilize rather slowly. Developing D takes many years. I think there is no escape from this.

On the other hand I used to find a significant new bug every 20-30 lines of my D2 code, this today happens much more rarely.

Bye,
bearophile

On 11/28/2012 7:40 PM, SiegeLord wrote:
> 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.

On the other hand, many people were unhappy with my position of "no breaking changes at all outside of clear bug fixes" to D1, which also implied "no language enhancements". There were many enhancements to the code generation, new platforms, etc., and many CTFE improvements (which I more or less regarded as bug fixing). There were also no changes allowed that affected binary compatibility.

D1 isn't going away - it isn't going to be removed from the servers, etc. It's just not going to be officially supported anymore.

On 2012-11-28 12:48, Manu wrote:


> I think the best approach is one that others have suggested, 2 branches,
> 'stable' which is maintained for 6-12 months, and only receives
> non-breaking fixes after they've been tested for a while, and 'dev',
> which users accept may receive breaking changes at any time. Those users
> will be happy to adapt their code as the language moves forward, as I am.

I completely agree, it's not rocket science.

-- 
/Jacob Carlborg

On 11/28/12 3:01 AM, Jacob Carlborg wrote:
> 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".

I disagree. Aside from a few details, the language described by TDPL is implementable. The problem becomes when TDPL gets in competition with incorrect code that currently compiles and runs although it shouldn't.

Andrei

On 11/28/2012 10:18 PM, Andrej Mitrovic wrote:
> On 11/28/12, SiegeLord <none@none.com> wrote:
>> with 2.061 it is the dissalowance of rebindability
>> of the this pointer.
>
> We can still revert this pull since 2.061 was not officially released
> yet. I think we've simply missed Walter's comment which you linked to:
> http://d.puremagic.com/issues/show_bug.cgi?id=780#c3
>

Yeah, it seems that the warning & deprecation stages were skipped. That was a mistake.

On 11/28/2012 11:34 P I come here on a regular basis to see if
> the issues hampering soM, Max Samukha wrote:
> I have a different concession.me long-overdue work that is important to me (and
> arguably to the community) have been resolved. There has been great
> progress thanks to Kenji Hara, Don and others but a couple of critical
> issues still remain (like this one
> http://d.puremagic.com/issues/show_bug.cgi?id=5380).


That issue is marked as "normal", not critical. You can raise it to critical, but if you do, please add an explanation why. Ditto for any others you find critical.