www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D has become unbearable and it needs to stop

reply GrimMaple <grimmaple95 gmail.com> writes:
I usually try to stay more silent (on the form at least), but I 
think I reached my boiling point. I've been a (self employed) 
full time D developer for almost 2 years now, developing quite a 
large codebase of personal closed source projects, as well as 
adopting some 3rdparty code like dlangui. And my life has become 
particularly miserable in the last half a year or so.

I wish I was exaggerating, but __every__ new DMD version breaks 
some of my code, to a smaller or bigger extent. It can be either 
my own code, or dependency code, but I started drowning in 
deprecation messages or outright breakage. It's nearly impossible 
to develop any reasonable 3rdparty in those conditions. I'm tired 
of fixing things that weren't broken. And I can't even imagine 
having to support multiple branches of code because of those 
deprecations. But I probably should, as, periodically, I get 
issues that dlangui can't compile with some outdated dmd version. 
It's just insane!

Recently, some of the changes resulted in direct API changes. 
This is unacceptable, as it, basically, forces people to update 
major versions and split the codebase between "before" and 
"after". Also forcing them to support two version of the same 
thing.

There have been a lot of talk about Gripes, about the "Vision" of 
D... But more than half a year passed, and yet the breakage only 
gets worse, and nothing seems to be improving. At least in 
regards of LTS. And with no proper LTS, no proper 3rd-party can 
exist.

So, as pissed as I am, please, for the love of everything, stop 
breaking D. I understand the desire to improve the language, but 
can you understand the desire to just... write working code? 
Please, make D at least somewhat stable.
Jun 08 2023
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but I 
 think I reached my boiling point. I've been a (self employed) 
 full time D developer for almost 2 years now, developing quite 
 a large codebase of personal closed source projects, as well as 
 adopting some 3rdparty code like dlangui. And my life has 
 become particularly miserable in the last half a year or so.

 I wish I was exaggerating, but __every__ new DMD version breaks 
 some of my code, to a smaller or bigger extent.


Can't confirm. Can you give some examples, please? In my 
experience (and we maintain a lot of D code), serious *new* 
breakage (not an existing bug) is pretty rare.

To be fair, we don't use that many external libs though.
Jun 08 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:

 Can't confirm. Can you give some examples, please? In my 
 experience (and we maintain a lot of D code), serious *new* 
 breakage (not an existing bug) is pretty rare.

 To be fair, we don't use that many external libs though.


2.104 deprecated `ref in`, this changes function signatures (Adam 
was particularly displeased with having to push breaking changes).
2.103 deprecated `alias this` on classes, which resulted in 
complete code breakage. This lad 
https://github.com/FreeSlave/icontheme/issues/2 even refused to 
do anything about it.
2.102 deprecated `__traits(getAttributes)`. Somebody complained 
about this, but I can't remember who exactly. Probably Adam again.
2.101 removed `std.xml`, which led to a significant rewrite of 
dlangui, which inevitably led to me leaving D (even though 
temporarily). And no, `undeaD` maintainers refused to fix my 
problems: https://github.com/dlang/undeaD/pull/54 , 
https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD 
doesn't work with GDC)

Other versions go too far back for my memory
Jun 08 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 8 June 2023 at 14:33:57 UTC, GrimMaple wrote:

 On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:

 Can't confirm. Can you give some examples, please? In my 
 experience (and we maintain a lot of D code), serious *new* 
 breakage (not an existing bug) is pretty rare.

 To be fair, we don't use that many external libs though.


 2.104 deprecated `ref in`, this changes function signatures 
 (Adam was particularly displeased with having to push breaking 
 changes).
 2.103 deprecated `alias this` on classes, which resulted in 
 complete code breakage. This lad 
 https://github.com/FreeSlave/icontheme/issues/2 even refused to 
 do anything about it.
 2.102 deprecated `__traits(getAttributes)`. Somebody complained 
 about this, but I can't remember who exactly. Probably Adam 
 again.
 2.101 removed `std.xml`, which led to a significant rewrite of 
 dlangui, which inevitably led to me leaving D (even though 
 temporarily). And no, `undeaD` maintainers refused to fix my 
 problems: https://github.com/dlang/undeaD/pull/54 , 
 https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD 
 doesn't work with GDC)

 Other versions go too far back for my memory


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.
Jun 08 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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.


 2.104 deprecated `ref in`, this changes function signatures (Adam was 
 particularly displeased with having to push breaking changes).


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`.


 2.103 deprecated `alias this` on classes, which resulted in complete 
 code breakage. This lad https://github.com/FreeSlave/icontheme/issues/2 
 even refused to do anything about it.


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.


 2.102 deprecated `__traits(getAttributes)`. Somebody complained about 
 this, but I can't remember who exactly. Probably Adam again.


`__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?


 2.101 removed `std.xml`, which led to a significant rewrite of dlangui, 
 which inevitably led to me leaving D (even though temporarily). And no, 
 `undeaD` maintainers refused to fix my problems: 
 https://github.com/dlang/undeaD/pull/54 , 
 https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD doesn't work 
 with GDC)


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
Jun 08 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer 
wrote:

 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?


The problem is that there is no easy migration path for the cases 
where it actually did work just fine. The update required an 
extra static if branch added to each use for a generic loop.

Moreover, a loop over overloads *still* required an additional 
getOverload since the deprecation message triggers in cases when 
it shouldn't have!

foreach(idx, overload; AliasSeq!(__traits(getOverloads, Module, 
memberName))) static if(.isScriptable!
         (__traits(getAttributes, __traits(getOverloads, Module, 
memberName)[idx]))()) { // lol  i have to do the second 
getOverload to stop the compiler from deprecating


The `overload` there wouldn't work despite it already being 
drilled down, since the deprecation wasn't smart enough to see I 
had already handled that case!

Pointless nagging from the compiler that led to worse code, not 
any bug fix.
Jun 08 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/8/23 11:21 AM, Adam D Ruppe wrote:

 On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer wrote:

 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?


 
 The problem is that there is no easy migration path for the cases where 
 it actually did work just fine. The update required an extra static if 
 branch added to each use for a generic loop.


You mean, it happened to work because of the ordering of the overloads? 
This is the nature of things that do something incorrect in the face of 
ambiguity.

This very much reminds me of the cycle detection problems I fixed. 
Cycles wouldn't get detected, because the algorithm was flawed. Fix the 
algorithm, and now "working" code breaks because there actually is a 
cycle. What do we do about it?

The answer at the time was to introduce a ridiculous deprecation system, 
where I implemented both the correct algorithm and the incorrect 
algorithm, and ran *both*. Then if they disagreed, still allow it and 
print a deprecation message.

In my estimation that is what is happening here -- you are relying on a 
faulty implementation, and that reliance is being deprecated.


 
 Moreover, a loop over overloads *still* required an additional 
 getOverload since the deprecation message triggers in cases when it 
 shouldn't have!
 
 foreach(idx, overload; AliasSeq!(__traits(getOverloads, Module, 
 memberName))) static if(.isScriptable!
          (__traits(getAttributes, __traits(getOverloads, Module, 
 memberName)[idx]))()) { // lol  i have to do the second getOverload to 
 stop the compiler from deprecating


That seems like a bug in the deprecation. If you have the overload, you 
shouldn't need a second getOverload.

And... bug just filed a few days ago.

https://issues.dlang.org/show_bug.cgi?id=23966

-Steve
Jun 08 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer 
wrote:

 You mean, it happened to work because of the ordering of the 
 overloads?


Yes, attaching an attribute to the first overload worked well for 
a lot of cases and could have been specified to work. Or 
maximally, overload sets could be a well-defined concept in D and 
the symbol refers to them and then UDAs either don't attach to 
them or... something. Or, minimally, going from overload set to 
specific overload could have been made trivial and generic with 
other symbols that are not overload sets, so you can migrate by 
calling that instead of doing an extra branch externally.


 This is the nature of things that do something incorrect in the 
 face of ambiguity.


Technically, the spec is still ambiguous:

https://dlang.org/spec/traits.html#getAttributes

"Takes one argument, a symbol. Returns a sequence of all attached 
user-defined attributes. If no UDAs exist it will return an empty 
sequence "

It doesn't say anything about special treatment of overload sets, 
so it doing the same thing as the rest of the language - using 
the first one - is no more or less wrong than anything else.

In fact, it giving a deprecation is probably a violation of the 
spec...

These "bugs" ought to be defined in terms of the spec, and spec 
changes ought to be reviewed before merged.


 That seems like a bug in the deprecation. If you have the 
 overload, you shouldn't need a second getOverload.


Yes, indeed, the implementation of the deprecation is obviously 
broken.

Yet it shipped anyway.
Jun 08 2023
parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 8 June 2023 at 16:13:32 UTC, Adam D Ruppe wrote:


 That seems like a bug in the deprecation. If you have the 
 overload, you shouldn't need a second getOverload.


 Yes, indeed, the implementation of the deprecation is obviously 
 broken.

 Yet it shipped anyway.


The deprecation was not broken. There was another bug in the 
compiler that the deprecation simply exposed. That bug is being 
fixed with this PR: https://github.com/dlang/dmd/pull/15353
Jul 04 2023
prev sibling parent reply harakim <harakim gmail.com> writes:
On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer 
wrote:

 On 6/8/23 11:21 AM, Adam D Ruppe wrote:

 On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer 
 wrote:

 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?


 
 The problem is that there is no easy migration path for the 
 cases where it actually did work just fine. The update 
 required an extra static if branch added to each use for a 
 generic loop.


 You mean, it happened to work because of the ordering of the 
 overloads? This is the nature of things that do something 
 incorrect in the face of ambiguity.

 This very much reminds me of the cycle detection problems I 
 fixed. Cycles wouldn't get detected, because the algorithm was 
 flawed. Fix the algorithm, and now "working" code breaks 
 because there actually is a cycle. What do we do about it?

 The answer at the time was to introduce a ridiculous 
 deprecation system, where I implemented both the correct 
 algorithm and the incorrect algorithm, and ran *both*. Then if 
 they disagreed, still allow it and print a deprecation message.

 In my estimation that is what is happening here -- you are 
 relying on a faulty implementation, and that reliance is being 
 deprecated.


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?
Jul 05 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Wednesday, 5 July 2023 at 09:50:55 UTC, harakim 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.


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.


 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? 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.


 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.


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.
Jul 05 2023
parent reply harakim <harakim gmail.com> writes:
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.
Jul 05 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Wednesday, 5 July 2023 at 23:22:14 UTC, harakim wrote:

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

 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.


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.
Jul 05 2023
parent harakim <harakim gmail.com> writes:
On Thursday, 6 July 2023 at 02:44:30 UTC, FeepingCreature 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.


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.
Jul 05 2023
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer 
wrote:

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

 2.101 removed `std.xml`, which led to a significant rewrite of 
 dlangui, which inevitably led to me leaving D (even though 
 temporarily). And no, `undeaD` maintainers refused to fix my 
 problems: https://github.com/dlang/undeaD/pull/54 , 
 https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD 
 doesn't work with GDC)


 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


I just decided to do it. And of course, it's taking more time 
than I would like...

Any help appreciated: https://github.com/dlang/undeaD/pull/56

-Steve
Jun 09 2023
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 8 June 2023 at 14:33:57 UTC, GrimMaple wrote:

 On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:

 Can't confirm. Can you give some examples, please? In my 
 experience (and we maintain a lot of D code), serious *new* 
 breakage (not an existing bug) is pretty rare.

 To be fair, we don't use that many external libs though.


 2.104 deprecated `ref in`, this changes function signatures 
 (Adam was particularly displeased with having to push breaking 
 changes).
 2.103 deprecated `alias this` on classes, which resulted in 
 complete code breakage. This lad 
 https://github.com/FreeSlave/icontheme/issues/2 even refused to 
 do anything about it.
 2.102 deprecated `__traits(getAttributes)`. Somebody complained 
 about this, but I can't remember who exactly. Probably Adam 
 again.
 2.101 removed `std.xml`, which led to a significant rewrite of 
 dlangui, which inevitably led to me leaving D (even though 
 temporarily). And no, `undeaD` maintainers refused to fix my 
 problems: https://github.com/dlang/undeaD/pull/54 , 
 https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD 
 doesn't work with GDC)

 Other versions go too far back for my memory


This list demonstrates you aren't complaining for nothing. It's 
easy to see dealing with this rate of breakage it is painful.

That being said, I don't think language instability is the 
problem. We want D to develop after all, and the language already 
tries to be reasonably backwards-compatible. It's just the 
natural price of using a language that is still developing.

Bundling changes to fewer releases wouldn't probably help either. 
We'd have version changes less often, but they'd be bigger when 
they do happen. If anything, we should have a common agreement of 
what is the latest "LTS" compiler verion a DUB library should 
support. I don't mean the compiler would have any LTS support 
from it's development team, just that it'd be the verion DUB 
libraries are tested against.

Fortunately there are ways for the user to ease the pain. The 
common theme in your list seems to be you're relying in many 
libraries. I don't know how many, and I'm not saying it's wrong. 
But the less library dependencies you have, the less problems.

Sometimes it may be more practical to bundle the library source 
in your codebase (as opposed to DUB registry) so you can fix it 
yourself. That has its downsides but it's still a valid choice.

Also, unless it's something security critical such as certain 
parts of Vibe.d there is no pressure for libraries to be up to 
date. You can use older library versions until everything is 
ready to update to newer compiler version.
Jun 08 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 8 June 2023 at 20:08:51 UTC, Dukc wrote:

 That being said, I don't think language instability is the 
 problem. We want D to develop after all, and the language 
 already tries to be reasonably backwards-compatible. It's just 
 the natural price of using a language that is still developing.


I'm pro breaking changes that move toward something better that 
have a good migration path.

I'm against breaking changes that don't do those thing.

The alias this for classes thing has no migration path and isn't 
moving to something better. It has no actual technical 
justification, being an arbitrary removal. This is not a step 
forward.

The getAttributes of an overload set had no easy migration path 
for the cases where it worked just fine (nor the other cases 
really, the "right" way is a pain in the butt consistently, and 
this deprecation is not a step toward fixing that pain), and the 
deprecation message itself is buggy giving false positives that 
are a pain to work around! This is a step backward.

The changes to `in` are obnoxious since it keeps changing the 
definition to protect people who weren't following the spec while 
punishing people who were. But... it is potentially leading to 
something valuable and is pretty easy to migrate things, so I'll 
cut it a bit of slack. While it annoys me, on balance, I can 
actually see this as worthwhile.


 But the less library dependencies you have, the less problems.


Yeah, dependencies are evil, but again this is a bit of a 
problem: D works best when everyone does their own thing. But one 
of the paths to bigger adoption is more collaborative libs...


 Sometimes it may be more practical to bundle the library source 
 in your codebase (as opposed to DUB registry) so you can fix it 
 yourself. That has its downsides but it's still a valid choice.


When your thing is open source it tends to become a problem 
eventually whether you like it or not.
Jun 08 2023
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jun 09, 2023 at 12:14:35AM +0000, Adam D Ruppe via Digitalmars-d wrote:
[...]

 I'm pro breaking changes that move toward something better that have a
 good migration path.


+1, me too.



 I'm against breaking changes that don't do those thing.


Yes.



 The alias this for classes thing has no migration path and isn't
 moving to something better. It has no actual technical justification,
 being an arbitrary removal. This is not a step forward.


I actually think alias this for classes is a bad thing.  I used it in my
own code and liked it at first, but as I gained more experience with it,
I discovered that it was only good for short term convenience, over the
long term it becomes a source of confusion and maintenance headaches. So
I'm not against removing it per se.  However, as you said, there is no
migration path, and that's bad.  I did have to rewrite a good chunk of
code in my own project after the deprecation came into effect. In some
parts it wasn't too pretty, though overall I did feel that the code
improved afterwards.  Still, the extent to which I used it was quite
limited; I can imagine the frustration if I had to deal with a much more
extensive usage.



 The getAttributes of an overload set had no easy migration path for
 the cases where it worked just fine (nor the other cases really, the
 "right" way is a pain in the butt consistently, and this deprecation
 is not a step toward fixing that pain), and the deprecation message
 itself is buggy giving false positives that are a pain to work around!
 This is a step backward.


I never dared use getAttributes on overload sets, because reading the
docs made it clear to me that it simply wasn't designed to handle that,
and probably would exhibit quirky behaviours and be unstable across
releases.  (It's a scary thing when the docs describe something and
fails to describe corner cases that immediately pop up to mind when you
read it -- obviously it didn't even occur to the author that it could be
a problem, which gives you a lot of confidence in the implementation --
NOT.)  I'm glad I exercised caution. :-/



 The changes to `in` are obnoxious since it keeps changing the
 definition to protect people who weren't following the spec while
 punishing people who were. But... it is potentially leading to
 something valuable and is pretty easy to migrate things, so I'll cut
 it a bit of slack. While it annoys me, on balance, I can actually see
 this as worthwhile.


With the recent proliferation of attributes and their frequent
breakages, I've become more and more hesitant to use them in my own
code. If it's a template and the compiler deals with them for me, then
fine. But I'm feeling more and more resistance to writing them myself,
in the fear that it will come back one day to bite me from behind at the
least convenient moment.  (One time I had a user request that got
stalled because of a deprecation kicked in for an old-ish project that I
hadn't touched in a while.  What could have been a 5-minute bugfix
turned into a several-hour detour to fix deprecations.  It was Not
Fun(tm).)


Another example of a deprecation of questionable value, though in
Phobos, not the language itself, is the approxEqual -> isClose
deprecation a couple of years ago.  I mean, there's totally a good
reason behind it, but the fact that it broke lots of perfectly-fine old
code was Not Nice.  And the deprecation message was unclear about how to
fix the code -- I had to go out of my way to look up the docs for
isClose (and the choice of name IMO was unfortunate) just to figure out
what exactly I needed to do to replicate the old behaviour of
approxEqual.  That was Not Nice when I needed to recompile an old
project just for a 1-line bugfix.  I ended up spending hours on it,
rather than just a 5-minute quick fix.  I have absolutely no problem
with using isClose for new code, but why gratuitously break old code for
no reason?  A lot of the breakage in my code was in old unittests --
verifying computations for values that are known to work correctly with
approxEqual. Just because approxEqual had some bad corner cases -- which
my unittests did NOT touch -- is no reason to break it for ALL old code
in existence that uses it.  Just undocument it so that new code won't
use it anymore.  It doesn't cause problems with anything else; its
continued existence in Phobos doesn't cause any detriment.  Old code
would continue to compile, and that's a Good Thing(tm).



 But the less library dependencies you have, the less problems.


 
 Yeah, dependencies are evil, but again this is a bit of a problem: D
 works best when everyone does their own thing. But one of the paths to
 bigger adoption is more collaborative libs...


Dependencies *are* evil.  (Dependency hell is an NP-complete problem.
That says something.)  I've come to adopt the practice of keeping a
local copy of all my 3rd party dependencies in my workspace, just so the
code will still exist 10 years down the road when I suddenly need to
recompile old code again.  I've been burned a couple of time with non-D
projects (these were C and C++ projects) where upstream of a 3rd party
lib either vanished into the ether, or decided to go ahead with a
totally breaking change with no migration path, AND the old version of
the code conveniently doesn't exist anymore.  I swore to myself that
I'll never rely ever again on the existence of some library source code
that only lives on some server somewhere out there on the 'Net.  If I
ever need a 3rd party lib, I'd better be darned sure I'm relying on a
local copy of it that's gonna STAY put forever (not just in some
temporary dub cache that can randomly get removed), until I don't need
it anymore.


That said, though, if D is forever going to remain in the realm of DIY
code, then it's never going to grow beyond what it is now.  We NEED to
promote more collaborative libs, not discourage them through gratuitous
breakages.



 Sometimes it may be more practical to bundle the library source in
 your codebase (as opposed to DUB registry) so you can fix it
 yourself. That has its downsides but it's still a valid choice.


 
 When your thing is open source it tends to become a problem eventually
 whether you like it or not.


Also, some things you may not be able to fix yourself.  E.g. if the lib
was a crypto lib and you're not a crypto expert.  Or fixing a
deprecation issue requires deep knowledge of the internal workings of
the lib, which you may not have.


T

-- 
That's not a bug; that's a feature!
Jun 08 2023
prev sibling parent reply Johan <j j.nl> writes:
On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:

 On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but 
 I think I reached my boiling point. I've been a (self 
 employed) full time D developer for almost 2 years now, 
 developing quite a large codebase of personal closed source 
 projects, as well as adopting some 3rdparty code like dlangui. 
 And my life has become particularly miserable in the last half 
 a year or so.

 I wish I was exaggerating, but __every__ new DMD version 
 breaks some of my code, to a smaller or bigger extent.


 Can't confirm. Can you give some examples, please? In my 
 experience (and we maintain a lot of D code), serious *new* 
 breakage (not an existing bug) is pretty rare.


