Allow Introspection on RestrictedExpression

[ShiromMakkad]

Category

User level API features/changes

Describe the feature you'd like to request

For testing purposes, I'd like to access the inner value of a restricted expression. For example,

assert_eq!(RestrictedExpression::from_decimal("16.0").into_inner(), "16.0".to_string());

Describe alternatives you've considered

It would be fine if that's not possible if we could just compare equality between RestrictedExpressions like so:

fn some_function_that_parses_data_into_cedar_context(value: T) -> HashMap<String, RestrictedExpression>;

let expr_map = some_function_that...(my_data);
assert_eq!(res.get("my_number").unwrap(), RestrictedExpression::from_decimal("16.0"));

I haven't dug around the Cedar codebase but I think you can just #[derive(PartialEq, Eq)].

Additional context

For now we're doing:

fn compare_expr(v1: &RestrictedExpression, v2: &RestrictedExpression) {
    assert_eq!(format!("{v1:?}"), format!("{v2:?}"));
}

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

[shaobo-he-aws]

@ShiromMakkad could you clarify why introspection is needed? I think for the alternative, you can evaluate restricted expressions into values and do the equality testing.

[ShiromMakkad]

It's for convenience in unit testing. It could be done like I showed above or assert_ne!(RestrictedExpression::from_decimal("16.0"), RestrictedExpression::from_decimal("15.0"));

[cdisselkoen]

Deriving equality on RestrictedExpression sounds perfectly reasonable to me. We'll have cases like, the restricted expression [1, 2, 3] will be != the restricted expression [3, 2, 1] even though, after evaluating, those produce equal Cedar values. But presumably that's the expected behavior when considering equality of expressions.

[cdisselkoen]

more to the point of @ShiromMakkad 's above example, derived equality on RestrictedExpression would find that from_decimal("16.0") != from_decimal("16.00"). Is this your expected behavior @ShiromMakkad?

[ShiromMakkad]

I think it's fine in the current version to go for a more restrictive result where "16.0" != "16.00". But if decimal("16.0") == decimal("16.00") are equal inside a cedar policy, it would be nice to have a way to evaluate that. I think that could also be a separate function though. Both interpretations are useful. For my unit tests, it wouldn't matter either way (the option you suggested would work just fine).

[cdisselkoen]

The second interpretation (where decimal("16.0") and decimal("16.00") are equal) is what you would get if you called eval_expression on each expression, and then compared equality on the result.

[ShiromMakkad]

Ok, then I'd prefer the first way where "16.0" != "16.00"