You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm new to CEL but it looks like when you use one of the macros evaluating predicates (currently all, exists, and exists_one) on a map, only the current key is made available to the predicate. With the key, you can get the value, of course, but this may be tedious in programs such as
where you have to repeat a long path to the map field. Would it make sense to have, in addition to the two argument form of these macros (not counting the map receiver) to also have a three argument form to conveniently include the value as well? The above example would then become
some.very.deeply.nested.message.some_map_field.exists(k, v, v == 42)
which, for me at least, is easier to read.
The text was updated successfully, but these errors were encountered:
@TheCount I think CEL will need to introduce another macro to make this possible. It's definitely something we've been discussing since the access to the indices and values is inconvenient at best and in other cases impossible.
One option is to introduce an opaque pair type which has a key(),index(), and value() methods and then introduce a new range macro for lists. The design challenge is in handling map types since there is likely an expectation (and a reasonable one) that a range over a map's entries will return a new map. This, by itself, would be a nice feature, but we have to decide what to do with duplicate keys. The default stance is to treat them like an error since you can't guarantee the order in which entries are traversed within a map.
I'm new to CEL but it looks like when you use one of the macros evaluating predicates (currently
all
,exists
, andexists_one
) on a map, only the current key is made available to the predicate. With the key, you can get the value, of course, but this may be tedious in programs such aswhere you have to repeat a long path to the map field. Would it make sense to have, in addition to the two argument form of these macros (not counting the map receiver) to also have a three argument form to conveniently include the value as well? The above example would then become
which, for me at least, is easier to read.
The text was updated successfully, but these errors were encountered: