FS-1056 - Allow overloads of custom keywords in computation expressions

[Nhowka]

RFC here

[smoothdeveloper]

Would this feature help with what the LINQ query builder can do?

dotnet/fsharp#11446

Maybe the different functions to handle nullable value in LINQ expressions could be unified in later versions of FSharp.Core?

[Thorium]

As the builders are coming fashionable, we'd need more validation possibilities, and extending this would help.

Here is a code sample that is not working in F# 5.0:

type InitialState =
    { Name : string
      Username : string option
    }

type ValidState =
    { Name : string
      Username : string
      MoreData : string option
    }

type MyBuilder() =
    member __.Yield _ =
        { Name = ""
          Username = None
        } : InitialState

    // This fails for custom operator overloading now:
    [<CustomOperation "name">]
    member __.Name(state:InitialState, name) = { state with Name = name }
    member this.Name(state:ValidState, name) = { state with Name = name }

    [<CustomOperation "username">]
    member __.Username(state:InitialState, username) = 
        { Name = state.Name
          Username = username
          MoreData = None
        } : ValidState 

let my = type MyBuilder()
let process (x:ValidState) = 
    //...
    ()

my { name "hello"; username "hello" } |> process // Valid
my { username "hello"; name "hello" } |> process // Valid
my { name "hello" } |> process // Intentionally invalid, compile time error

[Nhowka]

What error are you getting? I was testing it on the fable repl and I feel that it's working fine. Check it here

[Thorium]

The context here:
Currently Farmer gathers the state via computation expression, and then when executed, it generates an ARM-template.

vm {
   name "abc"
   username "myuser"
   system_identity
}

The thing I don't like, is that it validates the state at the execution (runtime), meanwhile your typical F# programs would make the illegal state un-representable:

failwith $"You must specify a username for virtual machine {this.Name.Value}"

But the Farmer is not taking view to the command order (and for backward-compatibility it should stay as that).
So what we want: InitialState: no-username, ValidState: has username.
Very simple change for the that,
here is the full repo: https://github.com/Thorium/farmer/tree/operator-overload

And what happens, when I try to build:
error FS3087: The custom operation 'name' refers to a method which is overloaded. The implementations of custom operations may not be overloaded.

[Thorium]

Ok, found it!
All the overloads have to be bundled together, you cannot do this:

    [<CustomOperation "name">]
    member this.Name(state:ValidState, name) = { state with Name = name }

    [<CustomOperation "username">]
    member __.Username(state:InitialState, username) = 
        { Name = state.Name
          Username = Some username
          MoreData = None
        } : ValidState 

    [<CustomOperation "name">]
    member __.Name(state:InitialState, name) = { state with Name = name }

Ok then...

[Thorium]

Another place where this seems to be a problem is that if the custom operator is coming via an interface:

[Nhowka]

When testing it here it seems like it's in a weird middle state. It works when you add an overload but it breaks with the The implementations of custom operations may not be overloaded. error when you add the CustomOperation attribute again on that second method.

It worked fine and the error went away when I changed the lang version to preview, but probably the code that is working shouldn’t work without that flag. My hope is that that kind of weird behavior disappears when the feature comes out of preview.