Can 100% confirm (Weka), and I share the frustration. Breakage 
happens upon every release, with significant effort involved to 
find and fix the breakage (i.e. you hire a compiler dev for it = 
me).
Breakage is due to:
- Intentional change of behaviour, sometimes without clear 
solution path or with buggy solutions. 
https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for 
recent examples.
- New bugs due to some improvement or new functionality.

I'm not sure, but I think this is mostly due to a severe lack of 
rigorous test cases, and unstructured compiler implementation (no 
splitting of certain analyses into well-defined functions 
(copying around of complex analysis) and too many special cases 
all around the semantic analysis for example). A change made in 
part X, has high likelihood to change behaviour of a seemingly 
unrelated part Y, and the lack of test cases means it will go 
undetected.

The breakneck pace of releases means that the releases themselves 
do not get sufficient community testing (who tests betas?? lol, 
I'm still working on fixing the code for the release from last 
year). So every release is maintaining the level of immaturity 
(note: .0 releases I don't even consider, .1 or .2 (what LDC 
uses) is slightly better).

-Johan
Jun 08 2023
next sibling parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Thursday, 8 June 2023 at 17:20:25 UTC, Johan wrote:

 So every release is maintaining the level of immaturity (note: 
 .0 releases I don't even consider, .1 or .2 (what LDC uses) is 
 slightly better).

 -Johan


Personally I only use GDC in production and I've never had any 
surprises with their releases, I honestly would never use DMD in 
production I consider the quality of the backend insufficient for 
serious use in production.
I don't want to say a heresy, but sincerely if I had to decide 
for D the first thing I would do is stop work on DMD I don't see 
the real usefulness when we have LDC and GDC. Probably the 
primary development could be done on LDC to not have to be 
conditioned by the release times of GCC.
Jun 08 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jun 08, 2023 at 05:34:40PM +0000, Ernesto Castellotti via Digitalmars-d
wrote:

 On Thursday, 8 June 2023 at 17:20:25 UTC, Johan wrote:

 So every release is maintaining the level of immaturity (note: .0
 releases I don't even consider, .1 or .2 (what LDC uses) is slightly
 better).




[...]

 Personally I only use GDC in production and I've never had any
 surprises with their releases, I honestly would never use DMD in
 production I consider the quality of the backend insufficient for
 serious use in production.  I don't want to say a heresy, but
 sincerely if I had to decide for D the first thing I would do is stop
 work on DMD I don't see the real usefulness when we have LDC and GDC.
 Probably the primary development could be done on LDC to not have to
 be conditioned by the release times of GCC.


DMD is Walter's baby, and he'll probably let it go only over his dead
body. :-D

To be fair, though, for all its flaws DMD has one upside: super-fast
compile speed, which is valuable during development because the shorter
your code-compile-test cycle is, the more productive you are.

For final builds of almost anything (except shell-script replacements
where codegen quality is irrelevant), I wouldn't touch DMD with a
10-foot pole. Its codegen quality is just too low, esp. when it comes to
performance of the resulting executable. Over the years I've
consistently gotten 30-40% speed improvements with LDC over DMD,
sometimes even 50%.  LDC is my go-to compiler for serious work.  Once in
a while I use gdc and find that it has comparable codegen quality to
LDC.


T

-- 
In theory, there is no difference between theory and practice.
Jun 08 2023
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Thursday, 8 June 2023 at 20:55:20 UTC, H. S. Teoh wrote:

 DMD is Walter's baby, and he'll probably let it go only over 
 his dead body. :-D


Of course, in fact I was referring to a utopian situation ;-D


 To be fair, though, for all its flaws DMD has one upside: 
 super-fast compile speed, which is valuable during development 
 because the shorter your code-compile-test cycle is, the more 
 productive you are.


Yes that's true, however I don't see all this difference compared 
to GDC or LDC. For me it's not enough to concentrate the time in 
the development of DMD, killing DMD I think it's wrong but I if I 
was in the utopian situation of being able to decide anything 
about D I would keep it exclusively as a best effort side project


 For final builds of almost anything (except shell-script 
 replacements where codegen quality is irrelevant), I wouldn't 
 touch DMD with a 10-foot pole. Its codegen quality is just too 
 low, esp. when it comes to performance of the resulting 
 executable. Over the years I've consistently gotten 30-40% 
 speed improvements with LDC over DMD, sometimes even 50%.  LDC 
 is my go-to compiler for serious work.  Once in a while I use 
 gdc and find that it has comparable codegen quality to LDC.


 T


True, LDC is really good.
GDC starting from GCC 12 version started to get really 
interesting (so much so that now I've replaced LDC with GDC in 
production because it's much easier for me to handle for my 
embedded programming) because it is updated to recent D versions.
I believe that no one can ever reward enough Iain Buclaw for the 
great work he did with GDC, having a D compiler on GCC mainline 
is just amazing.
Jun 08 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jun 08, 2023 at 09:05:18PM +0000, Ernesto Castellotti via Digitalmars-d
wrote:
[...]

 GDC starting from GCC 12 version started to get really interesting (so
 much so that now I've replaced LDC with GDC in production because it's
 much easier for me to handle for my embedded programming) because it
 is updated to recent D versions.


I stuck with LDC mainly for the ease of cross-compiling to Windows. All
I need is to download the LDC releases for Linux and Windows, modify a
config file, and it's ready to go.  Cross-compiling with GDC is much
trickier to setup, and can be fragile if you're not 100% sure what
you're doing.



 I believe that no one can ever reward enough Iain Buclaw for the great
 work he did with GDC, having a D compiler on GCC mainline is just
 amazing.


To get a language into GCC mainline takes dedication and skill. The GCC
codebase isn't the most friendly to work with if you're not familiar
with it. And getting code to the point that it gets accepted into
mainline takes some real skillz.  But it also takes time -- IIRC it took
many years for Iain to push it through to GCC mainline.  That takes
dedication: long, dogged persistence.  It's really rare to find someone
who can do both.  Iain is a real treasure to the D community.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Jun 08 2023
parent Ernesto Castellotti <erny.castell gmail.com> writes:
On Thursday, 8 June 2023 at 21:33:37 UTC, H. S. Teoh wrote:

 I stuck with LDC mainly for the ease of cross-compiling to 
 Windows. All I need is to download the LDC releases for Linux 
 and Windows, modify a config file, and it's ready to go.  
 Cross-compiling with GDC is much trickier to setup, and can be 
 fragile if you're not 100% sure what you're doing.


Yeah great point, I hadn't thought about Windows because it's 
been years since I've done anything on Windows and in any case 
I've never used D for Windows programs only C++ :-(
Jun 08 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2023 10:20 AM, Johan wrote:

 - Intentional change of behaviour, sometimes without clear solution path or
with 
 buggy solutions. https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for 
 recent examples.


I suggest:

Restore the old getAttributes behavior, and create a new getAttributes2 with
the 
new behavior.

Will that work for you?
Jun 15 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 15 June 2023 at 07:07:18 UTC, Walter Bright wrote:

 On 6/8/2023 10:20 AM, Johan wrote:

 - Intentional change of behaviour, sometimes without clear 
 solution path or with buggy solutions. 
 https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for 
 recent examples.


 I suggest:

 Restore the old getAttributes behavior, and create a new 
 getAttributes2 with the new behavior.

 Will that work for you?


Going a bit offtopic, but this is one case where a true package 
system would come in handy! You could opt into migrations on a 
per-package basis, and have one compilation that mixes for 
instance different usages of `getAttributes` in different source 
files with no ambiguity or confusion.

One may even imagine bundling lots of migrations into "language 
editions" and updating those on a "long-term" basis.

dub.json:
```
     "edition": "d-2023",
```

(More at my dconf talk!)
Jun 15 2023
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 15 June 2023 at 07:07:18 UTC, Walter Bright wrote:

 Restore the old getAttributes behavior, and create a new 
 getAttributes2 with the new behavior.

 Will that work for you?


This is often even worse than just changing the original, so such 
things need to be evaluated on a case-by-case basis.

For the case of getAttributes, there's nothing actually wrong 
with the original behavior! The proposed getAttributes2 would be 
exactly identical to getAttributes, except that it gives a 
deprecation message on certain (currently ambigously defined, but 
could easily become defined) uses. There's no benefit to this and 
it would just add to long-term confusion as new people wonder 
what the differences are between the two.

(Something similar happened with getVirtualMethods and 
getVirtualFunctions. One was simply defined incorrectly and 
instead of fixing it, the other was introduced with a subtly 
different definition. That one is more justifiable than 
getAttributes2 would be, since it actually *was* defined, and 
*maybe* that subtle difference matters, and it is hard for the 
compiler to statically detect. But now the current result is you 
have a function that is wrong and a function that is right 
sitting side by side with only a careful reading of the docs 
revealing which is which.)

What I would suggest for getAttributes is either:

Option 1: Define its status quo behavior on the spec. If passed 
an overloaded function symbol, it will return the attributes of 
the lexically first function in the set. There's nothing actually 
wrong with that if people know what to expect and how to work 
with it! Put in the docs: Tip: you can use getOverloads to loop 
over all the overloads in the set. Optionally, change 
getOverloads so it also works on non-functions, so you can always 
loop over names and overloads (Even if a set of one item in the 
case of non-overloadable entities) without a separate branch.

OR

Option 2 (my preference): Sit down and define what, exactly, an 
overload set is in the language and make it into its own 
conceptual model with associated definitions in the reflection 
system. I don't have a specific proposal for D right now, but in 
my little script.d language, I made overload sets actually be an 
object with opCall defined. This is, of course, different since 
script.d is a dynamic language so many things, including overload 
resolution, happen at runtime. Indeed, this design was less about 
conceptual purity than about laziness in implementation - I 
already had objects and opCall working, so defining an object 
that internally had an array of functions and dispatched it was 
fairly easy.

But a side effect is the rest of the language can still work with 
it. I can loop over the overloads by... just literally looping 
over the overload set member in the object. You can detect it is 
an overload set by comparing object types. Other properties can 
be attached to it, etc.

That exact implementation is not right for D, but perhaps 
something similar could work. We could define all kinds of things 
in both the docs and in the language, iron out some edge cases, 
and make reflection easier to use.




Our random collection of of traits has served D well so far, but 
a second draft can learn a lot from its real world lessons and 
then both would exist side by side as a compatibility bridge.
Jun 15 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 15 June 2023 at 12:35:37 UTC, Adam D Ruppe wrote:

 Option 1: Define its status quo behavior on the spec. If passed 
 an overloaded function symbol, it will return the attributes of 
 the lexically first function in the set. There's nothing 
 actually wrong with that if people know what to expect and how 
 to work with it!


Yeah, hard disagree; or rather: "there's nothing actually wrong 
if people know what to expect and how to work with it" ... *and 
do so reliably*, which is to say that it is terrible. If you 
place a [pit of 
despair](https://blog.codinghorror.com/falling-into-the-pit-of-success/) next
to a feature, you should not blame the user for falling into it. The truth is,
`getAttributes` *invites* handling overloads wrong, it's a footgun, because
you'll probably not be testing it with overloads and unless you choose the
right tests, even if you do it will still appear to work correctly, while
silently executing a behavior that you probably won't expect and definitely
won't notice until a user complains years later when you have long moved on to
another project.
Jun 15 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Option 1 looks pretty good. Letting the user combine it with getOverloads
sounds 
good.
Jun 15 2023
prev sibling parent Johan <j j.nl> writes:
On Thursday, 15 June 2023 at 07:07:18 UTC, Walter Bright wrote:

 On 6/8/2023 10:20 AM, Johan wrote:

 - Intentional change of behaviour, sometimes without clear 
 solution path or with buggy solutions. 
 https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for 
 recent examples.


 I suggest:

 Restore the old getAttributes behavior, and create a new 
 getAttributes2 with the new behavior.

 Will that work for you?


Weka is using its own fork of the compiler (*), so indeed this is 
what I had tried, but Phobos was also adjusted and I try to stick 
to "no Phobos modifications" to prevent diverging even further 
from upstream.
I'll think I'll settle on the workaround as suggested in the bug 
report (assuming it works out for us).

-Johan

(*) because we have such reverts / cherry-picks
Jun 15 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/8/23 9:38 AM, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but I think I 
 reached my boiling point. I've been a (self employed) full time D 
 developer for almost 2 years now, developing quite a large codebase of 
 personal closed source projects, as well as adopting some 3rdparty code 
 like dlangui. And my life has become particularly miserable in the last 
 half a year or so.
 
 I wish I was exaggerating, but __every__ new DMD version breaks some of 
 my code, to a smaller or bigger extent. It can be either my own code, or 
 dependency code, but I started drowning in deprecation messages or 
 outright breakage. It's nearly impossible to develop any reasonable 
 3rdparty in those conditions. I'm tired of fixing things that weren't 
 broken. And I can't even imagine having to support multiple branches of 
 code because of those deprecations. But I probably should, as, 
 periodically, I get issues that dlangui can't compile with some outdated 
 dmd version. It's just insane!


I'm not saying your wrong or arguing with you, but you need to give 
specific examples. We can do nothing about general nebulous problems.

I know about the deprecation messages from DIP1000, I don't like those 
either (deprecation messages for my vibe-d project went from like 5 
(that are my fault) to 20,000).

-Steve
Jun 08 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 8 June 2023 at 14:08:05 UTC, Steven Schveighoffer 
wrote:

 On 6/8/23 9:38 AM, GrimMaple wrote:
 I know about the deprecation messages from DIP1000, I don't 
 like those either (deprecation messages for my vibe-d project 
 went from like 5 (that are my fault) to 20,000).

 -Steve


I think Grim meant this one: 
https://twitter.com/grim_maple/status/1666783261144522753?s=46&t=fQTa8qEB1aBjOkD2ftKKbA

Also another user mentioned previously about 
__traits(getAttributes) deprecation and problems with dyaml 
package
Jun 08 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/8/23 10:15 AM, Sergey wrote:

 On Thursday, 8 June 2023 at 14:08:05 UTC, Steven Schveighoffer wrote:

 On 6/8/23 9:38 AM, GrimMaple wrote:
 I know about the deprecation messages from DIP1000, I don't like those 
 either (deprecation messages for my vibe-d project went from like 5 
 (that are my fault) to 20,000).


 
 I think Grim meant this one: 
 https://twitter.com/grim_maple/status/1666783261144522753?s=46&t=fQTa8qEB1aBjOkD2ftKKbA


That's a segfault bug in the compiler, not an intentional language issue.

I would love to ensure that every release of the compiler doesn't have 
any bugs, please let me know when you have figured out how to guarantee 
that.


 Also another user mentioned previously about __traits(getAttributes) 
 deprecation and problems with dyaml package


This I am interested in seeing, have a link?

-Steve
Jun 08 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 14:26:56 UTC, Steven Schveighoffer 
wrote:

 That's a segfault bug in the compiler, not an intentional 
 language issue.

 I would love to ensure that every release of the compiler 
 doesn't have any bugs, please let me know when you have figured 
 out how to guarantee that.


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.


 This I am interested in seeing, have a link?

 -Steve


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.
Jun 08 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/8/23 10:37 AM, GrimMaple wrote:

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

 That's a segfault bug in the compiler, not an intentional language issue.

 I would love to ensure that every release of the compiler doesn't have 
 any bugs, please let me know when you have figured out how to 
 guarantee that.


 
 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'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 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.


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
Jun 08 2023
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08.06.23 16:44, Steven Schveighoffer wrote:

 
 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?


Add dlangui to the list of 3rd-party projects?
Jun 08 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 14:44:00 UTC, Steven Schveighoffer 
wrote:

 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


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.
Jun 08 2023
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/8/23 10:56 AM, GrimMaple 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.


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
Jun 08 2023
next sibling parent GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 15:11:50 UTC, Steven Schveighoffer 
wrote:

 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.


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.
Jun 08 2023
prev sibling parent bachmeier <no spam.net> writes:
On Thursday, 8 June 2023 at 15:11:50 UTC, Steven Schveighoffer 
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.


But that's not the purpose of an LTS release. You do it so you 
can share your code with others without having to support every 
compiler release for the last several years. A good example for 
another language is what R does for Ubuntu releases:

https://cran.r-project.org/bin/linux/ubuntu/

Some background: It's a nightmare trying to install R packages on 
Linux these days because that's traditionally been done from 
source. One of the prolific package writers adds insane numbers 
of dependencies like he's writing Javascript, and many of those 
dependencies require compilation of C++, which has miserable 
compile times. It's not unusual to spend more than an hour 
installing a single package because you need a single function it 
provides. Since it got to the point of impractical to use R on 
Linux, someone created the c2d4u repo. As it says on the linked 
page: "The ‘c2d4u’ repository is only available for LTS 
releases." It doesn't matter which release is labeled LTS, what 
matters is that Ubuntu 20.04 and 22.04 are the only things they 
have to support - but they couldn't do that with Ubuntu labeling 
one of their releases every two years as LTS.

That's not to say that big fixes couldn't be backported if they 
were valuable. Just that it's orthogonal to LTS.
Jun 08 2023
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 8 June 2023 at 14:56:21 UTC, GrimMaple 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"?


At the end of every monthly meeting summary I post an open 
invitation for anyone who wants to bring something to us to 
discuss. I've been doing that for a while now. If you want to 
make the case for an LTS, that's the place to do it. Anytime you 
want to bring anything to the team, just email me and I'll bring 
you in.
Jun 08 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 15:22:46 UTC, Mike Parker wrote:

 At the end of every monthly meeting summary I post an open 
 invitation for anyone who wants to bring something to us to 
 discuss. I've been doing that for a while now. If you want to 
 make the case for an LTS, that's the place to do it. Anytime 
 you want to bring anything to the team, just email me and I'll 
 bring you in.


As far as I appreciate your efforts, becoming a language 
developer was never my intention. Especially, for free. I have 
other things to write (in D, mind you), and I'm only willing to 
help as much as I can -- I steadily file bug reports every time I 
encounter something; I'm keeping some code up to date; I 
contribute to other D libraries that I can contribute to. All I'm 
saying is, any further coding in D is going to be impossible if 
no effort is brought into stabilizing the language.
Jun 08 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 8 June 2023 at 15:29:08 UTC, GrimMaple wrote:


 As far as I appreciate your efforts, becoming a language 
 developer was never my intention. Especially, for free. I have 
 other things to write (in D, mind you), and I'm only willing to 
 help as much as I can -- I steadily file bug reports every time 
 I encounter something; I'm keeping some code up to date; I 
 contribute to other D libraries that I can contribute to. All 
 I'm saying is, any further coding in D is going to be 
 impossible if no effort is brought into stabilizing the 
 language.


I'm not saying you should become a language developer. I'm saying 
if you have a strong case for an LTS release, bring it. I'm sure 
it's come up before, but no one has ever pushed it in a meeting 
that I can recall. I can't speak for everyone, but I wouldn't 
mind seeing it. I just know that there's a mountain of other work 
that we're putting a priority on right now, and until someone 
pushes it, I doubt anyone's going to pick it up.
Jun 08 2023
parent reply mw <mingwu gmail.com> writes:
On Thursday, 8 June 2023 at 15:38:15 UTC, Mike Parker wrote:

 On Thursday, 8 June 2023 at 15:29:08 UTC, GrimMaple wrote:

 I'm not saying you should become a language developer. I'm 
 saying if you have a strong case for an LTS release, bring it. 
 I'm sure it's come up before, but no one has ever pushed it in 
 a meeting that I can recall. I can't speak for everyone, but I 
 wouldn't mind seeing it. I just know that there's a mountain of 
 other work that we're putting a priority on right now, and 
 until someone pushes it, I doubt anyone's going to pick it up.


Too much bureaucracy: just look at:

1) How fast this threads grow: 30 replies in ~3 hours! esp. from 
developers who are maintaining real projects.

