Function comparing 2 variables of any type ( without static constraints )

A tricky problem. I have to implement a function fn eq( a, b ) comparing a and b. The function should return false if either types of variables are different or variables have different values. The function should return true if both type and value are the same.

A possible solution is to use dyn Any as Hyeonu advised in his answer. But such a solution has limited application because it restricts arguments of eq with static constraint. Maybe it is possible to come up with a more practical implementation?

Playground of such a solution ( please use format if you don't like my style ).

It gives error:

error[E0759]: `other` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
   --> src/main.rs:119:29
    |
108 |   fn eq( &self, other : &Logic< RightRef, RightCopy > ) -> bool
    |                         ----------------------------- this data with an anonymous lifetime `'_`...
...
119 |             Logic::ValNode( e2 ) => return eq( e1, e2 ),
    |                             ^^             -- ...and is required to live as long as `'static` here
    |                             |
    |                             ...is captured here...

For more information about this error, try `rustc --explain E0759`.
error: could not compile `playground` due to previous error

1 Like

Just an attempt:maybe macros works better than functions in the case.My computer is absent, but I think this can pass cargo.
macro_rules! eq!{($i:expr,$j:expr)=>{if $i==$j{true}else{false}}}

Well, is it the reason why cargo disallow a "==" between unknown types that not all types suits the function PartialEq?

2 Likes

I don’t think it’s possible to avoid the 'static bound.

Note that none if this is particularly “practical”. This feels like something that you’d want to have in a dynamic language, not in Rust.

One good change to make the solution with 'static more “practical” would be to change the arguments from owned to borrowed.

5 Likes

What do you want to do with this?

There is usually no good reason to write a function that always returns the same thing when called with different type parameters, because at the call site where the parameters are instantiated you would always know the return value anyway. So if you just use == directly, the compiler will just tell you if the types are incompatible and you can replace that expression with false, because it was useless anyway.

In deeply nested generic functions you generally should not care whether two type parameters are the same: if they are meant to be comparable then your signature should indicate that and providing comparable types is your caller's problem. To check at runtime whether two types determined at compile time are the same or not is a strong indication of a bad design. If the types are known at compile time you should resolve them immediately.

Also... Uh, that playground code. Are you maybe a Haskell programmer? You can't do everything in the type system. It looks like you're trying to make something extremely abstract and the fact you're mixing compile time and runtime concerns suggests it's not something that can be done solely at compile time. What is the primary concern of your code? Is it about LeftRef, RightCopy, R, V, and PartialEq? Or is it about Logic and Nothing? I think you should take a step back and evaluate what you really want the type system to do for you here.

8 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.