D has become unbearable and it needs to stop

[FeepingCreature]

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.