Why is D unpopular, redux.

[H. S. Teoh]

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.