On Thursday, 8 June 2023 at 14:26:56 UTC, Steven Schveighoffer wrote:

I like your sarcasm, but I didn't bring up the linked issue, as a segfault is obviously not related to my experience. Even though it adds an insult to injury.

I am particularly displeased with the community attitude of "link or didn't happen", because you personally know me and know how much struggle I had with trying to code in D.

On Thursday, 8 June 2023 at 14:20:18 UTC, Dejan Lekic wrote:

I am not getting paid for other contributions that I did (or tried to do) for D, and I don't expect that anyone else does. I am interested in having an LTS branch and I could contribute to it. But I can't create one.

On 6/8/23 10:37 AM, GrimMaple wrote:

I'm very interested in hearing problems that aren't compiler bugs though. So when I ask, please bring an issue, and the answer is this, then what am I to say?

I know it does happen, I know some of the issues you have faced. As I said, I'm not saying you are wrong. But what can someone like me do if it's just "things are bad, please help"? I'm ready to help! I just need to see what's happening.

The truth is, D shouldn't break code. It's not an intentional thing (most of the time). We have a set of something like 50 or 60 3rd-party projects that are CI tested with every PR. So the assertion that the core team doesn't care about 3rd party is simply wrong. But what can we do to help, if there is no specifics?

-Steve

On Thursday, 8 June 2023 at 14:33:57 UTC, GrimMaple wrote:

Yeah I somehow managed to completely avoid those, I guess.

Re std.xml, I'd probably have just vendored the entire module.

Re alias this on classes, we weren't using that anywhere, but "alias this" is always a nice-to-have anyways. You can always just access the property manually. Annoying but not crippling.

__traits(getAttributes) isn't deprecated, __traits(getAttributes) on overloads is deprecated because it was just plain broken. This only ever worked as a side effect of DMD compiler internals, ie. overloads being a linked list in functions.

ref in I just dodged outright. We just never use ref.

On Thursday, 8 June 2023 at 14:44:00 UTC, Steven Schveighoffer wrote:

The truth is, I've been nagging about LTS branches, and I've been nagging directly to Mike about it, and it went nowhere.
Per "core team doesn't care", when was the last time they had any meaningful meeting with said third party? When did they ask 3rd party developers directly about what they want or what they need? When did core team asked about "is it okay to deprecate this"?
The buildkite link is a joke in itself. It has some random packages, many of which are either deprecated, either abandoned. It doesn't even include most of the https://code.dlang.org/?sort=score list.

On 6/8/23 10:33 AM, GrimMaple wrote:

I agree some of these are questionable. We shouldn't be doing this much breakage. And thanks for giving specific examples.

This is pretty stupid actually. Why are we doing this? Just ignore ref when doing ref in. preview in is supposed to treat in as implicitly ref.

I haven't experienced problems with this, but it doesn't seem sound to me, without a valid replacement. I've seen a lot of complains about this on discord.

__traits(getAttributes) was deprecated if called on an overload set. It still works otherwise.

In this case, __traits(getAttributes) was wrong, so a bug is being fixed. How do we fix bugs like this without using deprecations and eventual removal?

This one is an issue with GDC and obscure varargs usage. I filed a bug on it, found that the answer is, GDC just isn't going to do that. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763

I have it in my backlog to fix undead: https://github.com/dlang/undeaD/issues/55

If someone else wants to do this, it should be pretty trivial! Just I don't have all the time in the world for these things.

-Steve

On 6/8/23 10:56 AM, GrimMaple wrote:

An LTS branch needs at least one dedicated person to keep it up to date with any bug fixes that happen in the main line. This is not a trivial task.

I think it would be fantastic to have, I don't know what the DLF has in terms of resources to make it happen.

As far as 3rd party input, they have started inviting community members into the monthly meetings. I attended the last one, along with 2 others. Maybe ask Mike about attending?

Adding libs to buildkite requires someone to set up the buildkite CI, it's not too hard. But I just noticed, the one I got added was removed (MartinNowak/io), I probably was contacted about it, but I don't remember.

But this isn't something that DLF is going to do itself. If you want your project added, all you have to do is make the PR: https://github.com/dlang/ci/blob/master/buildkite.sh

And then you have to be responsive to any issues that happen because CI fails to build.

-Steve

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

So, DLF isn't going to care, and then you try to convince me, that they do care.
I'm sorry, but running around begging "oh please don't break my code" is unproductive. There is only this much one can do. And I know this goes both ways. I don't expect core team to run around and check if everyone is happy, but I expect at least some level of commitment towards making D a safe (not in a sense of memory-safe) language.

What I'm seeing right now is strong refusal that there even are any issues.