Question: Why overloads instead of optional parameters?

Edit:

I’m giving the FSharp.Data.GraphQL client provider another try, since it’s been a few months. Looks like I’m not running into the same errors I got last time.

One thing I notice is that when I create an operation using a query like so:

let op = B.Operation<"""            query ($uId:Int, $rId:Int, $sinceTimestamp:String, $first:Int, $offset:Int) {
              answer(id: $rId) {
                agreed_users (sinceTimestamp:$sinceTimestamp, first:$first, offset:$offset) {
                    id
                    is_verified
                    username
                    avatar
                    follows_status(uId: $uId)
                }
              }
            }""">()

op.Run creates an overload for every permutation of parameters, plus a runtime context.

Is there any reason optional parameters were not used instead? Seems like it would be much easier to read and use, and probably more performant too. If there’s no particular reason, is that something you would consider?

[johnberzy-bazinga]

@NatElkins one option is to just generate our methods with explicit options rather than creating all the overloads. Maybe even providing both options and parameterize the new behaviour.

type MyApi = GraphQLProvider<"schema.graphql", explicitOptionalParameters=true>
let input = MyApi.Types.MyInput(x = "required", y = Some "optional")

[ivelten]

@NatElkins as you said, yes, we originally designed type constructors to use optional parameters for their properties. But we faced a problem with the Type Provider SDK itself and nullable/option types.

The SDK does not allow us to use an option or nullable type as an optional argument when declaring a provided constructor - at least not if we don’t provide a default value for it. But the design around it does have its own complications. I opened an issue in the Type Provider SDK repository that explains better this problem.

Basically, if we create an optional argument, we need to provide a default value. And if the optional argument is a value type, it does not have an “empty” definition, so there is no way to know if the user passed or not a value. Even when we get the default value, there is no way to determine if this value came as an omission of the optional parameter by the user, or if this value actually came of the user providing it.

Using a practical example, if the optional argument is an int type, and the default value is 0, when the user does not provide a value, we can’t say if 0 was given by the user or is just the default value that came by the omission of a value in the optional parameter. So, in the end, we would not be able to know if the optional property, which is an int option, should receive Some 0 or None.

Based on this issue, we decided that overloads would be the best workaround. As optional parameters are treated as overloads in the IL, we thought that in practice, the result of it running would not change. I also did test it with around 10.000 overloads and did not notice an impact at the time.

If this problem turns things unusable, I think we would need to think about the other workaround in the issue. Or discuss any other alternative that we did not think of at the time.