On Monday, 3 July 2023 at 15:04:13 UTC, FeepingCreature wrote:

Many used approach with clang/cling..
D already had dstep,ctod,htod,dpp,calypso,ohmygentool
Also same ABI with C and easy export(C)..
Many languages somehow live without it..

Also there were no DIP with: analysis of “best practices”, effort estimation, asking which approach based on effort is more desired by community..
Maybe it was but only inside core team idk..

On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer wrote:

This article has stuck with me over the years: https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/

That is what made Windows successful. It was what made .NET and Java successful. You can write a program and then you have a program.

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.

I see this has been brought up, but why not use compiler flags? It's a win for everyone. You do have some extra code in the compiler until the next major version, but refer back to my Sim City example. That's the price of being a stable tool.

That's it for my reply, but I also have a few questions:

1. If I wanted to be a contributor and understand the dmd codebase and be able to understand the core team's perspective, how would I start?
2. How would I join the meeting with the core team where they go over things?
3. Could the people who want a stable language theoretically declare one version of it stable and maintain it themselves?

On Wednesday, 5 July 2023 at 09:50:55 UTC, harakim wrote:

Linux guarantees binary compatibility. ("We do not break userspace!") However, Linux is IMO more willing than D to say "well, that API was a mistake, we're going to support it but we'll also offer a new API that does it right." Microsoft, of course, does the same thing. And ultimately, that's dependent on your ability to engineer a clean separation between the user API and the internals. D is hampered here because a user type has a lot of ways to be sensitive to implementation internals, and they can stack exponentially.

Maybe at some point D has to start deprecating combinations of features; to say "well, we're adding a new functionality, if you want to use that you cannot use this old functionality." So all the code that was written at time X continues to work, but the features that were available at time X don't necessarily work together with features that were available at time X+1. We have to get the combinatorial explosion under control somehow.

And what do you do when that person has left the company and you don't have anyone with commit access to their code? If I push for a Phobos deprecation, I'd love to be able to go through all affected projects and update their code; the problem is first that I can't find all affected projects because they'll be either closed-source or not in Buildkite, and second if I do find them that there's no guarantee there's anybody there to actually look at the fix. How many months should I wait for PRs?

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.

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.

On Wednesday, 5 July 2023 at 10:14:38 UTC, FeepingCreature wrote:

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.

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.

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.

On Wednesday, 5 July 2023 at 23:22:14 UTC, harakim wrote:

The problem is that you're committing your whole project to either having the flag set or not having it set. If some code will only work with and some code only without, you're SOL. And the more flags you add to the compiler, the more likely a conflict becomes.

On Thursday, 6 July 2023 at 02:44:30 UTC, FeepingCreature wrote:

I don't see a lot of projects being so large and complex that someone could not realize they are using a flag and then also miss the behavior in testing. And if the project is like that, then they have the manpower to go and remove the flag. How often are you expecting these compiler flags to come along? The first requirement is that there was a bug in the compiler or standard library. That seems like a pretty high bar to clear, although all code has bugs so it does happen. The second bar is the code base has to be such that it relied on the behavior of the bug. Then the person who is actually building the source has to decide it's too difficult to fix the issue for whatever reason. How many flags do you think a code base will have? When I write code, I split it up so I could pass the flag into a payment gateway but not into the shipping price calculator, for example.

I think in the case that the core team made a mistake that needs to be fixed, a flag is a good option. And only pushing the removal of deprecations every few years doesn't seem like a big deal either. I would like to see what you all talk about at the monthly meetings. I would like to learn what goes into making a programming language that makes these things so difficult. I would be willing to take a long time of listening and understanding to figure that out. And at the end of it, I think I could be a bridge from the language developers to the discontented community members who want to see stability.