[RFC FS-1079 Discussion] - Make .Is* discriminated union properties visible from F#

[kerams]

RFC https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1079-union-properties-visible.md
Suggestion fsharp/fslang-suggestions#222

[kerams]

There's one drawback listed

These attributes might incite beginners to check a value's case using a series of if x.IsFoo then ... elif x.IsBar then ... in situations where pattern matching would be more appropriate.

TPSDK allows one to hide Object methods on provided types from Intellisense. This might be a silly idea (it seems like a poor precedent in the first place), but could something like that be applied here? Novices won't be tempted to use .Tag et al. since those wouldn't be visible, while experienced users will (perhaps not right away?) know the properties are in fact at their fingertips.

[charlesroddie]

[<EditorBrowsable(EditorBrowsableState.Never)>] is a good compromise which will prevent a clutter of members for DUs with many cases appearing in intellisense.

There is precedent in set_ methods which are similarly hidden but usable.

type X() =
    member _.M with set () = ()
X().set_M ()

[smoothdeveloper]

The issue would be that this compromise will make the DU types harder to use in C#.

I do have APIs implemented with F# DUs and consumed in C# that I'd like to keep working the way it did so far.

[chkn]

It's not clear to me why one form would be more "appropriate" ...

type Food =
  | HotDog
  | Hamburger
  | Corn

match	if
match food with	if food.IsHotDog then
| HotDog -> "hot dog!"	"hot dog!"
| _ -> "not hot dog!"	else
	"not hot dog!"

There are already other places in F# where it's possible to use an if or match interchangeably, so I think this falls into the category of coding style, which IMHO is better enforced by team coding standards, CI checks, and/or editor tooling.

X().set_M ()

I had no idea this was valid!

[smoothdeveloper]

Fair points @chkn, thanks!

so I think this falls into the category of coding style

I agree

which IMHO is better enforced by team coding standards, CI checks, and/or editor tooling.

I don't disagree, but I like to put an emphasis on the earlier stages as well, API design choices, through features made conservatively wrt the long time idioms of the language and reinforcing those.

In my usage of match, in the places I know are relevant, I'll always prefer listing the cases rather than using the wildcard | _ ->, otherwise the exhaustivity check is turning less relevant.

There is also a suggestion fsharp/fslang-suggestions#731 that I obviously like which goes to that extent of disabling use of wildcard via an attribute.

For extensions that apply pervasively to such core constructs of the language, I'd be in favor of an opt-in approach, this RFC has no opt-in, and I'm not clear there is an opt-out as well.

This is why there may be a tension in how this feature applies to the language and the things that makes F# to me; what is your stance on having the feature guarded by an explicit attribute?

I had no idea this was valid!

You can use the same with get_ and turn both into something you can pipe to as if it was functions, and replace few <-.

[charlesroddie]

this compromise will make the DU types harder to use in C#.

Reference DUs are fine to use in C# even without the Is properties, since instead of .IsCase1 you can use is DU.Case1.

Struct DUs are a different matter and look hard to use from C# in the general case.

[smoothdeveloper]

I have a somewhat strong opinion that the feature should only work if an attribute specific to this feature is added on the DU.

If this restriction cause a problem, it is possible to work around it with extension static members, and having this by default on DU comes with the drawback of making it too idiomatic F# code, removing a fair share of the "safety" feeling when pattern matching is used more pervasively.

Any one share that opinion? What are the motivations to not have this restriction?

[charlesroddie]

It has the drawback that F# and C# will continue to see different things, if there is no annotation.

[smoothdeveloper]

@charlesroddie so long C# doesn't exhaustiveness checks nor an easy way to pattern match on F# DUs, I think that drawback is fine (also applies to lots of other things in F#).

Do you feel needing an attribute on the type definition in order to make the members valid to use is a good restriction or that those members should be visible by default once the feature lands in the compiler?

[smoothdeveloper]

Comment from @dsyme on the original suggestion:

I don’t think the loss of purity (e.g. wr.t. ordering of union cases) is a critical problem and I believe you can turn of the DefaultAugmentation in any case

so loss of purity wasn't a concern (for me, it is reservation prompting me to propose a guard).

@dsyme, could you expand on how it could be turned off in context of this RFC and if the opt out should be the default rather than an opt-in attribute?

@Tarmil you authored the initial suggestion, do you have a take on that aspect of a guard attribute?

[dsyme]

Some comments on this

1. If a union has "private" representation, e.g.

   type Union = private | Foo of int | Bar of string

   then the IsFoo, IsBar etc properties are only available inside the member definitions associated with the type (just as the Foo, Bar
   constructors are only available there). There is no way to give individual private to each one, just as there is no way to give individual
   private to Foo and Bar.

2. 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.)

I'll add this to the RFC

[dsyme]

Some secondary thoughts on this

• Are we comfortable doing this if the union case doesn't begin with a capital alphabetic letter? e.g. RFC FS 1126 Allow lower-case DU cases when RequireQualifiedAccess is specified dotnet/fsharp#13432 .
• Are we comfortable with rename-refactor not working for this feature?

[smoothdeveloper]

I've started to see the feature show up in VS Preview, I feel the one odd thing is having the property available on single case DUs.

Are we considering this should be the case?

[T-Gro]

I noticed a little bit too late, so the preview has this :((. It is fixed in main.
dotnet/fsharp#16571

Firstly it is odd, but also it increased the surface area of IL-exposed members since those were not generated before either (testers for single-case unions).

[smoothdeveloper]

Good to hear and sorry I didn't notice after a bit of search.