Open JohelEGP opened 5 years ago
Luckily, it seems that EWG approved the CTAD patches, says https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/.
There's also https://github.com/nholthaus/units/pull/217#issuecomment-436797746.
The next committee meeting (http://wg21.link/N4783, July 15 – 20, 2019) is the last opportunity to put into the WD the CTAD wording for alias templates for C++20. It looks like the wording's difficult, so it might not make it.
Class Template Argument Deduction for Alias Templates made it in for the C++20 CD (https://github.com/cplusplus/papers/issues/566).
@johelegp I think resolving this issue is the crux of the 3.0 release. Do you think you can revert the strong types?
Yes. I'll get to it right away.
I believe merging #150 was an error.
For starters, its title is wrong. The units already were strong types, so there was nothing to "strengthen." The README is very clear on the advantages implied by this type safety, unlike using
double
or a type alias likeusing meters = double;
for representing meters. I should have used some other term.The purposes of the changes in #150 were to allow using CTAD and improved error messages. Out of this came the idea manifested in #167, which greatly took care of the latter purpose. And CTAD became the only purpose (personally) for #150.
Since then, we've discovered a few problems with the merged #150, as discussed in #200. In exchange for CTAD, we're paying
N * M
more in some ways. What used to be a single partial specialization ofstd::common_type
forunit
s, becameM
specializations for each of theN
"strong" units.Hopefully one day alias templates can support CTAD, as is being proposed in https://wg21.link/P1021. For now, I'd rather settle with being explicit about the underlying type. Naturally, I propose myself for reverting #150. And I am sorry for pushing for it without fully realizing what it entailed.