The spec should warn against using copy constructors, not warn against using postblit constructors

[jmdavis]

Due to dlang/dmd#20970, any types with a copy constructor should not be used in a dynamic array or associative array, which realistically means that no one who isn't using -betterC should be using copy constructors.

However, the spec currently has a warning on postblit constructors, telling programmers to use copy constructors in new code instead. This might make sense if druntime supported copy constructors properly, but it doesn't. And until it does, IMHO, we really need to be warning programmers against using copy constructors and instead be telling them to use postblit constructors. Personally, I wasted a considerable amount of time because of this issue, because I did not realize that the support for copy constructors was not complete, and I'm one of the core contributors, and without the spec being correct with regards to the current state of things, plenty of other folks are going to make the same mistake.

[TurkeyMan]

I kinda feel like this is backwards; shouldn't the issue you describe be fixed instead of the spec being revised? That's a super-weird resolution to a bug. How do you arrive at the idea that revising the spec is the appropriate bug fix?

That said, I'm pretty horrified that copy constructors must have been added how many years ago, and you're saying they don't work? :/ .. This is just classic D! I mean, I did kinda know this because I've tried to use them and they did cause me problems, but I just assumed it was because I was doing something 'exotic'.

So, what do we do? It's almost impossible to do anything because everything is so fragile, nobody will ever do anything that addresses the overall brittle-ness, and then this hyper-conservative approach which leaves everything broken and never fix anything; it leads to people building around a broken ecosystem and depending on the quirks/bugs, and then people go "oh no, we can't fix anything because it'll break the code that was carefully adapted to the broken thing that we won't fix". Is this really where we want to be?

[rikkimax]

For AA's they'll be fixed once the implementation is converted to a template, since the compiler can kick in then. That is supposed to be done by @schveiguy this year hopefully.

I don't remember the status of dynamic array hooks being templated. @RazvanN7

[TurkeyMan]

Kinda feels like this is, like, maximum priority stuff? The language being in a state where you can't even successfully construct an object according to the spec is just, like, broken; in the most literal sense of the word.
It's like a "stop everything, all hands on deck until this is fixed" kinds thing... this situation shouldn't have persisted for a single day; how did this happen?

[dkorpel]

I think most D programmers are happily using plain structs / classes / base data types and don't care that much about postblits / copy constructors.

[TurkeyMan]

Mm. It's really un-fun to work without decent strings, dynamic arrays, maps, general collections, etc, though. It's been a gaping hole in the library forever.

[jmdavis]

I kinda feel like this is backwards; shouldn't the issue you describe be fixed instead of the spec being revised? That's a super-weird resolution to a bug. How do you arrive at the idea that revising the spec is the appropriate bug fix?

There is a bug report for fixing the language: dlang/dmd#20970

However, until it's fixed, the spec shouldn't be telling folks to use copy constructors instead of postblit constructors, because key parts of the language don't work properly with copy constructors. And prior to this PR, the spec was actually telling folks to use copy constructors instead of postblit constructors, which is totally the wrong thing to be telling people as long as the druntime hooks don't handle copy constructors properly. And really, move constructors need a similar warning for pretty much the same reasons. IMHO, neither of those features should have been added to the language without a -preview switch, and they should have been completed before being moved from the -preview switch into the language proper. We're in this mess now because that was not done, and the implementation was never finished.

That said, I'm pretty horrified that copy constructors must have been added how many years ago, and you're saying they don't work? :/ .. This is just classic D! I mean, I did kinda know this because I've tried to use them and they did cause me problems, but I just assumed it was because I was doing something 'exotic'.

I was also horrified to find out that they don't work properly with dynamic arrays and AAs. I wasted a bunch of time at work because of it. From the appearance of things, whoever implemented copy constructors (probably Walter) implemented the compiler side of things without considering the druntime side of things. So, copy constructors probably work fine with -betterC, but anyone using proper D should probably avoid them like the plague until the druntime hooks are fixed. I think that it's appalling that we've had a notice on the spec for years telling folks to use copy constructors rather than postblit constructors when copy constructors don't even work properly with some core language features. It probably hasn't been a bigger issue primarily because most D types don't need copy constructors or postblit constructors. Either way, IMHO, copy constructors should have been behind a -preview switch until they were fully complete and properly tested, but unfortunately, that didn't happen.

So, what do we do?

As the bug report to fix the actual issue explains, either TypeInfo needs to be updated to actually support copy constructors, and the hooks need to be updated to do the right thing when a copy constructor is present (as well as doing the right thing when both a postblit constructor and copy constructor are present), or the rest of the hooks need to be templatized appropriately, which is not a small project. The person who was working on templatizing the hooks did so primarily as part of SAoC, and he's busy with other stuff now (though as I understand it, he does plan to continue working on it if/when he can). So, someone else may need to do it, and I have no clue who that would be. It's not like we have employees that we can assign to work on stuff. It's all volunteer work, and there's a lot of stuff that needs to get done.

My gut reaction is that we should fix TypeInfo to support copy constructors and move constructors and then fix the non-templated hooks to use them properly via TypeInfo (and the templated hooks will need to be updated to deal with move constructors properly wherever that's appropriate). However, I've been told that dmd doesn't actually use TypeInfo like a proper class and does stuff like hard code offsets instead of calling the functions normally (probably for performance reasons), which makes changing it far more difficult than it really should be. We do need to templatize the remaining hooks regardless, but that's clearly going to take a while, in part because there are other changes that will need to be made to how the compiler works to be able to templatize some of the hooks. This work desperately needs to be done, but we don't actually have a plan for how to do it, in large part because of the volunteer nature of the project.

Regardless, for now, the best that I can do is highlight the fact that this issue exists and warn people about it so that they don't step on the landmine that it causes. So, we now have an issue for fixing the druntime hooks as a whole (as opposed to just having some seemingly disconnected bug reports complaining about some particular piece of functionality not working with copy constructors properly). And this PR has now fixed the spec so that anyone reading it will be informed instead of being told to use an incomplete feature instead of the pre-existing complete one.

It's almost impossible to do anything because everything is so fragile, nobody will ever do anything that addresses the overall brittle-ness, and then this hyper-conservative approach which leaves everything broken and never fix anything; it leads to people building around a broken ecosystem and depending on the quirks/bugs, and then people go "oh no, we can't fix anything because it'll break the code that was carefully adapted to the broken thing that we won't fix". Is this really where we want to be?

This particular issue has nothing to do with worrying about breaking code. It has to do with the fact that a feature was added without putting it behind a -preview switch and without it being finished - and then we told people to use it when it wasn't ready yet. Getting it done is a matter of someone with enough time and skill actually spending the time to finish the job.

If anything, the issue was caused by adding new stuff without putting it behind a -preview switch until it was completed, and it was further exacerbated by the fact that the druntime side of things was somehow forgotten. And from what I can tell, we have just done exactly the same thing with move constructors instead of learning our lesson. But at least this time around, the fact that the issue exists hasn't been forgotten. Regardless, the hooks still need to be fixed for both copy constructors and move constructors, and I have no clue how or when that's actually going to happen.

[dejlek]

Maximum priority"

stop everything, all hands on deck until this is fixed

For something that nobody uses, and probably will have extremely rare usage even if it worked as expected???