Compiler ignores obsolete attribute for enum cases.

[dbarbashov]

When enum case marked with [<Obsolete>], compiler doesn't give warning.
Even with [<Obsolete("Hello, world!", true)>] it still compiles.

Repro steps

1. Make enum

2. Tag some case with [<Obsolete>] attribute

3. Try use it somewhere

Example script:

open System

type MyDU =
    | Case1
    | [<Obsolete>] Case2
    
let xx = MyDU.Case2 // <- gives warning

type MyEnum =
    | Case3 = 0
    | [<Obsolete>] Case4 = 1
    
let yy = MyEnum.Case4 // <- no warning 

printfn "%A %A" xx yy 

Expected behavior

When enum case is marked as obsolete, compiler should give warning or error depending on Obsolete attribute configuration

Actual behavior

No compiler warning or error

Related information

OS: Ubuntu 16.04

$ dotnet --version
2.2.203

dotnet fsi output:

Microsoft (R) F# Interactive version 10.4.0 for F# 4.6
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> open System

type MyDU =
    | Case1
    | [<Obsolete>] Case2
    
let xx = MyDU.Case2

type MyEnum =
    | Case3 = 0
    | [<Obsolete("hello, world!", true)>] Case4 = 1
    
let yy = MyEnum.Case4

printfn "%A %A" xx yy ;;

  let xx = MyDU.Case2
  ---------^^^^^^^^^^

/home/lkmfwe/stdin(7,10): warning FS0044: This construct is deprecated

Case2 Case4
type MyDU =
  | Case1
  | Case2
val xx : MyDU = Case2
type MyEnum =
  | Case3 = 0
  | Case4 = 1
val yy : MyEnum = Case4
val it : unit = ()

[cartermp]

I could see this being a bug, though pattern matching on an enum makes this more challenging since we emit a warning unless you also have a discard case (or exhaustively pattern match on all 2 billion possible integers). So you'd still be writing code that can accept an obsolete value. The same goes for DUs though, so I guess that wouldn't be so bad.

Note that making a DU case obsolete and not using a discard case in pattern matching is problematic, since you will then have to either ignore incomplete pattern match warnings or ignore the obsolete warning on a pattern match, due to exhaustiveness.

[charlesroddie]

Warning on creation of obsolete instances will solve this issue, and pattern matching doesn't need adjusting.

pattern matching on an enum makes this more challenging since we emit a warning unless you also have a discard case

Warning on creation doesn't affect the default requirement of having a discard case on pattern matching.

Note that making a DU case obsolete and not using a discard case in pattern matching is problematic

You can avoid using a discard case by disabling FS0104 Enums may take values outside known cases (after #4522). But you still have to match obsolete ones because they give the "stronger" FS0025 Incomplete pattern matches. I believe this is correct because obsolete cases should be accounted for until they are deleted.

[Tarmil]

For reference, here is C#'s behavior. It does show a warning:

• when creating an instance using an obsolete enum case.

• when matching against an obsolete enum case using a switch statement.

• when matching against an obsolete enum case using a switch expression.

Switch expressions are interesting because unlike switch statements, they do check for exhaustiveness. However they do not have the distinction between FS0025 and FS0104, so they don't have the added value of matching against obsolete cases in this regard.

I think that we should actually distinguish two situations:

1. There is another non-obsolete case that has the same value as the obsolete case. This means that the obsolescence really is just a rename. In this case, pattern matching should show a warning, since it is still possible to obtain a FS0104 by using the renamed case.

2. There are no non-obsolete cases that have the same value as the obsolete case. This means that the obsolescence is an actual feature removal. In this case, pattern matching should not show a warning, since it is impossible to obtain a FS0104 without matching against the obsolete case.