2) And, how many times this topic have been raised in this forum 
again and again.
Jun 08 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 8 June 2023 at 17:49:27 UTC, mw wrote:

 1) How fast this threads grow: 30 replies in ~3 hours! esp. 
 from developers who are maintaining real projects.

 2) And, how many times this topic have been raised in this 
 forum again and again.


I am a developer who maintains real (commercial!) projects, and I 
want D to break more compatibility and do less stability. Just, 
you know, for reference.

Every time a complaint threat comes up, it tends to hog the 
frontpage. This sort of forum mechanics selects for *engagement*, 
not agreement. Note how my responses disagreeing with you bump 
the thread just as much as responses that agree.

Also, at the end of the day, language development is not a poll. 
There are some good arguments for (and against) a D3 split; "look 
how many posts can get spammed on this thread" is not one of 
them. Otherwise we should probably go and make `private` class 
scope as well...
Jun 08 2023
parent GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 19:34:41 UTC, FeepingCreature wrote:

 I am a developer who maintains real (commercial!) projects, and 
 I want D to break more compatibility and do less stability. 
 Just, you know, for reference.


Maintaining closed-source commerical projects isn't a problem 
with changing compiler. Because you only need to support one 
version at a time. Then, try writing open-source with many users, 
all of whom use different versions (and vendors) of compiler. Now 
you're in trouble.


 Also, at the end of the day, language development is not a 
 poll. There are some good arguments for (and against) a D3 
 split; "look how many posts can get spammed on this thread" is 
 not one of them. Otherwise we should probably go and make 
 `private` class scope as well...


D3 split doesn't hurt anyone. I don't know about making `private` 
class scope. If it doesn't hurt people - why not. After all, the 
"support" of an LTS branch will most likely go towards those 
interested in that branch, while others can use D3 if they want 
breaking changes.

Of course it's not a poll, but if issues come up repeatedly, then 
you have to listen to them. I don't understand how LTS is such a 
bad idea that everyone is so aggressively against it. It's not 
like we're stealing your freedom to do whatever, we're proposing 
(or at least trying to) a solution that theoretically should 
fulfill both ends needs.


 The thing is that D doesn't have structure enough to get a LTS.
 We can only try to always get newest ones because we don't want 
 to deal with old and nasty > bugs.


As someone in this thread pointed out already, LTS doesn't really 
require a lot of work to begin with. Just fix behavior in-place, 
with occasional security and segfault patches. At least, a 
working strategy could be developed according to amount of 
manpower.

Also, "D doesn't have structure" isn't coming from the nature of 
things. It has no structure because nobody is giving it structure.

I also find it very amusing how, supposedly, Walter has a final 
say anyway, but it's always the community's fault for D lacking 
structure, or manpower, or anything else.

I would've liked to see a negotiation point from the D core team, 
like: "We can do an LTS branch, if: #list
we can allocate people, assign roles, maybe even raise funds. But 
I hate it when core devs just show up saying "nah can't be 
bothered you do it". Because I know, at the end of the day, 
Walter can just say "no" and all the effort will go down the 
drain.

I find the whole idea of LTS pointless when the core community 
isn't interested in working towards that goal. I mean, if the 
initial author of LTS leaves, what are you stuck with?
Jun 08 2023
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 8 June 2023 at 15:22:46 UTC, Mike Parker wrote:

 On Thursday, 8 June 2023 at 14:56:21 UTC, GrimMaple 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"?


 At the end of every monthly meeting summary I post an open 
 invitation for anyone who wants to bring something to us to 
 discuss. I've been doing that for a while now. If you want to 
 make the case for an LTS, that's the place to do it. Anytime 
 you want to bring anything to the team, just email me and I'll 
 bring you in.


A formal meeting with idk how many people but id guess like 6 
people where your posting minutes is hardly an invitation Id 
accept.

Formality and 1 on 6 is scary; id suggest different methods to 
get information from people who dont feel listened to.
Jun 09 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 10 June 2023 at 00:32:33 UTC, monkyyy wrote:

 A formal meeting with idk how many people but id guess like 6 
 people where your posting minutes is hardly an invitation Id 
 accept.

 Formality and 1 on 6 is scary; id suggest different methods to 
 get information from people who dont feel listened to.


Our meetings are far from formal. And it's in no way a scenario 
in which all of us will gang up on any one person. Often, we 
disagree with each other at first and discuss our way to 
agreement.

Adam and Steve are regular members now. Nick Treleaven joined us 
last time and may become either a semi-regular or regular member. 
There's much benefit to having a range of viewpoints, and I think 
once anyone comes in, any trepidation or uncertainty they have 
will disappear once they see how it goes.

And if anyone doesn't want their words to appear in the summary, 
all they have to do is tell me. That's why I call them 
"summaries" and not "minutes".
Jun 09 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Saturday, 10 June 2023 at 05:43:39 UTC, Mike Parker wrote:

 Our meetings are far from formal. And it's in no way a scenario 
 in which all of us will gang up on any one person. Often, we 
 disagree with each other at first and discuss our way to 
 agreement.

 Adam and Steve are regular members now. Nick Treleaven joined 
 us last time and may become either a semi-regular or regular 
 member. There's much benefit to having a range of viewpoints, 
 and I think once anyone comes in, any trepidation or 
 uncertainty they have will disappear once they see how it goes.

 And if anyone doesn't want their words to appear in the 
 summary, all they have to do is tell me. That's why I call them 
 "summaries" and not "minutes".


