[feature] FCS API that reports unnamed DU and exception fields

[smoothdeveloper]

I'd like to have checks on F# code that reports DUs and exceptions for which the fields are left unammed.

type DU =
  | Case1 of int                    // kind of ok
  | Case2 of ok: int * okok: string // ok
  | Case3 of int * noOkCase: string // kind of not ok

exception Exception1 of int                    // kind of ok
exception Exception2 of ok: int * okok: string // ok
exception Exception3 of int * noOkCase: string // kind of not ok

In exchange with @baronfel, it came that FCS is good place for such helper function to be defined, and scaffolding from there, have other tools (IDE, linters, code fixes, etc.) using it.

There is an aspect of this concern which I think could contribute to the F# guidelines around authoring of DUs and exceptions.

If there is appeal for this, I thought of those relaxations:

• type is not public
• type is defined in a script
• there is a single field

I'm considering an extra one, if the type of the fields are all distinct, despite I don't think it is the best, if we'd bring this to the F# guidelines.

Is your feature request related to a problem? Please describe.

I find it problematic in debug scenarios for cases with many fields, also I'm sad that the implementation for #1885 doesn't pop up everywhere it would be useful, if only we nudged DU / exception authors, to name the fields.

Describe the solution you'd like

I'm willing to work on implementation of such helper function in FCS API, and depending where we want to take it, look at places I could put it in practice (say a code fixer, if we have infrastructure that would suggest member names).

Describe alternatives you've considered

Remain oblivious to the presence of unnamed fields, and see less usage for #1885

[vzarytovskii]

Probably a use-case for future analyzers sdk work.

[smoothdeveloper]

@vzarytovskii thanks. I am all down for taking this wherever I'm nudged towards, especially if I can get a bit of coaching / pointers on how we want this shaped, from FCS or any other standpoint.

My end goal is basically to discourage unnamed fields in our F# guidelines, if this gets a consensus.