On Sunday, 16 March 2014 at 15:05:45 UTC, Andrej Mitrovic wrote:
> On 3/16/14, Andrea <noneof@yourbiz.com> wrote:
>> In the
>> short term the current "broken" code will still work without
>> having to be rewritten.
>
> You'll end up in the same situation as Python 3. Most people will not
> only keep existing code, but continue to write *more of it*. By the
> time the "compatibility profile" is removed, it's going to become 100x
> harder to change all of that code, which means nobody will do it.

I was kind of expecting that argument. And yes, I do agree with that.

On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
> Am Mon, 17 Mar 2014 03:57:10 +0000
> schrieb "Jesse Phillips" <Jesse.K.Phillips+D@gmail.com>:
>
>> On Sunday, 16 March 2014 at 21:15:29 UTC, Martin Nowak wrote:
>> > Please think hard about this. Why does it need to break code?
>> > Can't we have a proper deprecation cycle?
>> > Until now it was always possible to add proper deprecation warnings and allow people to transition code at their own pace. I'm optimistic a solution can be found here too.
>> 
>> Deprecation is breaking code, it's a good way to to do it, but you shouldn't kid yourself that it isn't a breaking change.
>
> It certainly is a subjective matter. I usually skim though the
> change log, install the new compiler and cross my fingers.
> Then if I get a few deprecation messages with IDE links to the
> source that's ok for me every two months or so. I just try to
> fix these locations immediately instead of changing the build
> options to include -d.
> Silent breaking changes are a totally different beast.

IMHO we have a bunch of breaking changes already planned for the future and it'll be a bit more difficult than that to fix the code. Maybe I'm not aware of it and it already exists, but we should create a page where deprecated features are listed, the reasons behind the deprecation briefly described and small examples on how to fix the code are provided. This way fixing the code will be much easier. Let's say I get deprecation messages on 2 of those major breaking changes spread across a medium-size project: searching through the forums for the right thread(s) and reading through pages of discussion just to get an idea of what exactly is broken in my code and then fix it is not realistic IMHO. That would definitely scare away a D newcomer trying to experiment with the language for a project. For example, not long ago I was struggling to find what changed from TDPL as of today. In the future it's gonna be even more difficult for a new comer to *learn* D, let alone use it in real world projects.

>
> But it certainly depends on time pressure, how much

> infrequently maintained libs you use etc.

I speak for myself here, so I maybe wrong. I'm under the impression that a lot of (bindings to) libraries *are* infrequently maintained (not all of them of course). This is a big problem for D's employment in real world projects, which is caused by D's lack of popularity among library developers and I'm pretty sure that some of that is due to D's lack of long term stability. This is seriously slowing down D's adoption IMO.
In a recent project of mine I'm finding myself forced to go back to C++ (as much as I hate it) because of a lacking binding, which recently broke because the author introduced a change to the API and forgot to implement it in a few places and the shared libs precompiled binaries specific for the binding are severely outdated so my project doesn't even run. Now, I could submit a commit (I probably will) and spend half a day manually compiling the libraries, but why should I go through all of that when I can just download the latest official shared libs from the developer's website with templates for my favorite IDE, plenty of example code and the guarantee of a stable and reliable C++ API?
Now, on top of that add the compiler spitting at me deprecation messages with me having a vague idea on how to fix them and I'm done with D for good.

>
> At the end of the day I see no way for D to evolve "correctly"
> with the man power it has and the demands for both a stable
> target and improvements to so many things from
> final-by-default over "scope" to "shared".
> If we collected all these bits in a list we would see that
> they can't all be fixed in one release and things are still
> going to break quite a few times in the future. TLBB? Not
> quite there yet! ;-)

I agree with that 100%.

On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
>> Deprecation is breaking code, it's a good way to to do it, but you shouldn't kid yourself that it isn't a breaking change.
>
> It certainly is a subjective matter.

I don't see how it is. How do you define a change which has broken code.

> I just try to
> fix these locations immediately instead of changing the build
> options to include -d.

You're code no longer compiles due to a compiler change, that is what I consider a breaking change.

> Silent breaking changes are a totally different beast.

Agreed.

> At the end of the day I see no way for D to evolve "correctly"
> with the man power it has and the demands for both a stable
> target and improvements to so many things from
> final-by-default over "scope" to "shared".
> If we collected all these bits in a list we would see that
> they can't all be fixed in one release and things are still
> going to break quite a few times in the future. TLBB? Not
> quite there yet! ;-)

Agreed. Just because we feel that D still needs breaking changes, doesn't mean we should change the definition so that we can tell the world we don't break code every release. "No civilian casualties! We just found it easier to declare all humans as combatants."

On Monday, 17 March 2014 at 08:48:36 UTC, Andrea wrote:
> IMHO we have a bunch of breaking changes already planned for the future and it'll be a bit more difficult than that to fix the code. Maybe I'm not aware of it and it already exists, but we should create a page where deprecated features are listed, the reasons behind the deprecation briefly described and small examples on how to fix the code are provided.

