[bsaul]

I had the same feeling, and then i tried to implement the same solution in swift (which has more evolved constructs for enums and option sets), but it's actually not easy to do as well, if you want to handle all those constraints at the same time:

1/ a potentially big number of options, without creating functions with a huge list of parameters

2/ options with associated values (revision: int)

3/ reusable options between different operations, with type safety preventing wrong combination.

=> 1/ prevents you from using function overloading and default parameters

=> 2/ prevents you from using optionset (they're just bit masks)

and

=> 3/ prevents you from using regular sets or arrays as operation parameter.

I haven't spent more than half an hour trying to find a solution, so maybe there's a smart trick that would work, but it won't be an obvious solution either.

[fauigerzigerk]

I realise that you tried to work with the same constraints as the Go solution for the sake of argument.

But the whole rationale for having 3/ in the first place isn't valid in Swift, so it seems to me that the obvious Swift solution is to use an enum per operation.

[bsaul]

It does makes quite a bit of sense, especially in the case where all those enums end up being processed by one single private function, such as "configureServer(config: ConfOption) ". (i'm refering to the linked post by Dave cheney here)

I spent a bit more time on the problem, and now i'm pretty sure it is also not solvable "cleanly" in swift, because it actually would need to model some kind of constraints over the accepted values of a type for a parameter.

Something like get(opt: Options<restrictedTo [.prefix, .revision]>... )

Otherwise you'll need to manually create a subenum, and manually compare cases from the original one with the sub one.