On Fri, Aug 24, 2018 at 09:48:33PM +0000, Meta via Digitalmars-d wrote: > On Friday, 24 August 2018 at 21:43:45 UTC, Steven Schveighoffer wrote: > > According to this comment: > > https://github.com/dlang/phobos/pull/5291#issuecomment-360929553 > > > > There was no way to get a deprecation to work. > > > > When we can't get a deprecation to work, we face a hard decision -- > > actually break code right away, print lots of crappy errors, or just > > leave the bug unfixed. > > > > -Steve > > Ah, that's unfortunate. Damned if you do, damned if you don't. > > I still don't agree with making a breaking change to Phobos.
I'm kinda on the fence about this, actually. OT1H I actually *want* D to have breaking changes that will give longer-term benefits, like removing cruft that shouldn't have been there in the first place, or straightening out decisions that in retrospect were poorly made. But OTOH I have also experienced the annoyance of random code breaking upon compiler upgrades, especially if the breakage happens in old code that I don't quite remember the intricacies of, or worse, in 3rd party code whose upstream has become non-responsive or has abandoned the project, or it's just too urgent to wait for upstream to address the problem, which I then have to debug and fix myself. I don't know how to reconcile these two. Perhaps if we had the manpower, we could maintain older versions for long enough to allow users to gradually rewrite to work with newer compilers, while the development branch can be bolder in making breaking changes that ultimately will result in a better, cleaner language. But I doubt we have the kind of manpower it takes to maintain something like that. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
