Would it ever be possible/make sense for a

Union

to work as a return type? E.g.

await Get(Foo, ...)

gives me all rules registered returning a type that has an associated

UnionRule(Foo, ...

)?

Reflection would be useful for generating rule (currently my Metalint experiment needs to cache which rules it has generated). But I think this would be runtime-only, because it's a Get? Which is too late for registering new rules? So I'm not sure what you could actually do with these in userland.

My idea is to use this for

lint

which also runs formatters and fixers. Instead of 6 Gets, if I used inheritance I think I'd be able to use only 2 Gets (target tools and targetless tools)

I think c++ calls that an upcast

yeah. Type-erasure ftw

This might lead to ambiguous paths in the case of diamond inheritance, or multiple layers of inheritance. Eg

A > B > C

, C might have an ambiguous path to A with routes

C=>A

and

C=>B=>A

1. Unions dont actually take into account inheritance 2. The rule graph doesn't allow ambiguity (I think) 3. Python doesn't have this problem because it enforces a consistent MRO

yea. here is some discussion of one position where we could potentially remove the restriction: https://github.com/pantsbuild/pants/issues/11354

Seems the technical half is just registering these "type-erasure" rules? The scarier side is the "what does this mean" side

I think that your original question is one of the use cases covered in the ticket I linked: it's just a question of whether you want to bound the subtypes of the declared type to only being union members, or actually using inheritance.

Why don't we require inheritance for union members today?

the motivation was to allow a plugin to declare that an existing type was in a `@union`… just a hypothetical though.

In this case, the union member set is bounded (only need 2 boilerplate rules) so I'm prone to punt as to not implement something that isn't needed and give us a headache later

yea