D has become unbearable and it needs to stop

[harakim]

On Wednesday, 5 July 2023 at 10:14:38 UTC, FeepingCreature wrote:
> On Wednesday, 5 July 2023 at 09:50:55 UTC, harakim wrote:
>> If someone at my work removed a field that I was using from a 
>> database or an optional field from an API, I would flip out. I 
>> have never seen removing "useless" or "ambiguous" features as 
>> a good thing if people are actually using them. If that's the 
>> case, then you have to go out and talk to them and get them to 
>> agree first because you're the one who screwed up. Otherwise, 
>> you leave it as it is.
>>
>
> And what do you do when that person has left the company and 
> you don't have anyone with commit access to their code?

It's hard to imagine a hypothetical situation where this could 
happen and where I also couldn't come up with a a workaround. 
Unless it resulted in a security issue or data corruption, I 
would probably not change the API to add additional requirements 
until the calling application could be replaced. If I added a new 
field, it would be optional. If I couldn't identify which calls 
were coming from the old errant service and I felt like I had to 
make it required for security or data corruption reasons, I would 
probably write a proxy. This is all assuming that service is both 
never updated and also important.

As for D, do you know what Java would do in this situation? or 
.NET? I know all of the 20 year old Java code that I have 
attempted to compile still compiles. I don't have .NET code that 
old, but I have never had issues downloading examples from 10 
years ago unless they use XNA.

Maybe the D community should actively reach out and maintain a 
list of critical projects (kind of like the kite list) and then 
just make sure there is some kind of continuity plan and list 
those as almost-standard libraries or the like so people will 
tend toward them.

> Theoretically the use of the 'deprecated' feature is exactly to 
> draw user attention to n upcoming change, and D already has 
> very wide deprecation windows. If something is marked as 
> deprecated and people only speak up (and post their repos) once 
> it's actually removed, my sympathy is honestly limited.

If your target audience includes only people who notify you every 
time a feature they use is deprecated, then I think that's a fine 
stance. It would be helpful to spell that out as a philosophy of 
D so people can make a language decision with that in mind.

> Compiler flags don't work as soon as libraries come into play. 
> Really, what you'd want is *package flags;* settings that 
> lexically affect exactly the modules of a particular dub 
> library.

At first, I thought this made sense, but now I wonder why would 
it be a problem? Either you're pulling the source and you can 
compile with the flag or you're pulling the binary and it's 
already built. It seems like it makes sense and I must be missing 
something.