Re: Gradual 'tree' typing and C++

Hi Arsen,

Am Dienstag, dem 21.07.2026 um 14:19 +0200 schrieb Arsen Arsenovi=C4=87:
> [for convenience, I'll be using 'ttree' to refer to the hypothetical
>  gradually-typed tree system and its central type]
>=20
> Martin Uecker <[email protected]> writes:
>=20
> > 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.
>=20
> 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.

>=20
> 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.

>=20
> 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.
>=20
> 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=C2=A0
machines available to me. =20

>=20
> 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:
>=20
>   template<typename...> using ttree =3D tree;
>=20
> 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=C2=A0
of the code where this makes sense.  This would add static type=C2=A0checki=
ng
and readability (!) without adding any cost in terms of compilation time.

>=20
> 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.
>=20
> 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).
>=20
> Of course, the latter is also impossible in case we do this short
> circuiting for sake of compilation time.
>=20
> I really do wish I had a partially done example, so that we could do
> some empirical study on this.  But, alas=E2=80=A6
>=20
> > 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.
>=20
> 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. =20

>=20
> Then, we'll also need packs of types and of heterogeneous values that
> can be manipulated at compile-time, to represent sum types.
>=20
> > I agree, but the untypedness of tree is not the fault of C...
>=20
> I agree, but I never said that it was.  Just that we can't fix it in C
> in a viable way.
>=20
> > ... and changing this would not require switching to C++.
>=20
> 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)

>=20
> > It would simply require to introduce C types for each specific node
> > type.
>=20
> 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.

>=20
> As I said, gradual typing is the only alternative to dynamic typing
> possible for GCC today.
>=20
> 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.

>=20
> 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