Thoughts on some code breakage with 2.074

[Adam Wilson via Digitalmars-d]

On 5/9/17 20:23, Patrick Schluter wrote:
> On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote:
>> On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via
>> Digitalmars-d wrote:
>>> > [...]
>> [...]
>>> [...]
>> [...]
>>
>> I don't represent any company, but I have to also say that I
>> *appreciate* breaking changes that reveal latent bugs in my code. In
>> fact, I even appreciate breakages that eventually force me to write
>> more readable code!  A not-so-recent example:
>>
>> [...]
>
> The code breakage annoyance has more to do with 3rd party libraries not
> very actively maintained than with active codebases imho.

*cough* Umm, I think that's a false pointer.

If it's not actively maintained, should you really be relying on it? 
Where I work, current maintenance is one of the first questions we ask, 
followed immediately by determining whether or not we are able to 
maintain it ourselves should it go unmaintained.

If you're going to take on maintenance yourself, the library is already 
missing features and you're responsible for fixing it's existing 
implementation bugs anyways, might as well do the work of upgrading it 
while you're at it.

This is the point of Open Source, we have the opportunity to take 
unmaintained code and start maintaining it again.

Either way all I hear about is corp users not liking breaking changes. 
That has been demonstrated as a false concern time and time again.

If it's a matter of unmaintained libraries, those libraries probably 
have bigger problems than breaking compiler changes, fork and upgrade 
them or write your own. Because those have always been the only two 
choices you've ever had in practice anyways. Telling the world that we 
can't make breaking changes to the compiler because it might break an 
unmaintained library is irrational position and extreme position to 
take. It will *not* win us hearts and minds.

Let's stop hiding behind our misplaced fears over corp-users and 
unmaintained libraries so that we can start improving D for everyone who 
is using it today.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;