Not really. If the passed-in or default value doesn't convert to the field's type, SetupArgs panics.
Edit: Variations on this that offer compile-time type checking of passed-in values are possible, too. My use case wouldn't work well with that, though, because the function needs to be called by other functions that would have no clue about the FArgs struct.
You could instead do a version that just swaps in a default for any nil fields.
And in any case, you've got a lot more safety than the original Python code, no?
"And in any case, you've got a lot more safety than the original Python code, no?"
Only insofar as your approach puts the values back into a struct that can subsequently be used in a type safe manner. Arguably that's better than having no type safety at all.
But I think my main gripe with your design is that it is not just less type safe and slower, it also comes with more mental friction and verbosity than what Python does.
Granted, it's a lot less verbose than my Go code, which makes it a good solution in some scenarios. But in my view it's not a good general replacement for default keyword args and you didn't claim it was.
I certainly wasn't arguing it was a perfect substitute for default args, just that it was easier to manage than the example you gave.
The application I'm currently working on is mostly a direct port of Python code to Go. Python code I originally wrote. You needn't tell me it fails to accomplish all the things Python's default args do.