Long story short, what is there to discuss, if a simple question 
like "What are the requirments for the D team to consider LTS 
branch/release" is hanging unanswered? I don't believe that 
discussing such a thing is worth my (or anyone else's) time just 
because nobody cares enough to give straight answers. Without 
resorting to [please forgive my momentary rudeness] idiotic 
suggestions to come to some arbitrary meeting to discuss 
essentially nothing.

I am willing to come to the meeting, fine, but only after some 
common ground is found on topics of:
1. Needing LTS in the first place
2. Requirments and prerequisites for such an event
3. Your (D team's) proposition on how such thing could be 
achieved, and what resources are necessary for it

So far I only saw endless debates on wether LTS is even needed, 
and some abstract talk about "gib monez" without any concrete 
propositions.

Otherwise, this is a waste of everyone's time.
Jun 10 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 10 June 2023 at 08:58:34 UTC, GrimMaple wrote:


 Long story short, what is there to discuss, if a simple 
 question like "What are the requirments for the D team to 
 consider LTS branch/release" is hanging unanswered? I don't 
 believe that discussing such a thing is worth my (or anyone 
 else's) time just because nobody cares enough to give straight 
 answers. Without resorting to [please forgive my momentary 
 rudeness] idiotic suggestions to come to some arbitrary meeting 
 to discuss essentially nothing.

 I am willing to come to the meeting, fine, but only after some 
 common ground is found on topics of:
 1. Needing LTS in the first place
 2. Requirments and prerequisites for such an event
 3. Your (D team's) proposition on how such thing could be 
 achieved, and what resources are necessary for it

 So far I only saw endless debates on wether LTS is even needed, 
 and some abstract talk about "gib monez" without any concrete 
 propositions.

 Otherwise, this is a waste of everyone's time.


You're the one pushing for an LTS release. If you have a case to 
make for it, then you're welcome to come to the meeting and 
discuss it. I can't speak for everyone on the team. You might 
find support, you might not. The invitation's there, without any 
preconditions. Take it or leave it.
Jun 10 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Saturday, 10 June 2023 at 09:31:07 UTC, Mike Parker wrote:

 You're the one pushing for an LTS release. If you have a case 
 to make for it, then you're welcome to come to the meeting and 
 discuss it. I can't speak for everyone on the team. You might 
 find support, you might not. The invitation's there, without 
 any preconditions. Take it or leave it.


With that attitutude, I choose to "leave it".
Jun 10 2023
parent reply Rune Morling <ermo serpentos.com> writes:
On Saturday, 10 June 2023 at 10:34:06 UTC, GrimMaple wrote:

 On Saturday, 10 June 2023 at 09:31:07 UTC, Mike Parker wrote:

 You're the one pushing for an LTS release. If you have a case 
 to make for it, then you're welcome to come to the meeting and 
 discuss it. I can't speak for everyone on the team. You might 
 find support, you might not. The invitation's there, without 
 any preconditions. Take it or leave it.


 With that attitutude, I choose to "leave it".


How come? Mike is saying you're more than welcome to state your 
case? Are you suggesting that you'll only bother to do so if it's 
a foregone conclusion that it'll indeed happen?

That seems an odd tack to take for something you apparently feel 
quite strongly about?

Also, see Iain's message above; 2.076 is already the _de facto_ 
LTS due to GDC requirements (I believe ADR made this argument 
recently in the Discord too).

 From my limited perspective, the ideal case here is LDC and GDC 
working together on the _de facto_ LTS versions re. backporting 
important patches it seems. I'll leave the discussion of how that 
could work to more knowledgeable people.

In other words: This is _really close_ to happening is my 
impression. Why wouldn't you want to be one of the people helping 
to bring it over the goal line re. DLF buy-in so _you actually 
get what you were after in the first place?_
Jun 11 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Sunday, 11 June 2023 at 19:33:42 UTC, Rune Morling wrote:

 How come? Mike is saying you're more than welcome to state your 
 case? Are you suggesting that you'll only bother to do so if 
 it's a foregone conclusion that it'll indeed happen?


No. I am suggesting that there is no reason to believe that this 
"meeting" is going to be productive in any way. What going to 
happen is, I will join the meeting, and then get reiterated 
everything that's already been said here. Things like:


 It's just that I can't see how it would be effective.


If Walter can't see how it would be effective, and actually 
directly disagreeing with me:


 Making LTS versions balkanizes the language into multiple 
 languages, which will play hell with 3rd party library 
 maintenance.


How can I convince him otherwise? Just say "no u wrong"? This 
isn't going to work. Or, rather, why __would__ I even bother 
convincing him, when a clearly better solution for me would be to 
simply switch languages. Where I wouldn't even __need__ to 
support a GUI library to have one.

I have already said that, IMO, to understand my point, core D 
should try supporting some of the 3rd party. Maybe then they'll 
have to deal with all that versioning stuff. And maybe then 
they'll realize that LTS is needed. After all, there are things 
you can't understand until you're struck by them.


 That seems an odd tack to take for something you apparently 
 feel quite strongly about?


Some develop the langauge, some use the language. I'm not a 
language developer, and I don't intend on becoming one. If I 
wanted to, I'd just make my own language. Because there is only 
this much resistance I'm willing to go through __for free__. I 
have my daily job (in D!), but I'm still willing to commit in 
ways that can be found productive by both parties. Arguing with 
Walter isn't something I'm going to do, even for money.
As someone said in this thread previously, D is heavily biased 
towards language __developers__, not language __users__.


 From my limited perspective, the ideal case here is LDC and GDC 
 working together on the _de facto_ LTS versions re. backporting 
 important patches it seems. I'll leave the discussion of how 
 that could work to more knowledgeable people.


 From my limited perspective, GDC is awful and is not good for 
production. Then again, it's not like any other D compiler is 
"good enough", maybe LDC is. But anyway, in practice, GDC is a 
rare beast and most people use DMD/LDC. Maybe if GDC is promoted 
as "default" D compiler, then yes, we're getting there. But this 
wasn't suggested by anyone from the D team. They don't even want 
to spend 5 to 10 minutes coming up with ideas on my _direct_ 
question:


 What is your take, what will allow us to have an LTS branch?


So, again, there's simply nothing to discuss. I'm not big into 
how D team internals work, so how can I know what they want/need.


 In other words: This is _really close_ to happening is my 
 impression. Why wouldn't you want to be one of the people 
 helping to bring it over the goal line re. DLF buy-in so _you 
 actually get what you were after in the first place?_


Contributing to any open-source project isn't a privilege. At 
least it shouldn't be, in my opinion. Especially, when everyone 
is saying how they "lack manpower". But when issues are brought 
up, they just resort to "nah" or "do it yourself". And even when 
you _do_ it yourself, you end up in pages of useless arguing and 
very little productive being achieved. Or even your commits being 
reverted *sigh*

It's not that I expect D team to go and magically fix all my 
issues, and I never implied that. I'm jsut a language user 
~~crying for help~~ coming up with a proposal to improve the 
language. I don't have expertise to be a language developer. And 
I sure don't expect blatant disagreeing and responsibility 
dodging from the D team. What I expect is:

   1. Understanding the problem
   2. Proposing a possible solution with a list of requirments
   3. Analyzing possible pitfalls to discuss

Only then a meeting is necessary. Those 3 steps can easily be 
discussed in a forum post without wasting everyone's time with 
pointless banter. I outlined the preconditions for (actually any) 
meeting:


 I am willing to come to the meeting, fine, but only after some 
 common ground is found on
 topics of:

    Needing LTS in the first place
    Requirments and prerequisites for such an event
    Your (D team's) proposition on how such thing could be 
 achieved, and what resources are necessary for it


Otherwise (I'm probably repeating myself too much) there's simply 
__nothing to talk about__. It will be a stupid, pointless, 
phylosophical debate with nothing productive being achieved.


You can read this as: I'm a user that is willing to contribute, 
but I'm not going to spend my time begging and arguing, because 
there are other languages. I already spent enough time trying to 
do good things for D, and there is a decent chunk of sunk cost 
fallacy, but this can't go on forever. What angries me the most 
is how everyone is blatantly ignorant about users that they lose. 
For the love of everything that's holy, I already started my most 
recent project in **C++**, because it's just easier, despite 
everything bad about the language.

Take this with a little grain of salt, because I already stopped 
beginning projects in D. LTS isn't even the only problem with the 
language. It's one of the many that make D actually _unusable_ in 
modern day programming. Unfortunately, none of them are being 
addressed.

P.S. I still don't understand why D team expects people to spend 
hours and days to get very little done in regards of 
productivity. Despite how many people have left because of those 
reasons. I don't understand why D treats 3rd party developers as 
morons/idiots/non-importnat people (please select the correct 
one), and why they still make no effort to support said 3rd 
party. Modern day programming is impossible without third-party. 
Because people would rather deal with C++ that has everything, 
than enjoy D that has nothing. (and it's not like D is really an 
enjoyable language to begin with)
Jun 11 2023
parent Ernesto Castellotti <erny.castell gmail.com> writes:
On Sunday, 11 June 2023 at 22:25:48 UTC, GrimMaple wrote:

 From my limited perspective, GDC is awful and is not good for 
 production. Then again, it's not like any other D compiler is 
 "good enough", maybe LDC is. But anyway, in practice, GDC is a 
 rare beast and most people use DMD/LDC.


I don't understand why you say GDC is awful, it's simply D GCC 
frontend and behaves as one would expect from GCC.

GDC (like all GCC frontends) also has a great professional manual 
where it explains everything there is to know about the compiler, 
far superior to any other D compiler where the documentation I do 
not consider excellent.

What are your problems with GDC?


 But this wasn't suggested by anyone from the D team.


It's literally on the dlang download web page, 
https://dlang.org/download.html.
I would say that it is certainly to be considered among the 
officially recommended compilers


 P.S. I still don't understand why D team expects people to 
 spend hours and days to get very little done in regards of 
 productivity. Despite how many people have left because of 
 those reasons.


I doubt the D team expects anything from people
Jun 11 2023
prev sibling next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jun 08, 2023 at 02:56:21PM +0000, GrimMaple via Digitalmars-d wrote:
[...]

 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.


Here's a wild idea:
- Go through code.dlang.org and compile them with the latest compiler.
- Add *every* project that compiles to the buildkite list.
- Repeat this every release cycle.
- In the meantime, if anyone comes across any D project anywhere, as
  long as the source is public add it to buildkite.

OK, that takes care of coverage. By this point the core devs are
probably already screaming, "who's gonna fix broken builds when an
unmaintained project stops compiling?"

My answer is:
- For every buildkite breakage, contact the maintainer and ask him to
  fix the code.
- If he doesn't respond (the project is abandoned / inactive), the PR
  submitter should figure out a way of fixing / working around the
  problem.  THEN ADD THE WORKAROUND TO THE COMPILER. Either offer a flag
  to enable the workaround, or have the compiler generate an error
  message with explicit instructions of how to fix the problem.


The idea as presented above is probably impractical for a ton of
reasons. But it's a starting point. Somewhere to begin taking practical
steps attacking this problem, rather than sweeping it under the rug or
just yelling at each other.


T

-- 
Let X be the set not defined by this sentence...
Jun 08 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2023 7:56 AM, GrimMaple 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.


It's not about not caring about it. It's just that I can't see how it would be 
effective. Making LTS versions balkanizes the language into multiple languages, 
which will play hell with 3rd party library maintenance.

Clearly, the deprecation scheme is not serving our users well. We'll have to 
find a better way.
Jun 09 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 It's not about not caring about it. It's just that I can't see 
 how it would be effective. Making LTS versions balkanizes the 
 language into multiple languages, which will play hell with 3rd 
 party library maintenance.


I disagree with this statement, and I see a lot of people 
agreeing with my disagreement :)
LTS is LTS for a reason, meaning that 3rdparty will (ideally) 
only target LTS, without having to target unpredictable compiler. 
I don't understand how this is going to be worse for 3rd party, I 
only see wins. Have you read the thread btw?  I already posted an 
example (https://github.com/FreeSlave/icontheme/issues/2) where 
one person outright __refused__ to do anything about their broken 
code. I'll copy-paste the reasoning (it's about deprecated alias 
this):


 Honestly I don't know how to fix it without breaking/revamping 
 the code.
 The solution proposed in the dmd changelog didn't work for me.
 It also looks wrong and insufficient at all.


As for tis part:

 Clearly, the deprecation scheme is not serving our users well. 
 We'll have to find a better way.


The better way has been proposed already, it's just being 
dismissed without consideration. What is your take, what will 
allow us to have an LTS branch?
Jun 09 2023
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 9 June 2023 at 09:22:10 UTC, GrimMaple wrote:

 I disagree with this statement, and I see a lot of people 
 agreeing with my disagreement :)
 LTS is LTS for a reason, meaning that 3rdparty will (ideally) 
 only target LTS, without having to target unpredictable 
 compiler. I don't understand how this is going to be worse for 
 3rd party, I only see wins. Have you read the thread btw?  I 
 already posted an example 
 (https://github.com/FreeSlave/icontheme/issues/2) where one 
 person outright __refused__ to do anything about their broken 
 code. I'll copy-paste the reasoning (it's about deprecated 
 alias this):


How would LTS help? That only means they'll end up stuck at an 
old LTS version. It buys you a year, and then it breaks anyway.

You'd have to postulate a person who is okay with fixing *more* 
breaking changes, so long as it's more rarely. I'm skeptical.
Jun 09 2023
next sibling parent GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 9 June 2023 at 10:16:15 UTC, FeepingCreature wrote:

 How would LTS help? That only means they'll end up stuck at an 
 old LTS version. It buys you a year, and then it breaks anyway.


Answer is: planning and versioning. It's much easier to allocate 
your time to migrate once a year (ideally once every two years) 
than to end up in a constant loop of fixing small issues every 
month or so.

Breaking changes usually mean bumping major version number. This 
isn't what you want to do _every month_ when you develop some 
sort of third party. Long-term breakage is okay, as long as it 
happens less frequently. And, as long as this breakage is 
actually meaningful, not this "deprecate stuff because we can't 
fix it". My **user** opinion is, a well-known bug is better than 
correctly working code that breaks code that already works this 
known bug around.


 You'd have to postulate a person who is okay with fixing *more* 
 breaking changes, so long as it's more rarely. I'm skeptical.


Provided that there _will_ be more breaking changes. Actually, 
LTS branch will allow for more breakage short-term, allowing more 
freedom of D development, and resulting in less breakage 
long-term. Take this `alias this` issue mentioned earlier. If we 
had an LTS branch (or release), it could've been deprecated, and 
then un-deprecated again. Instead, since it's deprecated, there's 
no sense in un-deprecating it now since everyone kinda moved on 
already.
Jun 09 2023
prev sibling parent Martyn <martyn.developer googlemail.com> writes:
On Friday, 9 June 2023 at 10:16:15 UTC, FeepingCreature wrote:

 On Friday, 9 June 2023 at 09:22:10 UTC, GrimMaple wrote:

 I disagree with this statement, and I see a lot of people 
 agreeing with my disagreement :)
 LTS is LTS for a reason, meaning that 3rdparty will (ideally) 
 only target LTS, without having to target unpredictable 
 compiler. I don't understand how this is going to be worse for 
 3rd party, I only see wins. Have you read the thread btw?  I 
 already posted an example 
 (https://github.com/FreeSlave/icontheme/issues/2) where one 
 person outright __refused__ to do anything about their broken 
 code. I'll copy-paste the reasoning (it's about deprecated 
 alias this):


 How would LTS help? That only means they'll end up stuck at an 
 old LTS version. It buys you a year, and then it breaks anyway.

 You'd have to postulate a person who is okay with fixing *more* 
 breaking changes, so long as it's more rarely. I'm skeptical.


In my opinion, I do believe D is missing a LTS. It is needed.

For example, all I see are monthly releases. Which release should 
I be using? As the original post suggest, there are breaking 
changes not just in own code but with third-party libraries as 
well.


processes. Whenever I have an afternoon experimenting with D for 
a future project, I always hit a brick wall trying to test 
something.

For example nanomsg-wrapper. What am I doing wrong? No idea. I 
get errors. Now, since the creation of this post... maybe I need 
to use an older D release? However, if I then include another 
project, will have get more problems?

If we have a LTS build of, say. 18 months, the beta of the next 
build can be 12 after, allowing 6 months of tests and cleanups. 
It also allows third-parties to build their libraries/tools to 
LTS (as well as prepare for the next one)

I think .NET has a good system with .NET 5, .NET 6, etc. Of 
course, they likely have a larger team but I don't think an LTS 
workflow for D would cause that much problems? Monthly builds of 
dlang can continue, afterall.

Just my thoughts (and simplistic, I know.)
Jun 09 2023
prev sibling next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 9 June 2023 at 09:22:10 UTC, GrimMaple wrote:

 On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 It's not about not caring about it. It's just that I can't see 
 how it would be effective. Making LTS versions balkanizes the 
 language into multiple languages, which will play hell with 
 3rd party library maintenance.


 I disagree with this statement, and I see a lot of people 
 agreeing with my disagreement :)
 LTS is LTS for a reason, meaning that 3rdparty will (ideally) 
 only target LTS, without having to target unpredictable 
 compiler. [..]


What is your vision for LTS releases? How often would a new LTS 
version be released and for how much time would it be supported? 
How many LTS branches would be maintained in parallel? Something 
like the Ubuntu release cycle - 
https://ubuntu.com/about/release-cycle?
What is the range of supported versions that you would expect an 
actively maintained D library to support? Only the oldest LTS, or 
only newest one? What about the current versions?
What are the criteria for backporting changes to an LTS branch? 
While library functionality removals and new compiler errors are 
obviously a no-no, what about deprecations? On one hand, one 
would would prefer things to keep working as they were, but on 
the other hand deprecations are a migration tool - they let the 
users know that they need to adjust their code in order to be 
able to upgrade to a new version down the line.

There's also the question of certain bug fixes: usually druntime 
& phobos are straightforward, but there are some compiler bug 
fixes that can cause surprising regressions that are only 
discovered years (!) later, despite the best effort of everyone. 
I can assure you that this is not a theoretical concern - we've 
had hundreds of regression-causing bug fixes like this. The main 
cause is that the semantic processing part of the compiler 
codebase is very complex and convoluted. While some argue that 
the solution is ground-up from-scratch reimplemtnation (which is 
what the SDC project that has been years in the making is trying 
to accomplish), realistically, the most pragmatic option is to 
continuously refactor the codebase until it becomes much easier 
to maintain and evolve. Which is exactly what almost every major 
compiler contributor has worked towards on many occasions, but 
the reality is that we're still far from the place we want to be, 
and there's much more work to be done.

I don't expect the rate of change to decrease, (and I surely hope 
it doesn't as it means the development is dying!), so I would 
expect the divergence between the LTS release and the current one 
to constantly increase, both in terms of direct user-observable 
language changes, but also in terms of the codebase. There are 
many cases where in order to fix a bug you first need to refactor 
the code (so e.g. the logic is centralized in a single place and 
not spread across multiple files), which would make certain 
commits very difficult to apply to the LTS branch.

And even just in terms of user-facing changes, if the jump from 
LTS to the current release is too big, upgrading would become 
much more time consuming than the current status quo of a major 
release every two months, so in that sense, I would agree with 
Walter that this has the risk of splitting the community.


 I don't understand how this is going to be worse for 3rd party, 
 I only see wins.


While the past few releases may have been heavier on the 
deprecation side of things, once there's a new compiler release 
with shiny new feature X™, you're quite likely to get an influx 
of users requesting support for it, so sticking with an old 
compiler release is unlikely make everyone happy.
Jun 09 2023
parent GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 9 June 2023 at 10:59:35 UTC, Petar Kirov [ZombineDev] 
wrote:

 What is your vision for LTS releases? How often would a new LTS 
 version be released and for how much time would it be 
 supported? How many LTS branches would be maintained in 
 parallel? Something like the Ubuntu release cycle - 
 https://ubuntu.com/about/release-cycle?
 What is the range of supported versions that you would expect 
 an actively maintained D library to support? Only the oldest 
 LTS, or only newest one? What about the current versions?
 What are the criteria for backporting changes to an LTS branch? 
 While library functionality removals and new compiler errors 
 are obviously a no-no, what about deprecations? On one hand, 
 one would would prefer things to keep working as they were, but 
 on the other hand deprecations are a migration tool - they let 
 the users know that they need to adjust their code in order to 
 be able to upgrade to a new version down the line.


If it were up to me - I'd just split D into D2 and D3. D2 being a 
stable non-breaking lang that only adds upon what it already has. 
And D3 being a playground with "whatever goes", until peopel 
agree it's good enough and split for D4 is required. However, I 
understand other points of view as well, so having _at least_ 
some sort of stable release I am willing to treat as "good 
enough". A two-year cycle is a widely accept practice it seems, 
so why not adopt it?


 There's also the question of certain bug fixes: usually 
 druntime & phobos are straightforward, but there are some 
 compiler bug fixes that can cause surprising regressions that 
 are only discovered years (!) later, despite the best effort of 
 everyone. I can assure you that this is not a theoretical 
 concern - we've had hundreds of regression-causing bug fixes 
 like this. The main cause is that the semantic processing part 
 of the compiler codebase is very complex and convoluted. While 
 some argue that the solution is ground-up from-scratch 
 reimplemtnation (which is what the SDC project that has been 
 years in the making is trying to accomplish), realistically, 
 the most pragmatic option is to continuously refactor the 
 codebase until it becomes much easier to maintain and evolve. 
 Which is exactly what almost every major compiler contributor 
 has worked towards on many occasions, but the reality is that 
 we're still far from the place we want to be, and there's much 
 more work to be done.


I think, in the real world, if you don't add new stuff -- you end 
up with less bugs, provided you fix existing ones. As in, bug 
fixes rarely lead to introducing more bugs, it's the development 
of new features that usually bring new issues. If you localize 
refactorings to a concrete issue - it's not too difficult to 
backport everything. Anything else is, unfortunately, tough luck 
(tm). In my view, an LTS branch should only recieve critical 
bugfixes, such as compiler crashes or security vulnerabilities. 
If something leads to a buggy behavior - that's a thing that 
should be fixed in main branch and released in the next LTS.


 I don't expect the rate of change to decrease, (and I surely 
 hope it doesn't as it means the development is dying!), so I 
 would expect the divergence between the LTS release and the 
 current one to constantly increase, both in terms of direct 
 user-observable language changes, but also in terms of the 
 codebase. There are many cases where in order to fix a bug you 
 first need to refactor the code (so e.g. the logic is 
 centralized in a single place and not spread across multiple 
 files), which would make certain commits very difficult to 
 apply to the LTS branch.


In my opinion, that is only going to happen if D continues do 
develop with no clear goal or target. Lack of understanding where 
D is heading towards is creating that issue almost 
singlehandedly. Of course you're gonna divert the community if 
big changes are going to keep popping out of nowhere, like 
ImportC did. Infact, I think, LTS branch might help bring order 
to somewhat chaotic nature of D development cycle. Provided that 
D wants to have any order, which doesn't seem to be the case. 
Again, it boils down to the fact that D developers (the lang & 
compiler ones) don't really use D on a day-to-day baiss, outside 
of the compiler. So they can't even grasp what I and others are 
talking about. How could they, if their "work" never affects them 
to any extent, they are free to change and break whatever they 
want. They don't have to deal with the damages that they cause.


 And even just in terms of user-facing changes, if the jump from 
 LTS to the current release is too big, upgrading would become 
 much more time consuming than the current status quo of a major 
 release every two months, so in that sense, I would agree with 
 Walter that this has the risk of splitting the community.


It's still the same amount of changes, which are just easier to 
plan ahead for. And, again, it's not the changes themself that 
cause me pain, it's how frequent and breaking they are.


 While the past few releases may have been heavier on the 
 deprecation side of things, once there's a new compiler release 
 with shiny new feature X™, you're quite likely to get an influx 
 of users requesting support for it, so sticking with an old 
 compiler release is unlikely make everyone happy.


The whole __point__ of LTS is that everyone has the same version. 

LTS releases and nobody complained about the "recent" compiler 
being unsupported. Because everyone understands why it's called 
an "experimental" version, and they patiently wait for new LTS 
release.
Jun 09 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2023 2:22 AM, GrimMaple wrote:

 The better way has been proposed already, it's just being dismissed without 
 consideration. What is your take, what will allow us to have an LTS branch?


It's come up before many times, it's not like we haven't considered it.

We actually do have it - we do major releases, and point releases. Into the 
point releases go regression fixes and critical bug fixes.

The trouble, though, is we simply don't have the staff to do a whole lot with
this.
Jun 15 2023
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 It's not about not caring about it. It's just that I can't see 
 how it would be effective. Making LTS versions balkanizes the 
 language into multiple languages, which will play hell with 3rd 
 party library maintenance.


Think about it, if there wasn't a new D2 project that was 
decoupled from D1. Where would D be today? I strongly suspect D 
would be near as "rich" as it is today. D1 would just stand still 
stomping.

Now it is time again to make that leap. Balkanization is a 
necessary evil I think.
Jun 09 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jun 09, 2023 at 03:58:16PM +0000, IGotD- via Digitalmars-d wrote:

 On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 It's not about not caring about it. It's just that I can't see how
 it would be effective. Making LTS versions balkanizes the language
 into multiple languages, which will play hell with 3rd party library
 maintenance.


 
 Think about it, if there wasn't a new D2 project that was decoupled
 from D1.  Where would D be today? I strongly suspect D would be near
 as "rich" as it is today. D1 would just stand still stomping.
 
 Now it is time again to make that leap. Balkanization is a necessary
 evil I think.


I wasn't around during the D1/D2 split, but AFAIK there were D1 projects
that eventually had no way to transition to D2 because of fundamental
language discrepancies that had no migration path.

If D3 ever happens, it would be nice to think about feasible migration
paths for existing D2 code.

//

Also, as far as balkanization is concerned, I think we already have that
with -betterC and  nogc.  Let's just face it, folks, the people
embracing Phobos and GC are in their own camp, and the -betterC/ nogc
crowd is in another camp, and the two aren't seeing eye to eye.
Libraries written with Phobos in mind aren't compatible with betterC
code, and libraries written with  nogc in mind, while in theory
compatible with Phobos-using code, do present some friction (e.g., you
have to go out of your way to clean up after yourself instead of letting
the GC do it, like you would in non-betterC code; you can't pass a GC
callback to a  nogc library, etc.).

So, fear of balkanization IMO is fallacious.


T

-- 
The best compiler is between your ears. -- Michael Abrash
Jun 09 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 9 June 2023 at 16:22:15 UTC, H. S. Teoh wrote:

 I wasn't around during the D1/D2 split, but AFAIK there were D1 
 projects that eventually had no way to transition to D2 because 
 of fundamental language discrepancies that had no migration 
 path.


Indeed.

So worth noting that the D1/D2 split happened almost 
simultaneously: D2 came out about six months after D1. What 
happened previously is there was just the D language that changed 
randomly as it wanted. People asked for some long term support.

D1 was arbitrarily branched off. It became the "stable" version 
and the existing all-development version got rebranded D2.

This actually was a decent success for a while! Some big users 
stayed on stable successfully. But the stable thing eventually 
got dropped with no migration plan, and then there was never 
another stable release to replace it.

Would want to avoid repeating those latter mistakes.
Jun 09 2023
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jun 09, 2023 at 04:41:28PM +0000, Adam D Ruppe via Digitalmars-d wrote:

 On Friday, 9 June 2023 at 16:22:15 UTC, H. S. Teoh wrote:

 I wasn't around during the D1/D2 split, but AFAIK there were D1
 projects that eventually had no way to transition to D2 because of
 fundamental language discrepancies that had no migration path.


 
 Indeed.
 
 So worth noting that the D1/D2 split happened almost simultaneously:
 D2 came out about six months after D1. What happened previously is
 there was just the D language that changed randomly as it wanted.
 People asked for some long term support.
 
 D1 was arbitrarily branched off. It became the "stable" version and
 the existing all-development version got rebranded D2.
 
 This actually was a decent success for a while! Some big users stayed
 on stable successfully. But the stable thing eventually got dropped
 with no migration plan, and then there was never another stable
 release to replace it.
 
 Would want to avoid repeating those latter mistakes.


See, to me this proves that:

(1) LTS is viable for D;

(2) A migration path must be provided to move between LTS releases.

Point (1) is simple, at least in theory. (Well, simpl*er*, anyway.)

Point (2) is something we need to work on.  There should be a clear
migration path for every breaking change introduced to the language, and
this should be well-documented in a well-known place.  Probably it's too
onerous to do this for every release (though ideally that should be the
case), but at the very least there should be a solid migration plan from
one LTS release to the next.

That way, users who want/need stability will have a way to migrate to
newer releases, and won't be left behind with a 10yo obsolete compiler
because there's no migration path. Users who don't mind breakages every
now and then can just stay with the current releases.


T

-- 
Caffeine underflow. Brain dumped.
Jun 09 2023
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 On 6/8/2023 7:56 AM, GrimMaple 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.


 It's not about not caring about it. It's just that I can't see 
 how it would be effective. Making LTS versions balkanizes the 
 language into multiple languages, which will play hell with 3rd 
 party library maintenance.

 Clearly, the deprecation scheme is not serving our users well. 
 We'll have to find a better way.


2 versions is hardly balkanizing

Given even 1 wave of depreciations I would have dropped dlanggui; 
if grim says he needs an lts to continue supporting that ancient 
project I think theres a simple question:

Would you rather make an lts or let dlanggui die entirely?
Jun 09 2023
prev sibling next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/06/2023 8:05 PM, Walter Bright wrote:

 It's not about not caring about it. It's just that I can't see how it would be
effective.


Not making the compiler versions required to bootstrap the compiler LTS 
dooms our very ability to have a working compiler.

Without having C++ dumps of the compiler, before we did the whole self 
hosting thing was kinda short sighted.

Having LTS versions which work towards bootstrapping would certainly be 
beneficial to us long term and would allow us to solve the problem for 
the wider community who need stabilization.
Jun 09 2023
prev sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:

 On 6/8/2023 7:56 AM, GrimMaple 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.


 It's not about not caring about it. It's just that I can't see 
 how it would be effective. Making LTS versions balkanizes the 
 language into multiple languages, which will play hell with 3rd 
 party library maintenance.

 Clearly, the deprecation scheme is not serving our users well. 
 We'll have to find a better way.



On Thursday, 15 June 2023 at 07:39:02 UTC, Walter Bright wrote:

 It's come up before many times, it's not like we haven't 
 considered it.

 We actually do have it - we do major releases, and point 
 releases.
 Into the point releases go regression fixes and critical bug 
 fixes.

 The trouble, though, is we simply don't have the staff to do a 
 whole
 lot with this.



I understand this could be division (or maybe also to say 
repetition) to the core/language developers if we introduce LTS 
in D. I mean, if there was a security vulnerability that was 
fixed, it would need to be replicated on the active LTS releases, 
etc.

However, I do not see why this would cause a division for 3rd 
Party Libraries - as they *should* be targeting their releases 
towards LTS, anyway.


I think enough content has been voiced about LTS and, generally, 
appear to be on a similar wavelength by those in favour of it. 
Certainly enough for it to be discussed in a near future meeting 
with the core members.

I understand there might not be enough staff at this time and 
other factors. I get it. I still believe this can spark more 
discussion and, potentally, form a strategy on how **it could 
work** if we had X, Y and Z.

If a plan is presented and is understood on what needs to be done 
+ the work involved, maybe someone will step up and get involved.


Thanks.
Jun 15 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Frankly, anyone who wants to can step up and pick a version of D, declare it to 
be LTS, and pull only bug fixes to it, can do so.
Jun 16 2023
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version of 
 D, declare it to be LTS, and pull only bug fixes to it, can do 
 so.



 anyone


Coordination is not when everyone speaks.

All you need to say is "d version 99 is the lts for the next 3 
year" or maybe a formal blog post by 5ish people.
Jun 17 2023
next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Saturday, 17 June 2023 at 12:14:37 UTC, monkyyy wrote:
[•••]

 All you need to say is "d version 99 is the lts for the next 3 
 year"


👍👍👍
Jun 17 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 3 year" or maybe
a 
 formal blog post by 5ish people.


Somebody needs to step up and pull fixes into it.
Jun 18 2023
next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:

 On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 3 
 year" or maybe a formal blog post by 5ish people.


 Somebody needs to step up and pull fixes into it.


OK - while I am a developer that has used D for minor programs on 
my home systems (and someone who visits the forums and conf 
videos often) - I am happy to step up to support/contribute LTS. 
However, I am not in a position to do this right now. Not because 
"I am busy" or similar, I need to understand the internals and 
community process of the D language.

I guess I am a "user" of Dlang, but happy to dive into the dev 
world.

When I am ready (and noone else had stepped up to handling LTS) I 
will likely create a new post to kick things off officially.

Thanks.
Jun 19 2023
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Monday, 19 June 2023 at 10:35:34 UTC, Martyn wrote:

 On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:

 On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 
 3 year" or maybe a formal blog post by 5ish people.


 Somebody needs to step up and pull fixes into it.


 OK - while I am a developer that has used D for minor programs 
 on my home systems (and someone who visits the forums and conf 
 videos often) - I am happy to step up to support/contribute 
 LTS. However, I am not in a position to do this right now. Not 
 because "I am busy" or similar, I need to understand the 
 internals and community process of the D language.

 I guess I am a "user" of Dlang, but happy to dive into the dev 
 world.

 When I am ready (and noone else had stepped up to handling LTS) 
 I will likely create a new post to kick things off officially.

 Thanks.


Hi Martyn,

If you need any help in any direction, feel free to contact 
myself or Dennis on whatever channel you want (Gmail, slack, 
discord etc.)

Best regards,
RazvanN
Jun 19 2023
parent Martyn <martyn.developer googlemail.com> writes:
On Monday, 19 June 2023 at 13:59:25 UTC, RazvanN wrote:

 Hi Martyn,

 If you need any help in any direction, feel free to contact 
 myself or Dennis on whatever channel you want (Gmail, slack, 
 discord etc.)

 Best regards,
 RazvanN


Thank you!
Jun 19 2023
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:

 On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 3 
 year" or maybe a formal blog post by 5ish people.


 Somebody needs to step up and pull fixes into it.


If you go back only three years, that means there are currently 
nine major releases of DMD still in use in the wild, plus 
whatever releases of LDC and GDC have happened since then. Are 
they getting bug fixes? If not, why not?

We all know that requiring LTS to get all bug fixes makes it a 
big project, and that the probability of someone actually doing 
it is zero. It's not necessary and it's not sufficient to solve 
the problem of having to support too many compiler releases.
Jun 19 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Monday, 19 June 2023 at 13:38:58 UTC, bachmeier wrote:

 On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:

 On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 
 3 year" or maybe a formal blog post by 5ish people.


 Somebody needs to step up and pull fixes into it.


 If you go back only three years, that means there are currently 
 nine major releases of DMD still in use in the wild, plus 
 whatever releases of LDC and GDC have happened since then. Are 
 they getting bug fixes? If not, why not?

 We all know that requiring LTS to get all bug fixes makes it a 
 big project, and that the probability of someone actually doing 
 it is zero. It's not necessary and it's not sufficient to solve 
 the problem of having to support too many compiler releases.


I agree. While I don't think LTS releases needs to "get all bug 
fixes" - it doesn't stop it being a big project.

While some people may think this is a case of simply creating an 
LTS branch and... boom.. job done. It wont be as simple as that.

This needs some careful planning before going ahead with this. 
Besides, it is not worth putting effort into LTS if D developers 
are not onboard, especially library creators/maintainers. It is a 
change, afterall. One I am not willing to jump straight in 
without a cohesive plan.

This is especially the case for bug fixes towards an LTS - as we 
have to consider not just DMD, but GDC and LDC.

This wont be a one-man-task. I would guess atleast 3 people - 1 
per compiler.. minimum.

I don't think this will happen overnight. It will likely to be an 
oppotunity when it presents itself. How or when, I don't know. 
Maybe this wont come to fruition for a number of years.

   (wont stop me atleast looking into dmd compiler, atleast)

I want to see Dlang succeed. In my opinion, having LTS is a 
stepping stone towards this goal (even if it is a tiny stone in 
the grand scheme of things)
   - of course thats my opinion.
Jun 19 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
You're overthinking it a bit.

We have had (and to some extent still do) have LTS in terms of dmd-fe 
codebase.

It was done by Iain by himself pretty much.

https://forum.dlang.org/post/u5tg5u$1mce$1 digitalmars.com

See Iain's replies as to what needs to happen to do this proper.
Jun 19 2023
parent Martyn <martyn.developer googlemail.com> writes:
On Monday, 19 June 2023 at 14:28:04 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 You're overthinking it a bit.

 We have had (and to some extent still do) have LTS in terms of 
 dmd-fe codebase.

 It was done by Iain by himself pretty much.

 https://forum.dlang.org/post/u5tg5u$1mce$1 digitalmars.com

 See Iain's replies as to what needs to happen to do this proper.


Thanks - those replies might have skipped me. Will look for them.
Jun 19 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Monday, 19 June 2023 at 14:23:18 UTC, Martyn wrote:


 While some people may think this is a case of simply creating 
 an LTS branch and... boom.. job done. It wont be as simple as 
 that.


It actually is that simple. This is how the discussion is 
proceeding:

"There are too many compiler releases. It makes it hard to share 
libraries with others."

"Simple solution - have fewer compiler releases."

"We can only do that if someone's going to port bug fixes back to 
all previous releases of the compiler."

"Why? We're not doing that now?"

[Crickets chirping]

This problem has a simple solution. Fewer compiler releases. I'm 
all for bug fixes, but it has nothing to do with reducing the 
frequency of compiler releases. If bug fixes are that important, 
we'd already be doing it.
Jun 19 2023
parent Chris Katko <ckatko gmail.com> writes:
On Monday, 19 June 2023 at 17:55:40 UTC, bachmeier wrote:

 This problem has a simple solution. Fewer compiler releases. 
 I'm all for bug fixes, but it has nothing to do with reducing 
 the frequency of compiler releases. If bug fixes are that 
 important, we'd already be doing it.


No, I don't think solution is to significantly delay features on 
a rapidly developed language. Features draw new users in, and 
keep people remembering and thinking about a new language. "I 
wonder what cool thing I can do with this new feature"

I think a simple solution is mark all non-LTS releases as "beta", 
as in "buyer beware if you use these", and have an LTS release 
every 2/3/4 years. Having to update your codebase every say, 
"four years", isn't the end of the world if you know it's coming.

If anyone is using the "beta"/"unstable" branch (or whatever you 
want to call it), it's immediately on them "You should have 
anticipated this could happen" if something breaks compatibility 
as the language evolves. At least, it's in the language users 
mind that it "could" happen and lessens the mental blow when it 
_does_ happen. A kind of consenting to instability.

I would suggest two "branches". The latest LTS, and beta. You 
want reliability plus bugfixes, use the LTS. You want new 
features, use the beta. Expecting a small community to maintain 
more than two versions is unrealistic, and a nightmare for 
library developers.

As for removing features, I don't think that's been sufficiently 
addressed. (Unless I missed the relevant discussion somehow.) 
Removing features (without so much as a press release/blog post) 
is a very dangerous precedent that forces users to think "Will my 
next used feature be removed? Should I migrate to a new more 
stable language?".
Jun 23 2023
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:

 On 6/17/2023 5:14 AM, monkyyy wrote:

 All you need to say is "d version 99 is the lts for the next 3 
 year" or maybe a formal blog post by 5ish people.


 Somebody needs to step up and pull fixes into it.



 Coordination is not when everyone speaks.




Coordination is not when everyone speaks.

Your specifically the dictator for life, maybe md could write a 
formal blog post but there's a handful of voices that are "loud". 
An lts is a schelling point. It *can be* someone going out of 
their way to provide bug fixes and that is what makes it 
coordinated but it could also be like python 2 where the 
community just didn't upgrade for years.

If grim fixes a bug for version 2.87 and adr is trying to make 
something work on a d1 compiler and mir-whatevers maintains tests 
if their code works on 2.95; there no LTS there a bunch of people 
trying to fix their local problem, there's a (very very) wasteful 
coordination mechanisms for people without leaders such as what 
happens between fireflies. But, these take many cycles of 
messages and when those messages are headache-inducing bug fixes 
in ancient code the coordination may not happen before people 
leave.

If you say version 2.99 is the lts, and then store up a bunch of 
breaking changes for 2.125 then declare 2.124 the new lts. That 
may just work *without any extra bug fixes*, depending on how 
strongly the community trusts that message.Maybe grim ignores a 
bug report about 2.87 compiler, maybe mir tests upgrades its test 
suite to be 2.99 and maybe, just maybe, adr stops talking about 
the great d1 compile speeds and their actions may overlap better. 
Not likely, but it should be considered if you consider dlang gui 
important.
Jun 19 2023
prev sibling parent reply Dany12L <dany12719l gmail.com> writes:
On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version of 
 D, declare it to be LTS, and pull only bug fixes to it, can do 
 so.


After all this talk another unnecessary change that will break 
the code in the user has been accepted

https://github.com/dlang/dmd/pull/15319

Please Walter Bright check this...
Jun 18 2023
next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

 On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version of 
 D, declare it to be LTS, and pull only bug fixes to it, can do 
 so.


 After all this talk another unnecessary change that will break 
 the code in the user has been accepted

 https://github.com/dlang/dmd/pull/15319

 Please Walter Bright check this...


You know that this was actually a bug, right?
Jun 18 2023
parent reply Dany12L <dany12719l gmail.com> writes:
On Sunday, 18 June 2023 at 14:15:14 UTC, Hipreme wrote:

 On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

 On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version 
 of D, declare it to be LTS, and pull only bug fixes to it, 
 can do so.


 After all this talk another unnecessary change that will break 
 the code in the user has been accepted

 https://github.com/dlang/dmd/pull/15319

 Please Walter Bright check this...


 You know that this was actually a bug, right?


This is a deprecation that becomes an error, it should have been 
left as a deprecation
Jun 18 2023
parent Hipreme <msnmancini hotmail.com> writes:
On Sunday, 18 June 2023 at 14:18:40 UTC, Dany12L wrote:

 On Sunday, 18 June 2023 at 14:15:14 UTC, Hipreme wrote:

 On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

 On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright 
 wrote:

 Frankly, anyone who wants to can step up and pick a version 
 of D, declare it to be LTS, and pull only bug fixes to it, 
 can do so.


 After all this talk another unnecessary change that will 
 break the code in the user has been accepted

 https://github.com/dlang/dmd/pull/15319

 Please Walter Bright check this...


 You know that this was actually a bug, right?


 This is a deprecation that becomes an error, it should have 
 been left as a deprecation


Deprecation period serves to give people time for them to remove 
unexpected behaviors and bugs. Removing a feature is a thing, but 
fixing bugs and unexpected behaviors are completely other thing, 
deprecation periods usually takes 10 compiler versions, one 
should not expect them to keep working anyway after some time
Jun 18 2023
prev sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

 On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version of 
 D, declare it to be LTS, and pull only bug fixes to it, can do 
 so.


 After all this talk another unnecessary change that will break 
 the code in the user has been accepted

 https://github.com/dlang/dmd/pull/15319

 Please Walter Bright check this...


I'm not sure about that one myself, even though I did it. (See my 
comment.) Right now, I'm mostly just hoping that nobody is 
calling private methods in that way. As I said, I could split it 
out into a separate deprecation but that would require undoing 
the error unification in the fix PR. And the whole this error 
happened like three separate times is because this check is split 
over a bunch of separate codepaths, so I'd hate to contribute to 
making it worse.

That said, the language working as specified and documented is 
not an "unnecessary change".

I think we're running the risk of falling into a hole of "code is 
fragile and unmaintainable, so don't change anything ever." 
Longstanding bugs going unfixed is a major contributor to code 
that is fragile and unmaintainable, because you cannot trust what 
it says! Not to mention this makes D a hellhole for new people to 
learn.

Years ago, I noted that learning D is not primarily a matter of 
learning the language. The language is intuitive and 
straightforward. Instead, learning D is primarily a matter of 
memorizing all the diverse places where the language is *not* 
intuitive and in fact is broken and you just have to avoid them. 
I think cutting down on that is more important than preserving 
the very specific ways in which you are sometimes permitted to 
call a private method if you have placed an unrelated public 
method in the right location in your code.

That said, honestly, look at the bug. They're calling a private 
method! That means they, or at least somebody, intended it to 
*not* be called! Even on its own merits, I really think this is a 
case where an error is just more valuable to the developer than 
no error.
Jun 19 2023
parent Dany12L <dany12719l gmail.com> writes:
On Monday, 19 June 2023 at 07:23:59 UTC, FeepingCreature wrote:

 On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

 On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

 Frankly, anyone who wants to can step up and pick a version 
 of D, declare it to be LTS, and pull only bug fixes to it, 
 can do so.


 After all this talk another unnecessary change that will break 
 the code in the user has been accepted

 https://github.com/dlang/dmd/pull/15319

 Please Walter Bright check this...


 I'm not sure about that one myself, even though I did it. (See 
 my comment.) Right now, I'm mostly just hoping that nobody is 
 calling private methods in that way. As I said, I could split 
 it out into a separate deprecation but that would require 
 undoing the error unification in the fix PR. And the whole this 
 error happened like three separate times is because this check 
 is split over a bunch of separate codepaths, so I'd hate to 
 contribute to making it worse.

 That said, the language working as specified and documented is 
 not an "unnecessary change".

 I think we're running the risk of falling into a hole of "code 
 is fragile and unmaintainable, so don't change anything ever." 
 Longstanding bugs going unfixed is a major contributor to code 
 that is fragile and unmaintainable, because you cannot trust 
 what it says! Not to mention this makes D a hellhole for new 
 people to learn.

 Years ago, I noted that learning D is not primarily a matter of 
 learning the language. The language is intuitive and 
 straightforward. Instead, learning D is primarily a matter of 
 memorizing all the diverse places where the language is *not* 
 intuitive and in fact is broken and you just have to avoid 
 them. I think cutting down on that is more important than 
 preserving the very specific ways in which you are sometimes 
 permitted to call a private method if you have placed an 
 unrelated public method in the right location in your code.

 That said, honestly, look at the bug. They're calling a private 
 method! That means they, or at least somebody, intended it to 
 *not* be called! Even on its own merits, I really think this is 
 a case where an error is just more valuable to the developer 
 than no error.



