Type_id_as_type!

language design
1

not familiar with compiler internals, so i'm not sure how feasible this is, but i realized that with a single magic macro we could make rust generics basically as powerful as zig comptime.

the argument would be a const expression that evaluates to a TypeId, and it would expand to a magic type expression corresponding to the type of a TypeId.

this would be a huge extension to the rust language, but it would be interesting as a compiler experiment.

3 Likes
2

it's also worth noting this would make it possible to implement typeof in a limited capacity.

3

Isn't this just compile time reflection in Rust?

Not sure how you imagine it would work though? In fn type_id_as_type!(type_id: TypeId) -> ??? what are inputs and outputs (I assumed it's TypeId)?

I did some pondering on this, but my interests pulled me towards YAML and SIMD (an unholy combination, if there ever was one).

4

TypeId is currently a one directional 128-bit hash of type information. However, the compiler does maintain a map of generated TypeIds to ensure no accidental collisions happen (within a statically linked unit), so it would be theoretically possible to go from TypeId back to type. I don't see how it helps the expressive power of generics, though. Namely, a significant part of the expressive power of Zig's comptime is that they're syntactic templates that do name resolution after substitution of the comptime arguments, whereas Rust generics, even if we extend const generics to allow TypeId, are checked before instantiation and must be well formed for any and all instantiation that satisfies the trait bounds.

5

The compiler does not store any tables of type ids today, collisions are prevented by using a 128-bit hash. Adding such a table wouldn't necessarily be impossible, but it would quite tricky to do with the compilers query structure I think.

1 Like
6

When I was looking into compile time macros. What I did was create a derive macro that for a given T: Reflect will invoke a (const) method on that type, and that TypeInfo will contain all the info needed to construct a full descriptor of value. But to achieve that, I ran into problems:

  1. You can't define a (although you can resort to type hackery and make a impl Foo { const fn typeinfo() -> TypeInfo {...} })
trait Reflect {
  const fn reflect() -> TypeInfo
}

making it non-composable.

  1. It's not possible to construct an enum from Discriminant, even if it's possible to extract.
  2. If I recall correctly, there were some issues with functions being essentially variable argument generics, i.e. heterogeneous lists, while having no way to express that in code.
7

I think this could be done for associated types and consts, basically turning a TypeId const into the output type. Though it'd require a mono-time error if the computed type doesn't fulfill the bounds.

8

the idea is it would let you conditionally include fields and such.

for example, a datastructure may be able to become a ZST when instantiated with ZST type arguments.

i guess technically this overlaps with specialization?

9

I still don't understand how you envision the macro would be used. Could you provide some concrete example code?

10

Could you give me an example of what you mean? Types can be conditionally ZST.

11

for example, a Vec type with an opaque capacity could remove the capacity and heap pointer fields altogether when instantiated with a ZST, and just track the length field.