[FEATURE] Generics for v2 release of go-sdk

[skyerus]

Requirements

Now the go-sdk has been upgraded to go 1.18 it can make use of generics.

The obvious candidates where leveraging generics would reduce bloat:

• Evaluation types are effectively the same structure with different Value types
• Resolution types, as above, are effectively the same structure with different Value types

Pros:

• Less types to maintain
• Less duplicated code
• Less type inference
• Less chance of accidental inconsistent behaviour across types

Cons:

• Breaking change
• Breaks contract between providers and sdk

Perhaps this undertaking isn't worth the effort but it's at least worth raising.

[paddycarver]

I just tinkered with this for something similar. A constraint to be aware of: methods cannot accept type parameters.

So you can't turn

thisWillBeABool, err := client.BoolValue(ctx, "my-flag", true, myContext)

into

thisWillBeABool, err := client.Value(ctx, "my-flag", true, myContext)

You have to turn it into this:

thisWillBeABool, err := openfeature.Evaluate(ctx, client, "my-flag", true, myContext)

where the client gets passed to a package-level function (which can have type parameters). The function looks something like this:

Evaluate[T any](ctx context.Context, client *Client, flag string, defaultValue T, evalCtx EvaluationContext, options ...Option) (T, error)

This also would mean that client.ObjectValue would be able to accept a user-defined default type and could always return that type, without the need for any interfaces or runtime-checking of the type by the caller.