I think there is a misunderstanding here, saying that a 
particular language behavior is wrong according to the 
specification is different than throwing an error in the compiler.

Is issue 21275 incorrect according to the language specification? 
Yes
Is the behavior unpredictable? No, so there is no reason to throw 
an error

Simply issue a deprecation or warning message and allow the user 
to ignore it or treat it as an error, the fact that it is against 
the specification does not prevent the compiler from generating a 
working executable with predictable behavior.

There is no reason to throw errors for these things, C/C++ 
compilers don't do that and that allow the developer time to fix 
without preventing the code from compiling.
Jun 19 2023
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 So, as pissed as I am, please, for the love of everything, stop 
 breaking D. I understand the desire to improve the language, 
 but can you understand the desire to just... write working 
 code? Please, make D at least somewhat stable.


The solution is simple - LTS release that will only get critical 
updates. Would you pay someone to manage that? I am sure D 
Language Foundation would accept donation(s) towards that goal.
Jun 08 2023
next sibling parent bachmeier <no spam.net> writes:
On Thursday, 8 June 2023 at 14:20:18 UTC, Dejan Lekic wrote:

 On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 So, as pissed as I am, please, for the love of everything, 
 stop breaking D. I understand the desire to improve the 
 language, but can you understand the desire to just... write 
 working code? Please, make D at least somewhat stable.


 The solution is simple - LTS release that will only get 
 critical updates. Would you pay someone to manage that? I am 
 sure D Language Foundation would accept donation(s) towards 
 that goal.


What's a "critical update" for a compiler? A compiler is not a 
web browser.
Jun 08 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 14:20:18 UTC, Dejan Lekic wrote:

 The solution is simple - LTS release that will only get 
 critical updates. Would you pay someone to manage that? I am 
 sure D Language Foundation would accept donation(s) towards 
 that goal.


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.
Jun 08 2023
parent Cecil Ward <cecil cecilward.com> writes:
On Thursday, 8 June 2023 at 14:40:17 UTC, GrimMaple wrote:

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

 The solution is simple - LTS release that will only get 
 critical updates. Would you pay someone to manage that? I am 
 sure D Language Foundation would accept donation(s) towards 
 that goal.


 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.


 GrimMaple - Grim, are you ever using GDC or LDC?
Jun 17 2023
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:


 There have been a lot of talk about Gripes, about the "Vision" 
 of D... But more than half a year passed, and yet the breakage 
 only gets worse, and nothing seems to be improving. At least in 
 regards of LTS. And with no proper LTS, no proper 3rd-party can 
 exist.


My opinion is that this is a coordination problem. If you label a 
release every couple of years as LTS, no matter which one it is, 
anyone needing stability can write their code for the LTS 
release, and anyone needing to compile code will have the LTS 
release installed.
Jun 08 2023
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I wish I was exaggerating, but __every__ new DMD version breaks 
 some of my code, to a smaller or bigger extent. It can be 
 either my own code, or dependency code, but I started drowning 
 in deprecation messages or outright breakage.


If they are public, perhaps they are good inclusions to buildkite:

https://github.com/dlang/ci/blob/master/buildkite.sh

Projects on buildkite get their test suite run on every dmd pull 
request, so breakage can be prevented early.
Jun 08 2023
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I wish I was exaggerating, but __every__ new DMD version breaks 
 some of my code, to a smaller or bigger extent. It can be 
 either my own code, or dependency code, but I started drowning 
 in deprecation messages or outright breakage. It's nearly 
 impossible to develop any reasonable 3rdparty in those 
 conditions. I'm tired of fixing things that weren't broken. And 
 I can't even imagine having to support multiple branches of 
 code because of those deprecations. But I probably should, as, 
 periodically, I get issues that dlangui can't compile with some 
 outdated dmd version. It's just insane!

 Recently, some of the changes resulted in direct API changes. 
 This is unacceptable, as it, basically, forces people to update 
 major versions and split the codebase between "before" and 
 "after". Also forcing them to support two version of the same 
 thing.


