Make NewStringList to accept parametrized slice

[gudvinr]

To be able to use list of types whose base type is string you will need to resort to NewDynamicList:

type NotString string
...
types.NewDynamicList(adapter, []NotString{"cake", "croissant"})
...

NewDynamicList uses reflection which can be avoided for such cases.

Another option is to convert []NotString to []string and use NewStringList which will force you to allocate same slice twice.

---

However, quite simple modification like this one makes it possible to use these slices as is:

func NewStringList[T ~string](adapter Adapter, elems []T) traits.Lister {
...
get: func(i int) any { return string(elems[i]) },
...
}
...
types.NewStringList(adapter, []NotString{"cake", "croissant"})

---

In addition to that, something like this can make life easier for types whose natural representation is string but internal representation is not. Some examples of which are x509.OID and its brother asn1.ObjectIdentifier. Both and many others implement fmt.Stringer.

This can be resolved with this:

func NewStringerList[T fmt.Stringer](adapter Adapter, elems []T) traits.Lister {
...
get: func(i int) any { return elems[i].String() }
...
}

Currently, for this case you can't even use NewDynamicList because these types don't represent any "native" type. So you either make another type for therm (and re-allocate slice before passing) or work-around using NewProtoList and wrapper that implements protoreflect.List.

Or, instead of using baseList one could also make traits.Lister implementation but that creates enormous boilerplate.

[gudvinr]

Strictly speaking, the real problem isn't lack of constructors for various list types but rather lack of simple solution to wrap Go slice as CEL list.

If mechanism to do this exists or there's better solution than making feature-purpose constructors, I think this should be way to go instead. But I have only limited understanding of CEL internals so it's rather hard to suggest "real" solution to this problem other than stated in OP.

[TristonianJones]

Hi @gudvinr it's preferable to never touch the types.NewDynamicList or similar as these are meant to be implementation details handled by types.Adapter.NativeToValue and allocated on an as-needed basis during evaluation over the input.

For some custom functions there's a desire for custom list creation, but for this I'd recommend the following:

baseEnv, err := cel.NewEnv(... base env ...)
adapter := env.CELTypeAdapter()
env, err := baseEnv.Extend(
  cel.Function("toArray", 
    cel.Override("toArray_string", []*cel.Types{cel.StringType}, cel.ListType(cel.StringType),
      cel.UnaryBinding(func(arg ref.Val) ref.Val {
        return adapter.NativeToValue([]string{arg.Value().(string)})
      },
   ),
))

Not the most convenient, I admit, but it's also a toy example. We can probably overhaul the list and map types to support parameters, but it's just not something I've gotten to yet.