Jakub Jelinek <[email protected]> writes: > On Tue, Jul 21, 2026 at 08:34:09PM +0200, Arsen Arsenović wrote: >> Checks-and-uses of TREE_CODEs would also need to become (explicit) >> fallible conversion functions, i.e. >> >> if (TREE_CODE (t) == A) use t; >> >> ... becomes: >> >> if (auto tA = try_as_tree_or_whatever<A> (t)) use tA; >> >> ... or such. (I'd have preferred if the 'tA' could shadow 't', but >> unfortunately if it were to shadow 't' in the then branch, it'd also >> have to shadow it - a lot less usefully - in the else branch; that's not >> an issue in this trivial example but is in general) > > I'm sorry, but this is not an improvement, it is an exact opposite of > that.
Interesting, I thought that this specific example was overly favourable to the idea of in-language gradual typing. It's the trivial case where one check is replaced by another check whose result also gets encoded in the type system/current scope. Such a case - converting a check into a check + extra information in the variable type pretty much mechanically - seemed like strictly an improvement to me. In the languages I was mentioning as a reference, as well as in some others like Kotlin, the check alone would mean that 't' gets a narrower type definition in the scope of the then stmt, but this isn't possible in C++, sadly. Note that, at least initially, calling a function that receives a typed tree with an untyped tree should be possible (and result in the compiler automatically adding a runtime check), and calling a function that receives an untyped tree with a typed tree should probably always be possible. This is indeed what would allow for a gradual change. What was problematic in that example? -- Arsen Arsenović
signature.asc
Description: PGP signature
