DIP27 available for destruction

[Dmitry Olshansky]

27-Feb-2013 20:24, deadalnix пишет:
> On Wednesday, 27 February 2013 at 15:57:12 UTC, Andrej Mitrovic wrote:
>> On 2/27/13, Timon Gehr <timon.gehr at gmx.ch> wrote:
>>> I think the only technical problem of DIP27 outside the optional
>>> parentheses part is that it does not specify what is(T==function)
>>> will do.
>>
>> The only problem? How about breaking every single piece of code ever
>> written in D?
>>
>> It seems to me like people assume we can easily force people to
>> rewrite everything. It ain't gonna happen. This DIP was DOA from the
>> start.
>
> That is fallacy. PHP did massive breaking changes from 5 to 5 and still
> managed the change. And believe me, you'll find *WAY* more code written
> in PHP than in D even at the time.
>
> Breaking are not a problem in themselves and this reaction tells us more
> about our inability to do the most basic release management than
> anything else.

+1 on both counts.

It's the inability to handle breaking changes that is the most annoying.
An analogy: compare two situations.

The first one is that you see a notification on your front door that 
this day electricity might be unstable say during 6-8 P.M due to 
maintenance work. And at least you know what to expect even if it 
doesn't break a thing in the end.

The second one is that you have light constantly blink during the 
evening and your TV gets fried. Then a technician knock at you door to 
say that he's very sorry for frying  your TV box. But rest assured that 
he tried hard not to break anything and that only 0.05% of people 
experienced any problems.

Adopting the deprecation process is not good enough. Adopting and 
following it to the latter is still not good enough. Adopting, following 
and notifying people beforehand is close but not there.
The missing steps is providing a migration path and guarantees.

>
> On a more personal level, every single version of dmd break my code, so
> I'm kind of fed up when people don't want to fix actual broken stuff to
> not break code. D break code all the time, that is a fact already. Many
> breakage don't even have a good reason to exists (alias this syntax, I'm
> looking at you, but you are not the only one).

Same thoughts here. If anything compiler bugfixes are the biggest source 
of breakage in my code. That and regressions that come along.
I see it that only code that is constantly maintained (or instead is 
tied to a particular compiler version) is the only code that works today.

-- 
Dmitry Olshansky