On Mon, Oct 4, 2021 at 3:52 AM Zebediah Figura zfigura@codeweavers.com wrote:
Signed-off-by: Zebediah Figura zfigura@codeweavers.com
This series is kind of an RFC, though, because I'm not actually sure we want to do this. The obvious benefit is that we get rid of a lot of common boilerplate that's otherwise pretty hard to sidestep—as shown by the diffstat in patch 3. On the other hand, we might want to do something like GCC's "x <aka y>", in which case this would be a step in the wrong direction (and a pretty impactful step at that.)
This is generally fine to me, although I don't think I see much of an improvement from this going forward. Basically all the cases that are simplified in patch 3 are error messages (unsurprisingly); simplifying the code for those is nice and good but probably not too big of a deal. It would be more significant if we were to add many more errors down the line or if the same kind of boilerplate started to be required in some other places, possibly far from error paths. Maybe that's actually the case?
I guess that kind of "x (aka y)" notes in error messages would be nice to have, although probably not critical. I don't know that the changes made by this patch series would matter a whole lot in that regard though? It shouldn't make a difference for named types and those are often the most interesting ones to "unravel" (I'm thinking of the usual typedef case here).
(This series also has us taking a bit more memory, but it's not a lot. We already allocate names for all numeric types, since they aren't keywords.)
Yeah, I'm not particularly concerned by that either.