Thank you for sharing this and this is a valid concern indeed. 
Unfortunately D is run as a hobbyist project for langauage geeks 
with little concern for the professional environment. It is 
nothing wrong with language geeks having a project but it doesn't 
mix well with projects that require stable language+stdlib. I 
repeat over and over again, we need to start with D3 so that 
language geeks can have a platform without interfering with D2. 
D2 should be put in maintenance mode now and the language should 
be considered to be finished.
Jun 08 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

 Thank you for sharing this and this is a valid concern indeed. 
 Unfortunately D is run as a hobbyist project for langauage 
 geeks with little concern for the professional environment. It 
 is nothing wrong with language geeks having a project but it 
 doesn't mix well with projects that require stable 
 language+stdlib. I repeat over and over again, we need to start 
 with D3 so that language geeks can have a platform without 
 interfering with D2. D2 should be put in maintenance mode now 
 and the language should be considered to be finished.


Thank you for understanding my issues. I also think D2 is good 
enough to be considered finished. Personally, I would've branched 
it at around 2.100. That's before ImportC.

I too get this feeling that D is a hobbyist project, mostly 
directed towards language creators, not software engineers. Which 
is why most of people I know avoid D as if it was a plague. And 
which is why there isn't much 3rdparty on dub to begin with.
Jun 08 2023
parent mw <mingwu gmail.com> writes:
On Thursday, 8 June 2023 at 16:13:54 UTC, GrimMaple wrote:

 On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

 Thank you for sharing this and this is a valid concern indeed. 
 Unfortunately D is run as a hobbyist project for langauage 
 geeks with little concern for the professional environment. It 
 is nothing wrong with language geeks having a project but it 
 doesn't mix well with projects that require stable 
 language+stdlib. I repeat over and over again, we need to 
 start with D3 so that language geeks can have a platform 
 without interfering with D2. D2 should be put in maintenance 
 mode now and the language should be considered to be finished.


 Thank you for understanding my issues. I also think D2 is good 
 enough to be considered finished. Personally, I would've 
 branched it at around 2.100. That's before ImportC.


Fully agree! and I also suggested *over and over again* to 
separate D2 and D3 for a long time.

And as another evidence: just look at how fast this threads grow: 
30 replies in ~3 hours!



 I too get this feeling that D is a hobbyist project, mostly 
 directed towards language creators, not software engineers. 
 Which is why most of people I know avoid D as if it was a 
 plague. And which is why there isn't much 3rdparty on dub to 
 begin with.


Me too, it's much more like a hobbyist project.

 Walter, do you hear?
Jun 08 2023
prev sibling next sibling parent Ernesto Castellotti <erny.castell gmail.com> writes:
On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

I repeat over and over again, we need to start
 with D3


I agree, but I doubt the dlang foundation would agree either


 so that language geeks can have a platform without interfering 
 with D2. D2 should be put in maintenance mode now and the 
 language should be considered to be finished.


Cool, but after that who will continue to maintain D2?
Jun 08 2023
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

 Unfortunately D is run as a hobbyist project for langauage 
 geeks with little concern for the professional environment. It 
 is nothing wrong with language geeks having a project but it 
 doesn't mix well with projects that require stable 
 language+stdlib.



Is it even true? I always thought D was pretty rigid when it 
comes to language features

Sure we get bunch of attributes, but what about the core features?

``switch`` is still the same as it was in the past, other 
languages evolved it past what C has to offer, they have pattern 
matching

``union`` same story, other languages came up with tagged union, 
coupled with improved switch, you got sweet pattern matching 
capabilities and safeties

``tuple`` same story again.. other language, even the most high 



Other languages evolve at faster pace, some are even catching up 
yet they are considered `stable` languages

The `.enum` proposal for that got shutdown is the proof

The switch as expression got ignored

The tagged union one was met with: "just use std.sumtype template 
soup and get shitty errors"


 I repeat over and over again, we need to start with D3 so that 
 language geeks can have a platform without interfering with D2. 
 D2 should be put in maintenance mode now and the language 
 should be considered to be finished.


I aggree, it's time for D3, for it will be useless without a 
vision for the future
Jun 09 2023
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but I 
 think I reached my boiling point. I've been a (self employed) 
 full time D developer for almost 2 years now, developing quite 
 a large codebase of personal closed source projects, as well as 
 adopting some 3rdparty code like dlangui. And my life has 
 become particularly miserable in the last half a year or so.

 I wish I was exaggerating, but __every__ new DMD version breaks 
 some of my code, to a smaller or bigger extent. It can be 
 either my own code, or dependency code, but I started drowning 
 in deprecation messages or outright breakage. It's nearly 
 impossible to develop any reasonable 3rdparty in those 
 conditions. I'm tired of fixing things that weren't broken. And 
 I can't even imagine having to support multiple branches of 
 code because of those deprecations. But I probably should, as, 
 periodically, I get issues that dlangui can't compile with some 
 outdated dmd version. It's just insane!

 Recently, some of the changes resulted in direct API changes. 
 This is unacceptable, as it, basically, forces people to update 
 major versions and split the codebase between "before" and 
 "after". Also forcing them to support two version of the same 
 thing.

 There have been a lot of talk about Gripes, about the "Vision" 
 of D... But more than half a year passed, and yet the breakage 
 only gets worse, and nothing seems to be improving. At least in 
 regards of LTS. And with no proper LTS, no proper 3rd-party can 
 exist.

 So, as pissed as I am, please, for the love of everything, stop 
 breaking D. I understand the desire to improve the language, 
 but can you understand the desire to just... write working 
 code? Please, make D at least somewhat stable.



For facing reality, there is a bunch of code that were made in 
dlangui with a lot older version of the language. And right now, 
I don't see as much breakage as it happens with dlangui. There is 
a bunch of stuff that is being workarounded every version.

For Hipreme Engine, I do get some errors on users when they use a 
different version, what I've done is simply limiting their 
version (my build system also includes an auto download system 
for the expected D version). I'm always trying to stick to the 
most recent version because i know that if I stick too much time 
with a version, when needing to jump 10 versions, everything will 
be broken (specially since I'm maintaining my own runtime now).

The thing is that D doesn't have structure enough to get a LTS.
We can only try to always get newest ones because we don't want 
to deal with old and nasty bugs.

What I see right now is that D is in a constantly changing phase 
where they're trying to fix those billion bugs we had on bugzilla 
so it is quite normal to expect there will be a lot of breakage 
in this trail.

So, what I would recommend right now is literally adding more 
examples to buildkite and adding migration paths. Which would be 
a lot easier than maintaining 2 versions of the language (which I 
find rather unproductive most of the time)
Jun 08 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/06/2023 7:43 AM, Hipreme wrote:

 The thing is that D doesn't have structure enough to get a LTS.


Not true.

Iain maintained the LTS version for gdc for a very long time.

We can do it, but as far as I'm concerned its up to him if we proceed 
and how.
Jun 08 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 8 June 2023 at 21:11:24 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 Iain maintained the LTS version for gdc for a very long time.


And I maintained compatibility with that version in my libs until 
quite recently (of course some of them still do, but my test 
system uses gdc 12 instead of 9 now so the gdc9 support is prolly 
gonna start slipping). It actually wasn't even that hard.
Jun 08 2023
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 8 June 2023 at 21:11:24 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 09/06/2023 7:43 AM, Hipreme wrote:

 The thing is that D doesn't have structure enough to get a LTS.


 Not true.

 Iain maintained the LTS version for gdc for a very long time.

 We can do it, but as far as I'm concerned its up to him if we 
 proceed and how.


GCC is released yearly with a D front-end frozen at whatever the 
current version is at the time of branching, and that stays 
maintained for ~3 years.

- GDC 11.x - D v2.076.x (C++ port)
Current release 11.4, last point release 11.5 expected 2024-05.

- GDC 12.x - D v2.100.x
Current release 12.3, next point releases expected 2024-05 and 
2025-05.

- GDC 13.x - D v2.103.x
Current release 13.1, next point releases expected 2023-08, 
2024-05, 2025-05, 2026-05.


The devs working on LDC could sync up and maintain these specific 
versions as well.  Then we'd just be working together on 
backporting regression fixes long after DMD has moved on to the 
next bi-monthly major release rather than just leave it to one 
person. ;-)

It's only a matter of creating a release branch instead of tags 
in the dlang/dmd repository so that there's still a common 
upstream maintained by all interested downstream parties - i.e: 
this is where all updates and fixes for the C++ port got landed 
to.

https://github.com/dlang/dmd/tree/dmd-cxx

If no one else is doing it, there's really no incentive for me to 
re-upstream any regression fixes backported into GDC from a newer 
D language version.
Jun 09 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
My general feeling is the LTS should be based upon what is required to 
bootstrap the compiler.

But yeah, this kinda needs rights to happen with branches & 
coordination. Not something that can be made to happen on the N.G. needs 
an industry meeting with someone wanting to do it I think.
Jun 09 2023
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Friday, 9 June 2023 at 21:13:06 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 My general feeling is the LTS should be based upon what is 
 required to bootstrap the compiler.


We're already doing that then? It is already a requirement that 
gdc-9 has to be able to compile gdc-mainline (ergo, dmd itself 
must always be buildable by 2.076).
Jun 10 2023
prev sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Thursday, 8 June 2023 at 19:43:56 UTC, Hipreme wrote:

 For Hipreme Engine, I do get some errors on users when they use 
 a different version, what I've done is simply limiting their 
 version (my build system also includes an auto download system 
 for the expected D version). I'm always trying to stick to the 
 most recent version because i know that if I stick too much 
 time with a version, when needing to jump 10 versions, 
 everything will be broken (specially since I'm maintaining my 
 own runtime now).


For Dplug I tell users what compiler they should use, even then 
it's useful when people try the latest and it brings up issues. 
So we ought to do that with the D compiler ourselves else noone 
will see the issues.

Even then my lib have very little breaking changes and people 
willingly use the former versions, to my dismay. I think people 
have a bit unreaistic expectations about their favourite rate of 
change.

I don't believe a D LTS would solve things (it's like a small 
schism in the language regularly), the current situation seems 
honestly ideal to me with relatively gradual upgrade paths.
Haven't had the same issues, I had very small issues with DFLAGS 
being required to make an actually standalone shared library with 
the newer DUB+LDC. Or dub.json comments being impossible at the 
moment, but nothing really striking.
Jun 09 2023
next sibling parent Guillaume Piolat <first.last spam.org> writes:
On Friday, 9 June 2023 at 11:42:50 UTC, Guillaume Piolat wrote:

 blah


Oh crap, I do get the __traits(getAttributes) deprecation. Karma.
Jun 09 2023
prev sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/06/2023 11:42 PM, Guillaume Piolat wrote:

 I don't believe a D LTS would solve things


It does have some strong benefit, wrt. bootstrapping of the compiler.

So it solves more long term things, rather than short or medium term 
issues I think.
Jun 09 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Thanks for spending the time to post this. We're going to take it to heart.
Jun 09 2023
parent reply mate <aiueo aiueo.aiueo> writes:
On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:

 Thanks for spending the time to post this. We're going to take 
 it to heart.


Don Clugston also strongly advocated for an LTS:
https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja forum.dlang.org
Jun 11 2023
next sibling parent reply Johan <j j.nl> writes:
On Sunday, 11 June 2023 at 23:20:31 UTC, mate wrote:

 On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:

 Thanks for spending the time to post this. We're going to take 
 it to heart.


 Don Clugston also strongly advocated for an LTS:
 https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja forum.dlang.org


The situation at Weka is very similar.

Trying to help the discussion a little bit.
I think there is some miscommunication because different people 
in this thread have different ideas of what "LTS" means/should 
be. Please define what you mean with "LTS"

What I think would help me (Weka) is having a stable *language*, 
not necessarily a stable compiler. Adding new features to the 
compiler can be very useful, but if every new compiler introduces 
*language changes*, then that becomes an issue.

With language changes I consider:
- introducing a new deprecation/warning/error
- removing keywords
- changing meaning / behavior of something (incl standard library)
- adding deprecation/warning/error for something that invokes 
defined but undesired behavior.
- change of data layout. (although this is not defined by the 
language, users depend on this implementation detail because D is 
systems programming after all)
- ...

Not:
- adding deprecation/warning/error for something that clearly 
invokes undefined behavior (as noted by the spec)
- adding a new feature (for example `-i` flag)
- adding a new trait
- ...

The current problem is that _every_ compiler version introduces 
some language change. Even point-releases do that! 
(https://dlang.org/changelog/2.103.1.html#dmd.deprecate-pound-in-token-string)
So we technically have _many_ different D language versions out 
there. The language changes are often in the "Compiler changes" 
category. But those are not *compiler* changes, they are 
*language* changes.

cheers,
   Johan
Jun 12 2023
parent bachmeier <no spam.net> writes:
On Monday, 12 June 2023 at 11:01:35 UTC, Johan wrote:


 Trying to help the discussion a little bit.
 I think there is some miscommunication because different people 
 in this thread have different ideas of what "LTS" means/should 
 be. Please define what you mean with "LTS"


I sort of agree with this, but the goals are not exclusive. I 
don't see anyone disagreeing with the statement that the number 
of compilers currently in use makes it hard to share code with 
others (whether for money or otherwise). That can be fixed in 
less than a minute by labeling certain releases "LTS".

If someone wants to undertake a time-intensive effort to go 
beyond that, fine. It's not needed to improve the current 
situation though. We already have many compilers in the wild that 
aren't receiving updates. There's no reason to make this extra 
work a prerequisite to reducing the number of compilers you have 
to support in order to share your code with others.
Jun 12 2023
prev sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Sunday, 11 June 2023 at 23:20:31 UTC, mate wrote:

 On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:

 Thanks for spending the time to post this. We're going to take 
 it to heart.


 Don Clugston also strongly advocated for an LTS:
 https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja forum.dlang.org



I am referencing Mike Parkers' comment found inside the above 
link...
https://forum.dlang.org/post/zycmjfzasjmmswtbntim forum.dlang.org

This is a great example of what I would like to see moving 
forward.

Imagine being able to create a new project and specifying the 
release you would like to use. If you don't have it, it will 
install it for you.

For example, when you `dub init` it could also ask the question 
:- "Which D release would you like? **D23**" etc.

In most cases, users/developers are likely to choose the current 
"milestone" release. However, the previous milestones can also be 
available. For sake of simplicity and point, lets assume the 
current milestone release is D23. Of course, specific releases 
can still be used (ie 2.104.0)

Of course, milestone releases can have patches - but must not 
break things! Ie D23.1 or D23.2, etc.

Imagine the next milestone, D25, being available months and 
months ahead of time as a pre-release (ie D25-Prerelease0.1, etc) 
allowing the maintainers to test/prepare their libraries.


Imagine if D encouraged a rule for libraries to follow to 
specific versioning patterns. For example:- 
{release.major.minor.etc} - Imagine a library having releases 
such as 23.4.2.10 or 25.1.2.0.

This tells us that D23 is available. I have **increased 
confidence** I can download this and "works" inside my D23 
project. There is also a D25 version, the not-yet-released 
milestone. I now have confidence this library is very active into 
the next milestone release.

DUB could also be more intelligent when you `dub add` a 
dependency and, perhaps, handle validation (or test) upgrading to 
the next milestone.

"There is no release for D23. Suggestions...
D25 (25.1.2.0),
D21 (21.4.6.1)"

etc.

Obviously the regular releases can continue...
2.104.0
2.103.0
2.102.0
etc

These all get factored into the next milstone. Imagine a page for 
the next upcomming milestone to contain all of the new/updated 
features -- all on one page.


Yes, I am likely getting carried away with this. I understand 
that some of my points require some (big) changes in various 
areas including DUB - but I am just trying to demonstrate, and 
hopefully well, the many advantages to a LTS system/structure.


Until then, we have regular monthly (or every other month) 
releases. Could the next release break my application? What about 
LibraryX or LibraryY I am using? etc.

Thanks.
Jun 12 2023
parent Ki Rill <rill.ki yahoo.com> writes:
On Monday, 12 June 2023 at 12:12:18 UTC, Martyn wrote:

 [...]

 I am referencing Mike Parkers' comment found inside the above 
 link...
 https://forum.dlang.org/post/zycmjfzasjmmswtbntim forum.dlang.org

 [...]


That is exactly what I would like to see as well! This versioning 
scheme is much better than what we have right now stabilizing the 
language changes...
Jun 12 2023
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but I 
 think I reached my boiling point. I've been a (self employed) 
 full time D developer for almost 2 years now, developing quite 
 a large codebase of personal closed source projects, as well as 
 adopting some 3rdparty code like dlangui. And my life has 
 become particularly miserable in the last half a year or so.

 [...]


Case in point:

https://issues.dlang.org/show_bug.cgi?id=23989
Jun 13 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 13 June 2023 at 14:17:33 UTC, deadalnix wrote:

 On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but 
 I think I reached my boiling point. I've been a (self 
 employed) full time D developer for almost 2 years now, 
 developing quite a large codebase of personal closed source 
 projects, as well as adopting some 3rdparty code like dlangui. 
 And my life has become particularly miserable in the last half 
 a year or so.

 [...]


 Case in point:

 https://issues.dlang.org/show_bug.cgi?id=23989


Interesting...




Anyway, this is a general question for all, and I understand I am 
(likely) showing my n00bness as a D developer.

(Afterall, one of the reasons I am skeptical using Dlang for 
production is precisely this reason... no LTS and, more 
specifically, mangling of libraries tested under different dmd 
builds)

For example.. lets say:-

I have created a D application using DUB. So far, so good. It 
builds with the latest version of dmd I installed earlier today 
(2.104.0)

Ok, now I need to use some libraries. DUB is great for this! 
However, when I search for packages, how do I know which version 
they support?

```
    2.104.0?
    2.103.0?
    2.102.0? (???)
```

Are we expecting maintainers of these libraries to keep them up 
to date monthly? Lets be honest.. if I need to include 3 DUB 
projects into my application then what are the chances they have 
been tested on 2.104.0? It is highly unlikely. The next question 
is - what version should I be using? Atleast 4 versions old?

One DUB package might have been updated 4 months ago. While I can 
predict the version they last used, it does not mean thats that 
the version tested by the maintainer. Should I have to predict 
this? Should I have to look at their code? Each DUB package have 
their own versioning which does not help, either.

Now, imagine the difficulties of an application with 3 or 4 DUB 
packages. Each library being released/updated at different times 
and lord knows what version they were last tested on. Will they 
all work with 2.104.0?

Because of potential breaking changes for each new release... 
could I end up with ProjectA being OK but not another, while 
experimenting with different dmd versions?

There is a reason why LTS releases exist. Look at other 
languages. Java, .NET, C++. Look at other projects like Linux or 
Blender. Could you imagine Blender users going by monthly builds 
only. Blender would fall apart and fast!

Again, if we had LTS builds, our libraries can target those 
specifically. It also makes it easier to maintainers to plan 
ahead for the next LTS. As my previous post suggested, the 
version of the libraries can start with the LTS version. It makes 
it so easy to know if your version is supported, etc.

Just my 2 cents and I apologise if I am really missing the point. 
I am sure atleast some of this lands with a number of people.
Jun 13 2023
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:

 On Tuesday, 13 June 2023 at 14:17:33 UTC, deadalnix wrote:

 On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but 
 I think I reached my boiling point. I've been a (self 
 employed) full time D developer for almost 2 years now, 
 developing quite a large codebase of personal closed source 
 projects, as well as adopting some 3rdparty code like 
 dlangui. And my life has become particularly miserable in the 
 last half a year or so.

 [...]




 Anyway, this is a general question for all, and I understand I 
 am (likely) showing my n00bness as a D developer.

 (Afterall, one of the reasons I am skeptical using Dlang for 
 production is precisely this reason... no LTS and, more 
 specifically, mangling of libraries tested under different dmd 
 builds)
 [...]
 Just my 2 cents and I apologise if I am really missing the 
 point. I am sure atleast some of this lands with a number of 
 people.