The change log has been doing pretty good with this on for each release.

Otherwise, DIPs are kind of supposed to cover this, which would also help on planned breaking changes. There is an old list, which isn't even too much out of date, if at all.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

One of the biggest problems is that there doesn't tend to be any really clear statement of when a change has been approved. Usually it happens that someone implements it, and suddenly it is in the next compiler build. I feel that keeping the change log updated with this stuff is more important than the planning part.

On Monday, 17 March 2014 at 08:48:36 UTC, Andrea wrote:
> IMHO we have a bunch of breaking changes already planned for the future and it'll be a bit more difficult than that to fix the code. Maybe I'm not aware of it and it already exists, but we should create a page where deprecated features are listed, the reasons behind the deprecation briefly described and small examples on how to fix the code are provided.

We have:
http://dlang.org/deprecate

Am Mon, 17 Mar 2014 14:16:19 +0000
schrieb "Jesse Phillips" <Jesse.K.Phillips+D@gmail.com>:

> On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
> >> Deprecation is breaking code, it's a good way to to do it, but you shouldn't kid yourself that it isn't a breaking change.
> >
> > It certainly is a subjective matter.
> 
> I don't see how it is. How do you define a change which has broken code.
> 
> > I just try to
> > fix these locations immediately instead of changing the build
> > options to include -d.
> 
> You're code no longer compiles due to a compiler change, that is what I consider a breaking change.
> 
> > Silent breaking changes are a totally different beast.
> 
> Agreed.
> 
> > At the end of the day I see no way for D to evolve "correctly"
> > with the man power it has and the demands for both a stable
> > target and improvements to so many things from
> > final-by-default over "scope" to "shared".
> > If we collected all these bits in a list we would see that
> > they can't all be fixed in one release and things are still
> > going to break quite a few times in the future. TLBB? Not
> > quite there yet! ;-)
> 
> Agreed. Just because we feel that D still needs breaking changes, doesn't mean we should change the definition so that we can tell the world we don't break code every release. "No civilian casualties! We just found it easier to declare all humans as combatants."

Ok, so you were looking at it from the public perception view
point and I was thinking of the personal effect.
Anyways it looks like Andrei is convinced that close to no
breaking changes need to happen any more (excluding
possibly already wrong code). If so - and it hasen't been
communicated clearly - he and Walter should probably say so
more clearly in the coming weeks or at Dconf14.

Then we could stop discussing final-by-default and other things that potentially break code, like the changes to string handling and instead focus only on language additions.

-- 
Marco

On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu wrote:
> D1's approach to multithreading was wanting. D2 executed a big departure from that with the shared qualifier and the default-thread-local approach to data.
>
> We think this is a win, but D2 inherited a lot of D1's thread-related behavior by default, and some of the rules introduced by TDPL (http://goo.gl/9gtH0g) remained in the "I have a dream" stage.
>
> Fixing that has not gained focus until recently, when e.g. https://github.com/D-Programming-Language/dmd/pull/3067 has come about. There is other more stringent control of shared members, e.g. "synchronized" is all or none, "synchronized" only makes direct member variables unshared, and more.
>
> This will statically break code. It will refuse to compile code that is incorrect, but also plenty of code that is correct; the compiler will demand extra guarantees from user code, be they in the form of casts and stated assumptions.
>
> I believe this is a bridge we do need to cross. One question is how we go about it: all at once, or gradually?
>
>
> Andrei

I still have zero understanding of what "synchronized" is supposed to mean an only vague guesses about "shared". Probably have never used either of those apart of "shared static this()" module constructors. Having some examples of how code is supposed to behave and what will break can help reason about it.

On 3/18/14, 6:49 AM, Dicebot wrote:
> I still have zero understanding of what "synchronized" is supposed to
> mean an only vague guesses about "shared". Probably have never used
> either of those apart of "shared static this()" module constructors.
> Having some examples of how code is supposed to behave and what will
> break can help reason about it.

There are quite a few in TDPL.

Andrei

On Tuesday, 18 March 2014 at 13:49:54 UTC, Dicebot wrote:
> I still have zero understanding of what "synchronized" is supposed to mean an only vague guesses about "shared". Probably have never used either of those apart of "shared static this()" module constructors. Having some examples of how code is supposed to behave and what will break can help reason about it.

Synchronized is supposed to remove the top level shared qualifier (but keep it for every indirections) withing member functions. Member function also acquire a mutex before doing anything.

Andrei: please consider my proposal earlier in this thread. This is a relaxed version of the change that we are discussing here, which ensure the same level of safety, but with smaller breakage involved.

On Sunday, 16 March 2014 at 13:55:24 UTC, bearophile wrote:
> Benjamin Thaut:
>
>> Could you please explain in a bit more detail why you think opApply should be deprecated?
>
> To replace it with something better.

Don't even think, ranges are not better.