From 8c2756fcc53ffb7cc240ae94ddbffd2516b9d3ce Mon Sep 17 00:00:00 2001 From: Sokwhan Huh Date: Tue, 24 Oct 2023 21:20:48 +0000 Subject: [PATCH] Remove strongly typed enum support from the specification None of the stacks (cel-go, cel-cpp, cel-java) currently support strongly typed enum, leading to confusion. We may revisit this when we add concrete support for this in any of the stacks in the future. --- doc/langdef.md | 55 ++++++++------------------------------------------ 1 file changed, 8 insertions(+), 47 deletions(-) diff --git a/doc/langdef.md b/doc/langdef.md index fec4197d..338fd98e 100644 --- a/doc/langdef.md +++ b/doc/langdef.md @@ -10,7 +10,6 @@ This page constitutes the reference for CEL. For a gentle introduction, see - [Name Resolution](#name-resolution) - [Values](#values) - [Numeric Values](#numeric-values) - - [Enumerations](#enumerations) - [String and Bytes Values](#string-and-bytes-values) - [Aggregate Values](#aggregate-values) - [Booleans and Null](#booleans-and-null) @@ -207,11 +206,10 @@ combination of one or more of: indicate that we're accessing a field within a protocol buffer or map. * Protocol buffer package names: a simple or qualified name could represent an absolute or relative name in the protocol buffer package namespace. Package - names must be followed by a message type, enum type, or enum constant. -* Protocol buffer message types, enum types, and enum constants: following an + names must be followed by a message type, or enum constant. +* Protocol buffer message types and enum constants: following an optional protocol buffer package name, a simple or qualified name could - refer to a message type, and enum type, or an enum constant in the - package's namespace. + refer to a message type or an enum constant in the package's namespace. Resolution works as follows. If `a.b` is a name to be resolved in the context of a protobuf declaration with scope `A.B`, then resolution is attempted, in order, @@ -267,16 +265,6 @@ such as expression evaluation, rounding mode, or exception handling. However, any two not-a-number values will compare equal even if their underlying properties are different. -### Enumerations - -Each protocol buffer enumeration is its own CEL type. Enumerations have no -operations other than equality (and inequality), obtaining the type from a -value, and conversion to an `int`. (No conversion to string is supported, as -an enum value might have 0, 1, or many names.) Values of type `int` can be -converted to enum values as long as they are in the range `-2^31` to `2^31 - 1`. -A value of type `string` can be converted to enum values as long as it is a -defined for that enum. - ### String and Bytes Values Strings are sequences of Unicode code points. Bytes are sequences of octets @@ -451,7 +439,7 @@ int32, int64, sint32, sint64, sfixed32, sfixed64 | `int` uint32, uint64, fixed32, fixed64 | `uint` float, double | `double` bool, string, bytes | same -enum E | E +enum E | `int` repeated | `list` map | `map` oneof | options expanded individually, at most one is set @@ -465,6 +453,10 @@ buffers, an out-of-range CEL value results in an error. Boolean, string, and bytes types have identical ranges and are converted without error. +Protocol buffer enum values are converted to the corresponding `int` value. +Protocol buffer enum fields can accept any signed 32-bit number, values outside +that range will raise an error. + Repeated fields are converted to CEL lists of converted values, preserving the order. In the other direction, the CEL list elements must be of the right type and value to be converted to the corresponding protocol buffer type. Similarly, @@ -2456,41 +2448,10 @@ See [cel-go/issues/9](https://github.com/google/cel-go/issues/9). type conversion - - - E (for fully-qualified enumeration E) - - - (int) -> enum E - - - type conversion when in int32 range, otherwise error - - - - - (string) -> enum E - - - type conversion for unqualified symbolic name, otherwise error - - ## Appendix 1: Legacy Behavior -### Enums as Ints - -In many pre-1.0 implementations, protocol buffer enums are all treated as CEL -type `int`, and are legal arguments whenever an `int` is expected. Int values -in the range `-2**31` to `2**31 - 1` can be used whenever an enum is expected. -Values outside that range will raise an error. There are no standard functions -for conversion from strings, and no conversion to `int` is needed. - -``` -type(google.protobuf.Field{}.kind) # was int, now google.protobuf.Field.Kind -``` - ### Homogeneous Equality Prior to cel-spec v0.7.0, CEL runtimes only supported homogeneous equality