TLBB: The Last Big Breakage

[Andrea]

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