Mangling is not really the problem I think. If the ABI changes 
you can still rebuild everything, including the cached 
dependencies that would break; Not great but not a big problem. I 
think the discussion is more about how the language features are 
different from a version to another.
Jun 13 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:

 Ok, now I need to use some libraries. DUB is great for this! 
 However, when I search for packages, how do I know which 
 version they support?


Actually, dub already allows specifying toolchain requirments. 
https://dub.pm/package-format-json.html#toolchain-requirements . 
But it hardly helps with solving the issue of breakage, as some 
packages may require different versions of frontend and there is 
no way to solve it. Actually, someimtes, even dub packages 
themself can break because they depend on different versions of 
the same package, but at least 3rd party is usually strong enough 
in guaranteeing compatibility within certain major version.


 Are we expecting maintainers of these libraries to keep them up 
 to date monthly? Lets be honest.. if I need to include 3 DUB 
 projects into my application then what are the chances they 
 have been tested on 2.104.0? It is highly unlikely. The next 
 question is - what version should I be using? Atleast 4 
 versions old?


I don't know what the "expectancy" is, but talking with a lot of 
D developers led me to one conclusion: everyone expects you to 
have your own standard library. And then everyone expects you to 
use as little of the language as possible. And then everyone 
expects you to write your own code anyway, because there's an 
informal agreement that "dependencies bad".

This is a chicken and egg problem, really. Is there no packages 
because nobody writes them because "dependencies bad", or are 
"dependencies bad" because every existing one just breaks?


 Now, imagine the difficulties of an application with 3 or 4 DUB 
 packages. Each library being released/updated at different 
 times and lord knows what version they were last tested on. 
 Will they all work with 2.104.0?


I don't have to _imagine_ this -- dlangui has 9 dependencies. I 
went through great lengths to extract them from dlangui project 
itself (they were initially copy-pasted into a 3rdparty folder), 
and I'm beginning to regret this. If any of the dependencies 
break, or stop updating, I'm stuck with an old compiler version 
essentially. And it's not like replacing dependencies is easy 
when they are so scarce.


 Because of potential breaking changes for each new release... 
 could I end up with ProjectA being OK but not another, while 
 experimenting with different dmd versions?


`icontheme` dependency of dlangui is exactly what you describe. 
The maintainer refused to adapt to changed `alias this` rules, 
and I will have to figure something out eventually. Possibly, 
it's another project that I will have to maintain by myself 
because of silly breakage.


 There is a reason why LTS releases exist. Look at other 
 languages. Java, .NET, C++. Look at other projects like Linux 
 or Blender. Could you imagine Blender users going by monthly 
 builds only. Blender would fall apart and fast!


I agree that _some form_ of LTS is needed, but I don't think it's 
going to happen with D. After all, it's not that the lack of LTS 
is causing issues. We could be upgrading compilers monthly 
without issue __if__ those releases provided some strong 
guarantee of _at least_ not changing something that results in 
API changes. After all, changing, eg, `std.xml` to `undead.xml` 
isn't that devastating, and doesn't affect third-party that much. 
I even stressed that D has __become__ unbearable, as in it didn't 
introduce much breakage a few years back. Though, a stable 
release would still be greatly appreciated.


 Again, if we had LTS builds, our libraries can target those 
 specifically. It also makes it easier to maintainers to plan 
 ahead for the next LTS. As my previous post suggested, the 
 version of the libraries can start with the LTS version. It 
 makes it so easy to know if your version is supported, etc.


Yes, that is the whole point of this thread. To ask for some sort 
of stability in the D ecosystem. Because, practically, there 
isn't just "the latest version", there are 10 to 20 versions of D 
in the wild at the same time, and it's impossible to deal with.
Jun 13 2023
next sibling parent Hipreme <msnmancini hotmail.com> writes:
On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

 On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:

 Ok, now I need to use some libraries. DUB is great for this! 
 However, when I search for packages, how do I know which 
 version they support?





 This is a chicken and egg problem, really. Is there no packages 
 because nobody writes them because "dependencies bad", or are 
 "dependencies bad" because every existing one just breaks?


 Now, imagine the difficulties of an application with 3 or 4 
 DUB packages. Each library being released/updated at different 
 times and lord knows what version they were last tested on. 
 Will they all work with 2.104.0?




Although I have done my own standard library myself. I have 
plenty of other reasons to do so. One of them was for the number 
of platforms I needed to support (including my own Druntime). I 
can't see any other reason why would anyone other would need 
their own.
Jun 13 2023
prev sibling next sibling parent Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

 ...


Thank you for taking the time to respond.

Yes, your answers are confirming a number of things.. and that my 
'imagine' case(es) are, in fact, a reality - especially for 
bigger-than-average maintainers... like dlangui.

The "dependencies bad" mindset has a place for certain projects 
but should this be the case for many D projects? Sure D is great 
for low-level solutions and certainly allows this approach. It is 
a great replacement for C, etc. However D is also a high-level 

etc - especially with their respected package repositories.

With dependencies, the footprint on D executable, etc, should 
still be tiny compared to others. In **most cases**, the 
"dependency bad" needs to die in D.


*"I went through great lengths to extract them from dlangui 
project itself (they were initially copy-pasted into a 3rdparty 
folder), and I'm beginning to regret this. If any of the 
dependencies break, or stop updating, I'm stuck with an old 
compiler version essentially. And it's not like replacing 
dependencies is easy when they are so scarce."*

This pretty much hit the nail on the head for me. I do not want 
to write commercial projects only to keep having to handle 
dependency/compiler problems. Reality is - **** happens, and time 
is money. Do I really have the time to deal with this (potential) 
problem happening out of nowhere?


*"I agree that some form of LTS is needed, but I don't think it's 
going to happen with D"*

This is too bad. I hope you are wrong about this. I have been 
on-and-off with D for a few years, now. I felt D was going to be 
the "one true language" for me, whether low or high level. Some 
projects are coming my way believing the time have arrived to 
finally move to D.. to write some server-side applications... I 
just feel like I will hit a brick wall with the things mentioned 
above. Honestly it's making me bite the bullet and go a step 
closer to Ru$t (though they were having their own problems with 
trademark backlashes.. lol)


*"Yes, that is the whole point of this thread. To ask for some 
sort of stability in the D ecosystem"*

I just wanted it laid out in plain text. It seems to me the 
majority are on the same wavelength of what LTS means. I just 
wanted to clarify this.

Happy hacking.
Jun 13 2023
prev sibling next sibling parent reply Chris Katko <ckatko gmail.com> writes:
On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

 `icontheme` dependency of dlangui is exactly what you describe. 
 The maintainer refused to adapt to changed `alias this` rules, 
 and I will have to figure something out eventually. Possibly, 
 it's another project that I will have to maintain by myself 
 because of silly breakage.


I just did a grep -nr in my git directory, I've got 26 uses of it 
just in the few projects I have installed on this netbook. That's 
insane to delete a feature because "it's not clearly defined".

If it's not clearly defined... then you _define_ it, not _delete_ 
it. Especially after years of the feature being around.

Imagine if we dropped strings from D because there's some use 
case that's undefined.

If the blog/patchnotes stated workaround [1] is basically... 
implementing alias this with a template mixin... then make it use 
that mixin internally and keep "alias this". I mean, if that 
template mixin is a viable alternative, then it's clearly a 
solvable problem. If it's NOT a viable alternative, then why are 
we deleting a feature with no workaround? And likewise, if alias 
this is so dangerous, how is it safe/okay to recommend using the 
mixin version?

