| |
 | Posted by H. S. Teoh
in reply to FeepingCreature |  Permalink Reply |
|
H. S. Teoh 
Posted in reply to FeepingCreature
| On Mon, May 23, 2022 at 01:46:25PM +0000, FeepingCreature via Digitalmars-d wrote: [...]
> IMO, fear of breaking things is for projects who think they already have the most users that they will ever have. If you anticipate more people using D in the future, you should not let the complaints of current users cause pain for future users.
>
> At any rate, my personal oft-stated opinion is of course that the rate of change is too small. (Though I can't complain too loudly, since I've not exactly been making a lot of pull requests lately...)
Breaking changes is actually a good thing, *provided* users are given an off-ramp to smoothly migrate to the new way of writing things. (And also, the mere existence of an off-ramp is not the same thing as an off-ramp that's obvious to the user or told to him when the breakage happens -- e.g., if the compiler proposes the new way of writing it.)
I've told before of the deprecation of pointers implicitly converting to bool, that actually improved my code:
// Before:
T* ptr;
if ((ptr = func()) && ...) { ... }
// After:
T* ptr;
if ((ptr = func()) !is null && ...) { ... } // look, ma! More readable!
This kind of breaking change is welcome.
But breakages that have no workarounds are rather unwelcome.
T
--
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
|
