Extending generics for Workflow and Activity

[wilsonehusin]

I've been toying around with the project and it makes me wonder if it's worth extending the generics usage to ExecuteActivity and its friends. By extending, I mean:

type Activity[TResult, TArg any] func(context.Context, TArg) (TResult, error)

func ExecuteActivity[TResult, TArg any](ctx Context, options ActivityOptions, activity Activity[TResult, TArg]], activityArg TArg) Future[TResult]

This way, we can achieve compile-time type safety at the compromise of limiting activity argument to exactly one (excluding context.Context).

In my experience using Temporal SDK, I've always ended up defaulting to make workflow and activity arguments as struct anyway to avoid friction around versioning, so this "restriction" is actually a plus in my book, encouraging better hygiene. Curious what you think!

[cschleiden]

I had explored that as one of the options when generics came out: https://cschleiden.dev/blog/2022-03-06-go-workflows-generics

Go Generics - Approach 2: restrict activity functions

back then I did not want to adopt this since it felt too restrictive. Was hoping generics might evolve and provide better support for that scenario but that doesn't seem likely at this point.

Maybe having two ExecuteActivity methods could be an option 🤔 Need to think about this a bit more.

[wilsonehusin]

Happy to collaborate on experimenting / implementing! I'm going to try running this on my toy project for a bit and will report back if I find anything interesting.