And as for "gotchas" with alias this use, 90% of the D language 
is one big gotcha. Put code in a deconstructor? Better know 
exactly what kind code causes allocations because writeln(x, " = 
", y) will be fine, but god forbid you accidentally write 
writeln(x ~ " = ", y) and segfault with no stacktrace as you're 
trying to learn a new language.

imported std.regex? You just doubled your compile time. There's a 
gotcha.

Tell any other object about yourself in the constructor? 
segfault. Because your object isn't constructed till _after_ the 
constructor runs. There's a gotcha.

Not adding a feature I can use like [private] for classses (if I 
understand correctly, they don't do anything in D), I can stand. 
Not everyone agrees on what features are valuable. But actually 
__removing__ features I'm using to make my code cleaner with no 
compiler switch to keep the feature at my own peril? That's 
incredibly frustrating.

Language users are NOT going to take more than one or two 
instances of deleting features before they leave. Why risk 
writing code in a language when literally any other feature you 
use may be on the chopping block next?

[1] 
https://dlang.org/changelog/2.103.0.html#dmd.deprecate-alias-this-for-classes
Jun 14 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 15/06/2023 2:44 PM, Chris Katko wrote:

 imported std.regex? You just doubled your compile time. There's a gotcha.


That is more or less solved.

https://github.com/dlang/phobos/pull/8699
Jun 14 2023
parent Chris Katko <ckatko gmail.com> writes:
On Thursday, 15 June 2023 at 04:18:34 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 15/06/2023 2:44 PM, Chris Katko wrote:

 imported std.regex? You just doubled your compile time. 
 There's a gotcha.


 That is more or less solved.

 https://github.com/dlang/phobos/pull/8699


That's great news!
Jun 15 2023
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 15 June 2023 at 02:44:59 UTC, Chris Katko wrote:

 Tell any other object about yourself in the constructor? 
 segfault. Because your object isn't constructed till _after_ 
 the constructor runs. There's a gotcha.


What case triggers this? I've heard of most the other things but 
this one I can guess a couple things on but I'm not sure.


 Not adding a feature I can use like [private] for classses (if 
 I understand correctly, they don't do anything in D)


The `private` keyword always applies on the module level, so a 
private class member can be seen inside its module but not 
outside it.
Jun 15 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2023 7:44 PM, Chris Katko wrote:

 Tell any other object about yourself in the constructor? segfault. Because
your 
 object isn't constructed till _after_ the constructor runs. There's a gotcha.


All objects are default constructed before the constructor is called.

I'll need an example?
Jun 15 2023
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 15, 2023 8:05:21 PM MDT Walter Bright via Digitalmars-d 
wrote:

 On 6/14/2023 7:44 PM, Chris Katko wrote:

 Tell any other object about yourself in the constructor? segfault. Because
 your object isn't constructed till _after_ the constructor runs. There's
 a gotcha.


 All objects are default constructed before the constructor is called.


Or to be more precise, they're default-initialized before any constructors
are called.

- Jonathan M Davis
Jun 15 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2023 7:45 PM, Jonathan M Davis wrote:

 Or to be more precise, they're default-initialized before any constructors
 are called.


Right. (Good to hear from you!)
Jun 15 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 15, 2023 9:42:11 PM MDT Walter Bright via Digitalmars-d 
wrote:

 On 6/15/2023 7:45 PM, Jonathan M Davis wrote:

 Or to be more precise, they're default-initialized before any constructors
 are called.


 Right. (Good to hear from you!)


Well, I've been out of things for a while due to issues with migraines, but
they've improved enough that I'm getting back to work now. I don't know how
much I'll be dealing with the newsgroup or official D stuff going forward,
but I intend to be at least somewhat involved again.

- Jonathan M Davis
Jun 15 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 16/06/2023 6:23 PM, Jonathan M Davis wrote:

 Well, I've been out of things for a while due to issues with migraines, 
 but they've improved enough that I'm getting back to work now. I don't 
 know how much I'll be dealing with the newsgroup or official D stuff 
 going forward, but I intend to be at least somewhat involved again.
 
   * Jonathan M Davis


Good to hear, I was also wondering what was up.

Also, come join Discord!
Jun 15 2023
prev sibling next sibling parent reply claptrap <clap trap.com> writes:
On Friday, 16 June 2023 at 06:23:00 UTC, Jonathan M Davis wrote:

 On Thursday, June 15, 2023 9:42:11 PM MDT Walter Bright via 
 Digitalmars-d wrote:

 On 6/15/2023 7:45 PM, Jonathan M Davis wrote:

 Or to be more precise, they're default-initialized before 
 any constructors are called.


 Right. (Good to hear from you!)


 Well, I've been out of things for a while due to issues with 
 migraines, but they've improved enough that I'm getting back to 
 work now. I don't know how much I'll be dealing with the 
 newsgroup or official D stuff going forward, but I intend to be 
 at least somewhat involved again.

 - Jonathan M Davis


My wife has had crippling migraines for years, like 2 a week, 
crawling around on the floor crying, heavy duty painkillers to 
knock her out bad. She started on Ajovy about a year ago and its 
literally changed her life, she gets maybe 2 a month now. So 
instead of spending 3 or 4 days a week in bed or recovering from 
the after affects, she has a couple of days a month where she has 
to be in bed with the room blacked out.

The neurologist also made her stop taking any pain meds unless 
it's absolutely desperate, that helped with the day to day 
headaches she was also getting. So she doesnt take anything 
unless its a full on migraine.

But the Ajovy stuff is amazing, literally changed her life. It's 
an injection once a month with an epipen like thing.
Jun 16 2023
parent Chris Katko <ckatko gmail.com> writes:
On Friday, 16 June 2023 at 08:55:11 UTC, claptrap wrote:

 On Friday, 16 June 2023 at 06:23:00 UTC, Jonathan M Davis wrote:

 On Thursday, June 15, 2023 9:42:11 PM MDT Walter Bright via 
 Digitalmars-d wrote:

 On 6/15/2023 7:45 PM, Jonathan M Davis wrote:

 Or to be more precise, they're default-initialized before 
 any constructors are called.


 Right. (Good to hear from you!)


 Well, I've been out of things for a while due to issues with 
 migraines, but they've improved enough that I'm getting back 
 to work now. I don't know how much I'll be dealing with the 
 newsgroup or official D stuff going forward, but I intend to 
 be at least somewhat involved again.

 - Jonathan M Davis


 My wife has had crippling migraines for years, like 2 a week, 
 crawling around on the floor crying, heavy duty painkillers to 
 knock her out bad. She started on Ajovy about a year ago and 
 its literally changed her life, she gets maybe 2 a month now. 
 So instead of spending 3 or 4 days a week in bed or recovering 
 from the after affects, she has a couple of days a month where 
 she has to be in bed with the room blacked out.

 The neurologist also made her stop taking any pain meds unless 
 it's absolutely desperate, that helped with the day to day 
 headaches she was also getting. So she doesnt take anything 
 unless its a full on migraine.

 But the Ajovy stuff is amazing, literally changed her life. 
 It's an injection once a month with an epipen like thing.


I feel for you. Start keeping a log of food whenever you have a 
migraine. Just write down what you ate that day. Many people will 
find that food triggers migraines. My doctors gave me a list of 
foods to avoid (or watch). Literally on my wall to my right. It 
says: Onions (garlic), alcohol, chocolate, aged cheeses, 
caffeine, nuts, and lastly, cinnamon is one of the most common 
triggers in the world.

I cut out cinnamon, garlic/onions and my migraines almost 
disappeared.
Jun 16 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2023 11:23 PM, Jonathan M Davis wrote:

 Well, I've been out of things for a while due to issues with migraines, but
 they've improved enough that I'm getting back to work now. I don't know how
 much I'll be dealing with the newsgroup or official D stuff going forward,
 but I intend to be at least somewhat involved again.


That's great news! I'm glad to have you back!
Jun 16 2023
prev sibling parent reply Chris Katko <ckatko gmail.com> writes:
On Friday, 16 June 2023 at 02:05:21 UTC, Walter Bright wrote:

 On 6/14/2023 7:44 PM, Chris Katko wrote:

 Tell any other object about yourself in the constructor? 
 segfault. Because your object isn't constructed till _after_ 
 the constructor runs. There's a gotcha.


 All objects are default constructed before the constructor is 
 called.

 I'll need an example?


I misremembered a bit when summarizing, from this thread last 
year:

https://forum.dlang.org/post/uvjvtzidbqartwkbbaww forum.dlang.org

Code works fine when you directly send a reference during 
construction. But if you access it from an absolute path like 
module.classinstance.variable it crashes.

That is not something that is obvious, at least to me. If, during 
construction, I can send a reference to [this] to a called 
function just fine, but not refer to the same object through its 
absolute path until after construction, that's counter-intuitive 
/ a gotcha, for me.

Note: on re-reading my old post I see typos that were corrected 
in my later posts in the thread. To be clear, I'm not referring 
to module.CLASSTYPE.variable anywhere. It's 
module.classInstance.variable.
Jun 16 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
Thanks for the reference. I think Mike accurately diagnosed it. D doesn't 
guarantee that null pointers won't be dereferenced, and you'll need to ensure 
they are set before using them.
Jun 17 2023
prev sibling parent BlueBeach <blue.beach7052 fastmail.com> writes:
On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:


 Yes, that is the whole point of this thread. To ask for some 
 sort of stability in the D ecosystem. Because, practically, 
 there isn't just "the latest version", there are 10 to 20 
 versions of D in the wild at the same time, and it's impossible 
 to deal with.


Hi,
I hope you don't mind my opinion since it's my first post here. 
But in my defense I'm a lurker for years. For some reason I like 
this forum very much.

While I didn't read every answer in this particular thread, I 
thought the quote from OP can be very well summarised to:

"I need some sort of stability despite the numerous versions of 
D."

Thinking about this, I'm not sure a LTS support version is the 
best solution for this problem, because the primary thing you 
need is stability not support. What you need is the possibility 
to have a stable working environment when dealing with older 
versions. That your software is building even when new versions 
of a D compiler or some libraries are released. I think the 
solution to this lies in a package manager that allows for 
different versions of D including the associated libraries.
Jun 15 2023
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 write working code? Please, make D at least somewhat stable.



Add the `deprecation` directory and save the `deprecation` 
function code there.
If the `deprecated` function is placed separately in 
the`deprecated` directory, even if it is deprecated, some people 
are unwilling to improve and can continue to keep the 
`deprecated` function available. As long as the code is there, it 
can be compiled and passed.
In this way, it is equivalent to `updating`only adding 
functionality, without `damaging` functionality.
Jun 13 2023
parent zjh <fqbqrr 163.com> writes:
On Wednesday, 14 June 2023 at 01:22:00 UTC, zjh wrote:

 In this way, it is equivalent to `updating`only adding 
 functionality, without `damaging` functionality.



With the `deprecated` directory, there is no need to maintain the 
`LTS` version because you have never `deleted` functionality!.
Jun 13 2023
prev sibling next sibling parent Joe bloow.edu <Joe bloow.edu> writes:
On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

 I usually try to stay more silent (on the form at least), but I 
 think I reached my boiling point. I've been a (self employed) 
 full time D developer for almost 2 years now, developing quite 
 a large codebase of personal closed source projects, as well as 
 adopting some 3rdparty code like dlangui. And my life has 
 become particularly miserable in the last half a year or so.

 I wish I was exaggerating, but __every__ new DMD version breaks 
 some of my code, to a smaller or bigger extent. It can be 
 either my own code, or dependency code, but I started drowning 
 in deprecation messages or outright breakage. It's nearly 
 impossible to develop any reasonable 3rdparty in those 
 conditions. I'm tired of fixing things that weren't broken. And 
 I can't even imagine having to support multiple branches of 
 code because of those deprecations. But I probably should, as, 
 periodically, I get issues that dlangui can't compile with some 
 outdated dmd version. It's just insane!

 Recently, some of the changes resulted in direct API changes. 
 This is unacceptable, as it, basically, forces people to update 
 major versions and split the codebase between "before" and 
 "after". Also forcing them to support two version of the same 
 thing.

 There have been a lot of talk about Gripes, about the "Vision" 
 of D... But more than half a year passed, and yet the breakage 
 only gets worse, and nothing seems to be improving. At least in 
 regards of LTS. And with no proper LTS, no proper 3rd-party can 
 exist.

 So, as pissed as I am, please, for the love of everything, stop 
 breaking D. I understand the desire to improve the language, 
 but can you understand the desire to just... write working 
 code? Please, make D at least somewhat stable.



To be honest, it is best to leave D. There really is no vision, 
no real organization, and no throughput. D is just coasting on 
fumes. I stopped programming in D and I'm much happier. I only 
use it to maintain a few small utilities I regularly use when I 
want to add a feature or fix a bug but I've moved on. D will not 
last. It's a pipe dream to think D will ever get anywhere. 
Python, a rather idiotic language, has become dominant because of 
AI and it being pushed by major companies. The world doesn't work 
logically and it depends more on $$$ and desire than logic or 
quality.

As more and more people get in to programming(the younger 
generations) languages like python will dominate and languages 
like D will die a cold harsh death. These are just facts. I don't 
make them up, I just report them. D's community failed to realize 
how myopic and insignificant they were. Those still remaining are 
just hanging on to hang on.

D was about 10-20 years behind the curve. Now It's only gotten 
worse since only a massive amount of investment will be able to 
turn D in to anything competitive and sane. It doesn't matter how 
"great" the language is if no one uses it. It will die out. New 
people will come in to "take over" and ruin it as they try to 
turn it in to something else. This discussion has been had for 
nearly a decade and the core team simply does not care and never 
will. For them, it's their golf game and they don't care about 
playing professional, just every other weekend for an hour or so.

With the speed of modern computers and the focus on GPU's and AI 
D really serves no use. It's like learning Latin. Sure it is a 
nice thing to know but it's about useless in the real world. The 
people that "speak Latin" simply do not care and/or have the 
resources to make it main stream. Fewer and fewer people will 
learn it. Over time it will die like any other language. There 
will always be a few people that will be interested in wasting 
their time learning it so they can pretend they have some secret 
talent over others or because they want to understand the 
original text accurately but this is not enough to sustain it 
past a few decades or hundred years. If I'm not mistaken, Latin 
has about 1000 fluent speakers. If you realize that it was once 
the dominant language of the modern world and was the lingua 
franca of Christianity then, well, imagine how D is going to fare.

Save yourself now before you waste more of your life with it. I'm 
speaking from experience. You won't be able to talk sense in to 
the diehards, many have tried. They are deluded or get paid to 
use D by a company that is simply trying to maintain it's 
codebase and has no need to switch. Kids rule the world, they are 
the ones that will spend hours upon hours a day programming 
useless things and pushing things for no reason other than they 
want to. Those drive progress. Age, at some point, ruins almost 
everyone. At some point the effort to grow something is more than 
one can put in. Everything dies, and D's on it's deathbed(this 
does not mean necessarily that D will just vanish completely off 
the face of the earth on day, it means that it is not popular 
enough to sustain growth in any meaningful way and the diehards 
won't do anything change that).
Jun 21 2023
prev sibling parent reply Z3Solver <z3solver proton.me> writes:
Putting in my 2 cents. I used to work as a professional D 
developer, made a living off of it for a year or two, and then 
became quickly disillusioned with it. Hell - DMD has not worked 
for me on aarch64 macOS for the past 6 months, even after 
updating to the latest version of both macOS / DMD available due 
to some obscure linker error that I sincerely cannot be assed to 
dig into. It just doesn't work, so I've just avoided writing D 
like the plague (or just use ldc, which has always worked!).

In my eyes, D is like the perfect embodiment of "move fast, and 
break things", but sans the "you need to fix those things at some 
point after you break them", and like OP mentioned, so incredibly 
frustrating to deal with.

I tried. I genuinely did. But there are so many rough edges, as 
well as a complete reluctance to try New Ideas That Are Proven To 
Work Elsewhere. Because we have to do it the D way -- whatever 
the hell that means.

I'm personal friends with a few engineers at Facebook, and 
learned the reason why Facebook dropped D. I mean, hell, there 
was huge internal hype about it there, as well as major 
investment in the language; it was seen as the replacement to C++ 
and was paraded around as the Next Great Thing (TM). Hell - they 
even hired on Andrei & Walter, as well integrated it fully into 
Buck (Facebook's internal build tool). You know what happened? 
Facebook engineers ran into so many headaches and issues with D 
that they chose to drop it entirely, and in its place came a 
language that you might've heard of: Rust. Need proof? Look at 
what languages are implemented in Buck2 - you'll notice that 
there's a stark lack of D anywhere.

I'm genuinely shocked that D is still used in production 
anywhere. It feels like you need to take the Symmetry approach of 
writing your own standard library (and be incredibly selective 
about which features you use - e.g. the majority of Mir is 
written with  safe  pure  nogc, which made it an absolute joy to 
work with) just to even be able to use it in a remotely 
productive way. And even then, you start to run into some serious 
rough edges with dmd and work around compiler issues all the time.

This doesn't even get into my criticisms of the language itself. 
The level of compiler metaprogramming that D encourages its users 
to use has so many footguns, combined with a compiler that has so 
many incredibly bizarre design decisions (seriously, DMD has 
caused me to OOM my entire system on multiple occasions) that 
I've become incredibly incredibly skeptical that it was a good 
idea to begin with.

Now I write Rust professionally and don't have any of these 
pains. I have new pains, of course, but at least my "new pains" 
are addressed by the community / language maintainers in a 
reasonable timeframe, whereas some of the compiler bugs I've 
reported have gone unseen unless I made an absolute fuss about it 
on the Discord. I don't have to worry about my crates magically 
breaking if I update the compiler. I don't need to worry about my 
code randomly getting slower to compile if I update the compiler. 
I can use every part of the standard library and not have to 
worry about (x) or (y) - unlike tar pits like std.regex, or 
std.string. Sure, the cognitive load is higher since I now need 
to worry about ownership / borrowing, and I sometimes need to 
fight the borrow checker, but in return I get a language that is 
incredibly reliable & ergonomic to use.

I wish you all well, and I wish D could've worked out. I really 
wanted to like the language. There are so many great lessons that 
can be learned from D. But viewed holistically, I cannot 
recommend any new developers to write any code in D.
Jun 30 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Are you seeing warnings about alignment?

Its a known issue that has been fixed in LDC but DMD still needs the 
workaround.

https://forum.dlang.org/post/upczlsrzcpxgalgjyvvp forum.dlang.org
Jun 30 2023
parent reply Z3Solver <z3solver proton.me> writes:
On Friday, 30 June 2023 at 18:09:45 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 Are you seeing warnings about alignment?

 Its a known issue that has been fixed in LDC but DMD still 
 needs the workaround.

 https://forum.dlang.org/post/upczlsrzcpxgalgjyvvp forum.dlang.org


That's the one! Crazy that an issue that we've known about since 
November 4th, 2021 *still* hasn't been fixed in the "flagship" 
compiler. Oh well.
Jun 30 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 01/07/2023 6:15 AM, Z3Solver wrote:

 That's the one! Crazy that an issue that we've known about since 
 November 4th, 2021 /still/ hasn't been fixed in the "flagship" compiler. 
 Oh well.


Reference compiler, not flag ship which is a bit different.

Yeah we don't generally recommend dmd these days. Its good if you're on 
x86 and want fast builds, but is not so good at performance or 
correctness type of stuff.

Eventually dmd will drop support for OSX, once Apple drops the x86 
support. So if you want to drop support for dmd and be happy about it, 
I'd recommend it.

But for reference, there have been a lot of governance changes in the 
last 10 years. Its well worth talking about the problems that you are 
having including going to one of the industry meetings.
Jun 30 2023
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 30 June 2023 at 17:55:38 UTC, Z3Solver wrote:

 It feels like you need to take the Symmetry approach of writing 
 your own standard library (and be incredibly selective about 
 which features you use - e.g. the majority of Mir is written 
 with  safe  pure  nogc, which made it an absolute joy to work 
 with) just to even be able to use it in a remotely productive 
 way.


This is a misunderstanding. The standard library whose core 
Symmetry based on Phobos is for the internal Symmetry Integration 
Languge, SIL. D code in Symmetry still uses Phobos as-is. Sure, 
we sometimes copy-paste a function out of it to modify it 
slightly, and sometimes use third-party (or internal) libraries 
when we're unsatisfied with what Phobos offers, but `std` is 
still widely used.

Also, at least my experience is that the list of D features to 
not use at Symmetry are stylistic choices. There's no general ban 
on technological D features like the garbage collector, ` system` 
code or global variables (although of course we prefer to avoid 
the latter two when other things are equal, like any good D 
programmer).
Jul 02 2023
parent FeepingCreature <feepingcreature gmail.com> writes:
On Sunday, 2 July 2023 at 18:18:35 UTC, Dukc wrote:

 On Friday, 30 June 2023 at 17:55:38 UTC, Z3Solver wrote:

 It feels like you need to take the Symmetry approach of 
 writing your own standard library (and be incredibly selective 
 about which features you use - e.g. the majority of Mir is 
 written with  safe  pure  nogc, which made it an absolute joy 
 to work with) just to even be able to use it in a remotely 
 productive way.


 This is a misunderstanding. The standard library whose core 
 Symmetry based on Phobos is for the internal Symmetry 
 Integration Languge, SIL. D code in Symmetry still uses Phobos 
 as-is. Sure, we sometimes copy-paste a function out of it to 
 modify it slightly, and sometimes use third-party (or internal) 
 libraries when we're unsatisfied with what Phobos offers, but 
 `std` is still widely used.

 Also, at least my experience is that the list of D features to 
 not use at Symmetry are stylistic choices. There's no general 
 ban on technological D features like the garbage collector, 
 ` system` code or global variables (although of course we 
 prefer to avoid the latter two when other things are equal, 
 like any good D programmer).


Funkwerk, same here. Widespread use of the standard library 
except when we need to fork something to fix a bug or design 
issue (grrr Rebindable grrr). We try to *minimize* GC load via 
various means (ranges, structs, stream decoding), but we wouldn't 
forbid it outright - that would make the code far too painful to 
contemplate. And it is useful.
Jul 02 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2023 10:55 AM, Z3Solver wrote:

 I tried. I genuinely did. But there are so many rough edges, as well as a 
 complete reluctance to try New Ideas That Are Proven To Work Elsewhere.


I appreciate you spending the time to post here.

I have some frustrations, too - how can we focus just on bug fixes while 
implementing new features at the same time?

The other frustration I have is I never heard any feedback from Facebook, and
I would like to work on the problems you're experiencing, but it would be nice 
to have a specific list.
Jul 02 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:


 I have some frustrations, too - how can we focus just on bug 
 fixes while implementing new features at the same time?


Who asked for those features in the first place? Eg. who asked 
for ImportC? Are you even sure those new features are needed?


 I would like to work on the problems you're experiencing, but 
 it would be nice to have a specific list.


This entire thread is a list of problems, yet your only response 
is "Do it yourself". So I'm not buying this "I would like to work 
on the problems you're experiencing".
Jul 03 2023
next sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

 Who asked for those features in the first place? Eg. who asked 
 for ImportC? Are you even sure those new features are needed?


Recently translated miniz (a zlib replacement) from C to D and 
Dennis' ctod didn't make it through the unbelievable macros, and 
it was a drag to expand the macros by hand.
I will very probably use ImportC when it can find the 
preprocessor on Windows, which has been a blocker here. So many 
codebases have been translated from C to D it can be indeed 
valuable. Moreover ImportC is also a fast C compiler so it can 
eventually help build times of D projects by rewriting in C :)
Jul 03 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 3 July 2023 at 11:50:32 UTC, Guillaume Piolat wrote:


 Recently translated miniz (a zlib replacement) from C to D and 
 Dennis' ctod didn't make it through the unbelievable macros, 
 and it was a drag to expand the macros by hand.
 I will very probably use ImportC when it can find the 
 preprocessor on Windows, which has been a blocker here. So many 
 codebases have been translated from C to D it can be indeed 
 valuable. Moreover ImportC is also a fast C compiler so it can 
 eventually help build times of D projects by rewriting in C :)


So to help projects in D you should re-write them in C? Huge W 
for the language, GG. Big confidence boost!
Jul 03 2023
parent Guillaume Piolat <first.last spam.org> writes:
On Monday, 3 July 2023 at 11:56:40 UTC, GrimMaple wrote:

 So to help projects in D you should re-write them in C? Huge W 
 for the language, GG. Big confidence boost!


If I can keep part of my stack in C by just not translating them 
to D then it would be a win, since then you get the breadth of C 
libs + faster compile time. The pragma(pack) and __align work is 
needed to get there... it's not lack of confidence not to start a 
JPEG decoder from scratch, it is way faster to translate.
Jul 03 2023
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

 Who asked for those features in the first place? Eg. who asked 
 for ImportC? Are you even sure those new features are needed?


I didn't ask, but I sure am happy ImportC exists!

--Bastiaan.
Jul 03 2023
prev sibling next sibling parent reply Dmytro Katyukha <firemage.dima gmail.com> writes:
On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

 On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:


 I have some frustrations, too - how can we focus just on bug 
 fixes while implementing new features at the same time?


 Who asked for those features in the first place? Eg. who asked 
 for ImportC? Are you even sure those new features are needed?


 I would like to work on the problems you're experiencing, but 
 it would be nice to have a specific list.


 This entire thread is a list of problems, yet your only 
 response is "Do it yourself". So I'm not buying this "I would 
 like to work on the problems you're experiencing".


Why so many hate for ImportC? I am waiting when it will be ready 
and supported by LDC, thus i will be able to use some C libraries 
without pain.

For example, it took too much time to understand how to generate 
(and then manually process) D definitions for such simple library 
as [libzip](https://github.com/katyukha/dlibzip). I am waiting 
when ImportC will be supported by LDC, and then i will be able to 
use it for example for this wrapper around libzip 
(https://github.com/katyukha/Zipper).

Also, i want to use D to create some internal service to parse 
git repositories (few hundreds repos), and for this reason i want 
to use libgit2 C library. But without ImportC ready, i do not 
want to even try to manually generate D bindings for for that. I 
have seen and tried to use 
[libgit2](https://github.com/s-ludwig/libgit2) D bindings, even 
added there 1 PR. But currently, i see that without ImportC, it 
will be impossible to maintain such kind of bindings with 
reasonable (for me) efforts. Especially, taking into account 
different versions of libgit2.

Thus i think, ImportC is important feature that could 
significantly boost D ecosystem.

Also, i want to create libpq wrapper for postgresql database 
similar for python's psycopg (no classes, only ref-counted 
structs, no integrated orm, just simple and reliable library). 
But the only thing that stops me to start work on it (except 
time) is that ImportC is not ready yet (not supported by LDC and 
has some bugs). I will not even try to start work on such 
projects without ImportC.

So, please, stop hate ImportC.

---

In case of LTS, i support that D needs some kind of LTS release, 
or at least keep backward compatibility as much as reasonably 
possible. But, i think, that before starting of LTS, at least 
following features have to be completed (no need to use -preview 
to enable them):
- DIP1000 support
- ImportC
- Preview In (good to have, but not necessary)
- Something other that is partially ready and may be necessary 
for D ecosystem.

I think that, things that have to be backported to (or may be 
forwardported from) LTS release must include:
- regressions
- critical bugfixes
- bugfixes that require reasonable amount of work to backport.
- possibly some deprecation warnings (i think it is good to know 
that some feature will be removed as early as possible).
- possibly some safe (fully backward-compatible features that 
require reasonable amount of work to backport).

In case of reasonable amount of work, i mean: why not to backport 
fix/feature if it could take not more then few hours.
Jul 03 2023
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 3 July 2023 at 13:59:56 UTC, Dmytro Katyukha wrote:

 On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

 [...]


 Why so many hate for ImportC? I am waiting when it will be 
 ready and supported by LDC, thus i will be able to use some C 
 libraries without pain.

 [...]


FYI, I'm cross-compiling and cross-linking targeting Windows from 
a Mac, using ImportC to handle directly the ffmpeg API, using LDC.

I just love that.

/P
Jul 03 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/3/2023 7:08 AM, Paolo Invernizzi wrote:

 FYI, I'm cross-compiling and cross-linking targeting Windows from a Mac, using 
 ImportC to handle directly the ffmpeg API, using LDC.


Awesome!
Jul 03 2023
prev sibling parent Guillaume Piolat <first.last spam.org> writes:
On Monday, 3 July 2023 at 13:59:56 UTC, Dmytro Katyukha wrote:

 For example, it took too much time to understand how to 
 generate (and then manually process) D definitions for such 
 simple library as 
 [libzip](https://github.com/katyukha/dlibzip). I am waiting 
 when ImportC will be supported by LDC, and then i will be able 
 to use it for example for this wrapper around libzip 
 (https://github.com/katyukha/Zipper).


Unrelated, but I plan to make a `miniz` package with this 
translation, since it could maybe simplify using zlib. (some of 
the APIs aren't supported though)
https://github.com/AuburnSounds/gamut/blob/main/source/gamut/codecs/miniz.d

Also translated lz4 (but not lz4hc).
Jul 03 2023
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

 On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:


 I have some frustrations, too - how can we focus just on bug 
 fixes while implementing new features at the same time?


 Who asked for those features in the first place? Eg. who asked 
 for ImportC? Are you even sure those new features are needed?


I'm not using it in D right now, but every compiler I've ever 
made has had some variant of ImportC. It's a great feature, and I 
am hype that it's in the language.
Jul 03 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 3 July 2023 at 15:04:13 UTC, FeepingCreature wrote:

 I'm not using it in D right now, but every compiler I've ever 
 made has had some variant of ImportC. It's a great feature, and 
 I am hype that it's in the language.


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..
Jul 03 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/3/2023 8:27 AM, Sergey wrote:

 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..


There wasn't a DIP, because ImportC isn't about the D language. I.e. it's a 
compiler feature, not a D feature.
Jul 03 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/3/2023 4:35 AM, GrimMaple wrote:

 On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:
 

 I have some frustrations, too - how can we focus just on bug fixes while 
 implementing new features at the same time?


 
 Who asked for those features in the first place? Eg. who asked for ImportC?
Are 
 you even sure those new features are needed?


There have been 4 previous attempts at automating access to C .h files, by 4 
different people. There's quite clearly a problem that needs solving.



 I would like to work on the problems you're experiencing, but it would be nice 
 to have a specific list.


 
 This entire thread is a list of problems, yet your only response is "Do it 
 yourself". So I'm not buying this "I would like to work on the problems you're 
 experiencing".


Look at my PRs starting with "Fix ..." and the PRs people are steadily
contributing.
Jul 03 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
 whereas some of the compiler bugs I've reported have gone unseen


As far as I can tell, this is the first post by Z3Solver. I cannot find any 
bugzilla issues attributed by Z3Solver. If you could provide links to the
issues 
you've reported, I would appreciate it. Thanks!
Jul 02 2023