Add "Make .Is* discriminated union properties visible from F#"

[Tarmil]

No description provided.

[cartermp]

These are more suggestions than anything else

[cartermp]

Also might be worth mentioning that existing DUs that define IsXX members won't compile today, so this is safe from that perspective.

[Tarmil]

Also might be worth mentioning that existing DUs that define IsXX members won't compile today, so this is safe from that perspective.

It is mentioned in Compatibility / Is this a breaking change?

[cartermp]

Almost there. This will need a snippet describing compatibility with the existing Is* members you have access to on the Option<'T> and ValueOption<'T> types.

[cartermp]

This isn't true for Option<'T> or ValueOption<'T>. See here.

[Tarmil]

Option<'T> is easy: IsSome and IsNone are already visible, so there is no change.

For ValueOption<'T>, there are also visible IsSome and IsNone, in addition to the hidden IsValueSome and IsValueNone. So there are two possible routes:

• make them visible (which makes them redundant with the existing IsSome/IsNone)
• keep them hidden (which makes ValueOption<'T> unique among all union types for not having Is{{UnionCaseName}} properties)

I think I'm in favor of the former, for consistency. Plus it's probably simpler to implement than making an exception.

[abelbraaksma]

I assume we can't remove the existing IsSome/None, but adding IsValueSome/None would effectively make them aliases of the former, in which they would then probably be unique in our ecosystem.

It's a tough call. For parity you would like to have them, but different members that do the exact same thing brings confusion, and unless the tooltip would clearly describe that they are synonyms, I'm afraid programmers will have to research what the differences are and you'll end up answering questions similar to whether String or string has better performance / should be preferred / has different semantics etc.

Of course, the answers will be simple, they're equal, but I think it's better to prevent the questions rising in the first place.

But then there's the argument of parity, auto generated code, predictability, orthogonality etc. It's a tough call ;).

[Tarmil]

I'm not sure what the exact stance on obsoleting API is, but it could be acceptable to mark the existing ValueOption IsSome/IsNone properties [<Obsolete>] to reduce confusion.

[cartermp]

@Tarmil I think your preference here is spot on: hiding IsValueSome/IsValueNone for ValueOption. Can you make a note of that in the RFC?

[abelbraaksma]

I like the RFC, it's quite clear I think, but I do have a few general remarks / requests:

• should we add a discussion thread for the RFC, as many other RFC's have, as opposed to just the original feature request?
• what to do about exposure to null? That is, if Foo.IsCase is a property, x.IsCase could have x point to null. Not in F#, but if the property is exposed to, say, C# from F#. Do we consider that an acceptable NRE, or should we do something else? Would the property also work on DU's where null is a true value (like with IsNone)?
• The texts talks about compiler-generated properties, but don't we already have them and don't they simply need to be exposed instead?
• I'm a bit fuzzy about the section on Alternatives, sounds much to me like an unresolved issue: do we, or don't we expose Tag in some or more ways? And I think it is already exposed to C# anyway.
• The proposal talks about nested types, but this feels a bit odd, considering that F# does not allow creation of nested types (but I don't have a better alternative).
• There's mention that conflicts won't arise. I agree, but it might be good to mention that extension properties may exist, or other bindings with the same name and module/type (but not instance members). Current rules could potentially break such code, because extension members come last in resolution. Not a big thing and I don't know if it exists in the wild, but we might want to point it out.

[dsyme]

The "natural" way of implementing this is to generate the Is/Tag properties earlier (into the TAST) rather than in IlxGen.fs. I don't think this technique causes any compat problems but this should be considered when reviewing the implementation.