Improve error message for Restriction to use named fields for a struct multi case DU

[edgarfgp]

While looking at #3648 . I wanted to understand why there is this limitation.

So this PR is to understand what are the ramification of this change and also for my own education :)

This limitation is specified in the RFC https:/fsharp/fslang-design/blob/main/FSharp-4.1/FS-1014-struct-discriminated-unions.md

But is does not explain why :( .

[edgarfgp]

I did some more investigation and finally understood the reason for this limitation :

It is all down to the fact that struct does not support inheritance so they are required to have explicit names for all the cases (As the generated code tracks the case type and tag) int he same struct :)

See : https://sharplab.io/#v2:DYLgZgzgNAJiDUAfALgTwA4FMAEBBbAvALABQ252i2AGtgPZjYCWAdsqRZdgJr2OvsyFUh2EkA2gB4AysgBOAVwDGyAHwBdUmizYAQoVHkq1AEZ9sADxDM2hrtzMNsqawKA=

[abelbraaksma]

Since the code is autogenerated, the fieldnames could just as well be implicitly taken from the casenames, or be themselves autogenerated as $1, $2 etc. I don’t see how the absence of inheritance prevents this.

What’s more is that a struct DU currently doesn’t use overlapping fields, leading to each struct DU having a size of the sum of all fields. I recall there was discussion fixing this (either implicitly or explicitly). This is easiest with primitive types having the same width (int and uint, for instance). I know that was not the target of this PR, but it has always left me wondering.

That way, the width would just be the union of the fields, plus the tag, which is potentially much more efficient.

[abelbraaksma]

See #9368, fsharp/fslang-suggestions#699 and #5215.

Also: #11718 and #5236/#13897.