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)

Reply via email to