If you’re in a situation where you have a trait object, you can only supply that object to functions that work with that trait. It's sort of a lowest-common-denominator polymorphism. So why do you want to know the type? I'm just curious what your use case is here.
I’m writing a parser for arithmetic and boolean expressions that emerges more and more into an interpreted programming language. I parse an expression into an operator tree, with infix operators that can have more than two arguments. The operator in question is a , for constructing tuples.
When constructing the operator tree, consecutive commas should be merged into a single node with a child for each argument, instead of each being a node with exactly two children. This is to allow the parser to differentiate between nested and non-nested tuples.
I represent operators in my operator tree as Box<dyn Operator> , so I needed a way to figure out if two nodes have operators of the same type to decide if they should be merged into one.
But as suggested by cbiffle, I will switch from the polymorphic approach to an enum approach. That will keep the operator types accessible and makes features that require context sensitive tree insertion with more context than just the precedence hopefully simpler to implement.