[RFC FS-1079] - (already implemented) - interaction of autogenerated .Is* properties for DU cases and signature files

[T-Gro]

The RFC FS-1079 specifies FS-1079 :

"If a union type is in a file with a signature, that signature can entirely hide the representation of the union type, and yet still individually reveal the individual IsFoo, IsBar members. (Other generated members not covered by this RFC can't be individually revealed like this.)"

Which means that:

• Code not using .fsi files can declare type MyDu = A | B | C and immediately use the generated IsA,IsB,IsC testers
• If that code decides to start using signature files, users have to know to explicitly type out signature of those boolean tester properties
• There is not much help in advising that manual signature extension

I would like to propose a more language supported mechanism for declaring the intent of wanting/no wanting the tester property generation from a signature file perspective, without having to manually specify it for every DU case.

This could either be in the form of a new attribute applied, or a syntactical language extension. (e.g. inspired by with get,set markers, which are also possible in signature files).

My specific proposal to close this design gap of RFC FS-1079 would be:

• A new attribute [<GenerateTesterProperties(true|false)]
• Default value would be true if attribute is not specified
• Existing DUs in FSharp.Core would be annotated with "false", since they do expose their own testers already and we want to avoid 2 properties doing the same, but with different names (e.g. "IsSome" vs. "IsValueSome")

cc @kerams , @Tarmil , @abelbraaksma , @dsyme , @vzarytovskii

[dsyme]

Is this attribute only for use in signatures? Or if it is present in the signature it must also be in the implementation?

[T-Gro]

Right now, it does not come with any syntax construct.

When using .fs files only, you do not have to do anything, and you automatically get the new .Is* property testers.
If you use .fs and .fsi files, you have to specify the exact signature, and implementation is then autogenerated for you.

The idea of making this an explicit language construct would be a new attribtue to be applied to the signature, but that is just a proposal.

[Tarmil]

I feel like this causes a problem where the contents of the .fsi file are no longer sufficient to know what the public API is; you also need to look into the .fs to find out what the generated members are. Doesn't this break optimizations where downstream files are not re-checked when you edit a .fs file that is hidden behind a .fsi?

[T-Gro]

If you look into the .fs, you will not find anything - the members are generated automatically for you, they are not written out in the .fs file.

[T-Gro]

Optimizations will not get broken.
You still have to write out the cases, and the properties are derived from the cases( cases A | B | C -> properties IsA,IsB,IsC).
A change in the cases has to happen in the .fsi file, so cache invalidation will work fine here for incremental checking.

[Tarmil]

Right, I was thinking of the case where the .fsi hides the cases. Ie the .fsi just declares [<Sealed; GenerateTestProperties true>] type T. I guess this case is out of the question then, which makes sense.

[T-Gro]

Indeed.
The .fsi still needs to spell out all the cases.
But it could avoid typing (and "magically" knowing what to type) the tester property signature for each case.

[abelbraaksma]

A new attribute [<GenerateTesterProperties(true|false)]

Since *.fsi files require you to repeat the attribute declarations, it will create some semblance of discovery. That is, *if you look at the fsi file, you will not also need to look at the implementation file to know what is exposed.

To be fair, though, in a separate suggestion, we might want to remove that requirement (and turn it into a warning). I mean, right now, each time I use Obsolete with a nice explanatory string, I have to copy that over and maintain them to be exactly the same in two spots. This, I think, goes against the succinct nature of F#.

Default value would be true if attribute is not specified

@T-Gro I'd suggest to make the default value false instead. You don't want to magically expand a surface area without the user knowing.

We may, though, allow the attribute at a higher level (assembly). That way, a library writer only has to "opt in" once, and may "opt out" for individual DUs.

TLDR: I agree to (most of) your proposal here. While I usually prefer being explicit, but here you allow people to opt-in.

[T-Gro]

I am not sure we have a precedence for an assembly-level attribute affecting compilation of the very same unit, do we?
I also do not believe their usage is commonly known - I would personally put them in the "google how it is typed before every usage" category.

[abelbraaksma]

Agreed (to the "look up how you type it" remark).

But, look up any documentation on any attribute, it always shows the associated AttributeUsageAttribute. Just to say that, assuming someone knows of the attribute, they probably seen the docs page, and therefore know it can be used globally.

I am not sure we have a precedence for an assembly-level attribute affecting compilation of the very same unit, do we?

We do. Some examples that comes to mind are StringFreezingAttribute and RuntimeCompatibilityAttribute (both have been around since forever) and ReferenceAssemblyAttribute. They all influence how the compiler compiles the assembly. I'm sure there are others.