Hi Arsen, Am Dienstag, dem 21.07.2026 um 14:19 +0200 schrieb Arsen Arsenović: > [for convenience, I'll be using 'ttree' to refer to the hypothetical > gradually-typed tree system and its central type] > > Martin Uecker <[email protected]> writes: > > > I do not think so. Alone the compile-time cost of templates makes this > > a bad trade-off in my opinion, and I find compilation time already to > > be problematic for GCC. > > That's a reason to improve the GCC implementation of templates (of > course, no easy feat), not to make GCC less maintainable.
you seem to take it for granted that it templates improve maintainability, but in my personal experience the opposite is true. > > We already have a relatively small base of active developers, and a yet > smaller base of reviewers. I am not sure that adding more complexity would help with this. > > Having fewer tools for writing correct code, having fewer type > annotations for new developers, and having more latent bugs are all very > bad ideas. The first means more time needs to be spent verifying and > re-verifying changes, which directly decreases effective review > capacity. The second means new developers must spend more time figuring > out types that can be passed in given places, which they will get wrong, > and which will demotivate them. The third means more bugs go uncaught > and more time is spent fixing those that do get caught. > > I'd be fine with gcc build time tripling or more to reduce those > factors. Speaking for me, I would not be able to contribute anymore if build times triple. It is already a pain today and I have fairly fast machines available to me. > > That said, there's no reason why we couldn't make it possible to > essentially disable the 'tree' type checking. I don't think that's > worth it, frankly, and I think it adds to the combinatorial explosion > that is GCC build-time configuration, but we could explicitly make it so > that 'ttree' with, say, checking disabled, compiles down to: > > template<typename...> using ttree = tree; > > Hence, short-circuiting all or nearly all cost. If it was my call, I would start by introducing simple wrapper types for expressions, types, statements, .. and also only for some parts of the code where this makes sense. This would add static type checking and readability (!) without adding any cost in terms of compilation time. > > When I was initially thinking about this problem, I did put this down as > a design goal for a different reason: showing that GCC would compile to > the same machine code anyway even with this typechecking added, thus > making it easier to approve the patch series. > > I'm now of the opinion that this original goal of mine isn't worth it, > especially as we could use 'ttree' to provide member accessors to > increase the level of assistance that can be provided by editors and/or > decrease verbosity (discovering what the correct accessor is for some > part of some tree_code is a bit of an art even today; this also did come > up in the C++ NAS patch, where TREE_LANG_FLAG_... was being used > incorrectly - this, too, could've been prevented, but luckily Thomas > caught it in review). > > Of course, the latter is also impossible in case we do this short > circuiting for sake of compilation time. > > I really do wish I had a partially done example, so that we could do > some empirical study on this. But, alas… > > > I agree that catching errors at compile time is good, but in > > many cases this can be achieved in C just as well. I usually find > > that people underestimate what can be done in C alone. Clearly, C++ > > allows you to do more sophisticated typing (I wrote for some time > > expression-template libraries before I decided that this just takes > > too much of my time). Being clever with C++ templates is - in my > > experience - usually a bad trade-off as the cost in complexity and > > compilation times exceeds the improvements in type safety you can > > achieve in this way. > > Please implement a conversion operator in C. Adjusting 'tree' is a > non-starter without those. In my experience, having implicit conversions makes it harder to read and maintain code. > > Then, we'll also need packs of types and of heterogeneous values that > can be manipulated at compile-time, to represent sum types. > > > I agree, but the untypedness of tree is not the fault of C... > > I agree, but I never said that it was. Just that we can't fix it in C > in a viable way. > > > ... and changing this would not require switching to C++. > > It would. There is no method by which we can implement correct rules > for gradual typing in C. Especially not earlier versions of C. Gradual typing can also be done in C. For example, here is a variadic type: https://godbolt.org/z/d8djYsMx5 (And in this example, the compiler completely removes all overhead for the dynamic type checking and devirtualizes all functions) > > > It would simply require to introduce C types for each specific node > > type. > > The "simply" here is doing a lot of heavy lifting. There's nothing > "simple" about changing *the* core type of a 3 million LoC codebase. > > As I said, gradual typing is the only alternative to dynamic typing > possible for GCC today. > > C lacks user-defined conversions; this alone makes it impossible to > implement gradual typing in C. You can implement conversions just fine, you can just not have implicit conversions. > > I also highly doubt that _Generic would be able to perform the > operations necessary to check for, say, overlaps of two sum types > (i.e. whether two different instances of what I called 'one_of' in my > original message contain each-other), which would be necessary to > determine whether a conversion is safe. > I also have to wonder whether the tokens emitted by the hypothetical > requisite macro soup would end up being slower to compile than the > equivalent template soup. I seem to recall some article on LWN about > macro expansion cost being a real problem for Linux, but I can't find it > now. I do not propose to have a lot of macros either. In fact, I am arguing against adding a lot of complexity, be it either templates or macros. Martin
