I'm really liking discriminated unions; unfortunately, I can't use them as often as I would like to since I intend my code to be used by other people using C# and other common .NET/DLR languages, and the output of discriminated unions isn't as self-documenting as a class and/or enum is.

Is it possible that in future versions, maybe in VS2010, the output code might be made a little easier to read?

Some thoughts given this code which I stole from Chris Smith:

type Suit =

| Diamonds

| Hearts

| Spades

| Clubs

type Card =

| ValueCard of int * Suit // Value 2 - 10 and Suit

| Jack of Suit

| Queen of Suit

| King of Suit

| Ace of Suit

| Joker

1. Are the get_uniq_ methods needed by consumers? Could these be hidden with [EditorBrowsable]? Reflector shows that the properties Clubs Diamonds etc. just call these methods.

2. This goes for publishing delegates as well, but I wish we had a way to name parameters. For instance, the ValueCard constructor has parameters called ValueCard1 and ValueCard2 -- which aren't very descriptive at all. It would be nice if in the definition of Card we could write something like | ValueCard of (rank:int)*(suit:Suit).

3. Could the Card.Jack(), Card.Queen() etc. be named Card.NewJack(), Card.NewQueen(), or maybe Card.Jack.New(), Card.Queen.New() respectively? This would seem to get rid of the underscores on the class names, which I think most C# developers find to be a bit unsightly.

4. This one's probably logistically impossible: if C# 4.0 switch could discriminate types, maybe the tag_s could be hidden as well. I can't remember if there's a performance hit to using the "is" keyword (which I presume would be how a switch on types would be implemented), but even if there were, I think there might not be too many scenarios where there would be tight loops spanning F# code and C# code.

5. Somewhat related to this, instances of Card end up having properties representing every value of every union. I think unlike F# devs, C# devs would prefer to just do typecasts than have a cluttered type definition in IntelliSense, even if it means writing a little more code.

I'm not sure these are the best solutions, but are there plans for any sort of improvements in this area?

Thanks,

Rei