Allow parameter-less CustomOperation

[vzarytovskii]

Description

Implements fsharp/fslang-suggestions#1250

I can't think of the need of putting it under language version, since if new fslib is used with old compiler, said compiler will be unable to produce warning that new attribute constructor won't have any effect

Checklist

• Test cases added
  • Add lower and upper case methods
  • Add Quoted method names test, disallow if needed this is allowed now, so we'll allow it in the new attribute.
  • Add operators methods irrelevant, since operators are static methods.
• Add RFC (does this need an RFC?) this doesn't need an RFC, since it's a very minor change.
• Disallow empty string as name (allowed now, but unusable, should it be an equivalent of unit constructor?) empty name is the equivalent of parameterless attribute.
• Release notes entry updated

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/FSharp.Core	docs/release-notes/.FSharp.Core/8.0.200.md
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.200.md

[vzarytovskii]

Only took like a month to figure release notes automation out. @nojaf if you'll have a minute, could you please check the format and see if it needs and adjustment?

[nojaf]

Only took like a month to figure release notes automation out. @nojaf if you'll have a minute, could you please check the format and see if it needs and adjustment?

The example looks off compared to https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

[vzarytovskii]

Right now, the following code

openSystemtypeC()=[<CustomOperation("foo bar")>]member_.M()=()member_.Zero _ =()member_.Yield _ =()letc= C()
c {``foo bar``()}
c {``foo bar``}

will yield the following compiler diagnostics:

error FS3099: 'foo bar' is used with an incorrect number of arguments. This is a custom operation in this query or computation expression. Expected 0 argument(s), but given 1.
error FS0501: The member or object constructor 'M' takes 0 argument(s) but is here given 1. The required signature is 'member C.M: unit -> unit'.
error FS0501: The member or object constructor 'M' takes 0 argument(s) but is here given 1. The required signature is 'member C.M: unit -> unit'.

Which is a bit confusing. @T-Gro@0101 What do you think if we disallow spaces in the parameters of the attribute, and in method names if attribute is parameter-less? Like introduce a new error (or warning) under preview version which will let user know that builder will compile but won't work?

[T-Gro]

Right now, the following code

openSystemtypeC()=[<CustomOperation("foo bar")>]member_.M()=()member_.Zero _ =()member_.Yield _ =()letc= C()
c {``foo bar``()}
c {``foo bar``}

will yield the following compiler diagnostics:

error FS3099: 'foo bar' is used with an incorrect number of arguments. This is a custom operation in this query or computation expression. Expected 0 argument(s), but given 1.
error FS0501: The member or object constructor 'M' takes 0 argument(s) but is here given 1. The required signature is 'member C.M: unit -> unit'.
error FS0501: The member or object constructor 'M' takes 0 argument(s) but is here given 1. The required signature is 'member C.M: unit -> unit'.

Which is a bit confusing. @T-Gro@0101 What do you think if we disallow spaces in the parameters of the attribute, and in method names if attribute is parameter-less? Like introduce a new error (or warning) under preview version which will let user know that builder will compile but won't work?

Error has the problem with existing code (builder author, not consumer) compiling fine, warning at build time of the builder could work.

[vzarytovskii]

Error has the problem with existing code (builder author, not consumer) compiling fine, warning at build time of the builder could work.

Diagnostic will only affect builder author, not consumer. So existing compiled builders should work fine (if they anyhow using custom operations with spaces inside).

[T-Gro]

Error has the problem with existing code (builder author, not consumer) compiling fine, warning at build time of the builder could work.

Diagnostic will only affect builder author, not consumer. So existing compiled builders should work fine (if they anyhow using custom operations with spaces inside).

It's just the unpleasant situation for a builder author to update .NET SDK, and suddenly getting a new error.

[vzarytovskii]

Error has the problem with existing code (builder author, not consumer) compiling fine, warning at build time of the builder could work.

Diagnostic will only affect builder author, not consumer. So existing compiled builders should work fine (if they anyhow using custom operations with spaces inside).

It's just the unpleasant situation for a builder author to update .NET SDK, and suddenly getting a new error.

I don't think it's used anywhere (as it can't be utilised in any way), it will be under version flag as well. And it makes code more correct. I'm fine with warning as well.

[0101]

I don't think it's the space, I see the same error even without it. Can we make it work? Or just give diagnostic that tells you to write _ instead of () in the method definition. Whatever is easiest.

[vzarytovskii]

Well, it seems that you can, in fact, call custom operations:

openSystemtypeC()=[<CustomOperation("foo bar")>]member_.M(())=()member_.Zero _ =()member_.Yield _ =()letc= C()
c {``foo bar``}

compiles just fine, so we can't disallow it.

I will just add the check for the new case (parameterless constructor).

(https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AbEAzAzgHwgAcYA7AAgGUBPXAFxgFsBYAKDupPIGEAKASnIBeNuTHkA2gB5uAV3oRGAeRJQAhnQCWEUrwBE2CBHLA1UPfwB8AXVHjGTYDCjkA+gDoAsrwGCh5ATsxB0YnFw8ALWdjV2EA/iDyELC3dwBNTRgMABM3OMDWcXI2DBg6cjA4vgTWNkqAb3IAAybDY1MoFvIAXzYgA)

[vzarytovskii]

Actually, disregard my question about spaces in the CustomOperationAttribute, since code I wrote in the example is incorrect.

[vzarytovskii]

Ok, this is ready, I decided not to put Experimental attribute on it, since it's too noisy for normal usage. As well as permit parameterless attribute on the following

[<CustomOperation>]member_.``foo bar``_ =()

It will work exactly the same way it works now with

[<CustomOperation("foo bar")>]member_.FooBar _ =()