F# 9 changes the validation of attribute usage targets for union cases.

[eiriktsarpalis]

I noticed the following regression when trying to build an old F# project using the .NET 9 sdk. The following code

open System.Runtime.Serialization

type CartEvent =
    | [<DataMember(Name = "cartCreated")>] CartCreated

now fails to compile with the error

error FS0842: This attribute is not valid for use on this language element

Technically, this error is correct because DataMemberAttribute specifies AttributeTarget.Field ||| AttributeTarget.Property however this is breaking a common pattern used when serializing events modelled as discriminated unions.

So I have the following questions:

1. Was this change made intentionally rectifying lack of attribute target validation by the compiler?
2. What attribute AttributeTarget should library authors be specifying for attributes intended for application to union cases?

cc @bartelink

[T-Gro]

This was done as part of fsharp/fslang-suggestions#1375 , via a series of changes implemented by @edgarfgp . It has been indeed intentional to rectify a prior lack of enforcement.

Unrestricted attribute would fit here best, but I assume that is not an option?
Due to the different lowering techniques for union types that are to be supported, I cannot think of a fixed one that would work well without edge cases.

[T-Gro]

Due to the lowering differences, the attribute targets are branched based on the numbers of fields:

if rfields.IsEmpty then AttributeTargets.Property else AttributeTargets.Method

[edgarfgp]

@eiriktsarpalis are you using 9.0.102 ? I do not seem to reproduce this for

open System.Runtime.Serialization

type CartEvent =
    | [<DataMember(Name = "cartCreated")>] CartCreated

1. Was this change made intentionally rectifying lack of attribute target validation by the compiler?

Yes

2. What attribute AttributeTarget should library authors be specifying for attributes intended for application to union cases?

open System

[<AttributeUsage(AttributeTargets.Property, AllowMultiple = false)>]
type PropertyOnlyAttribute() = 
  inherit Attribute()
  
[<AttributeUsage(AttributeTargets.Method, AllowMultiple = false)>]
type MethodOnlyAttribute() = 
  inherit Attribute()
  
[<AttributeUsage(AttributeTargets.Property ||| AttributeTargets.Method, AllowMultiple = false)>]
type PropertyAndMethodAttribute()
    = inherit Attribute()

type CartEvent =
    | [<PropertyOnly>] CartCreated
    | [<MethodOnly>] CartUpdated of int
    | [<PropertyAndMethod>] CartDeleted of int

[eiriktsarpalis]

Does the above workaround still result in the custom attribute being reported when I call UnionCaseInfo.GetCustomAttributes() for the relevant union case?

are you using 9.0.102 ?

Yes

[edgarfgp]

Does the above workaround still result in the custom attribute being reported when I call UnionCaseInfo.GetCustomAttributes() for the relevant union case?

I believe so. If you run

let a =
    typeof<CartEvent>
    |> FSharpType.GetUnionCases
    |> Array.map (fun x -> x.GetCustomAttributes())

You will get.

val a: obj array array =
  [|[|FSI_0007+ProperlyOnlyAttribute;
      Microsoft.FSharp.Core.CompilationMappingAttribute|];
    [|FSI_0007+MethodOnlyAttribute;
      Microsoft.FSharp.Core.CompilationMappingAttribute|];
    [|FSI_0007+PropertyAndMethodAttribute;
      Microsoft.FSharp.Core.CompilationMappingAttribute|]|]

[T-Gro]

Do we need a dedicated docs section about attributes on unions and their cases perharps?

[eiriktsarpalis]

While I get why each of the union case arities are mapped to Property and Method respectively, I don't necessarily think this would be intuitive to a library author or somebody consuming the attributes. I don't think there's a perfect solution here, but I can propose a couple alternatives:

1. Allow AttributeTarget.Type: while technically not all union cases a represented as types in IL, logically they are the closest concept corresponding to a union case.
2. Revert validation to pre F# 9 behavior. This should avoid breaking existing source code that applies [<DataMember>] attributes to union cases.

[T-Gro]

If DataMember is capable on support symbols beyond its attribute targets, wouldn't it then be possible to change it's declaration?

If there are libraries that do support invalid combinations of symbols and attribute targets, I think we could go with an opt-in way to trigger warnings instead of errors.

[eiriktsarpalis]

If DataMember is capable on support symbols beyond its attribute targets, wouldn't it then be possible to change it's declaration?

Types under System.Runtime.Serialization are considered legacy nowadays and we try not to make any changes to them. Apart from that though DataMemberAttribute is a type intended for use on properties and fields, so I doubt F# union cases would meet the bar for inclusion. The correct annotation should have been DataContractAttribute, although this is not allowed on union cases even with older versions of F#. It's been too long to remember exactly, but I suspect that might have been the reason that forced me to switch to DataMemberAttribute back in the day.

[T-Gro]

I don't want us to mix up two things when coming up with a solution:

• Staying as correct as possible for reflection-based-libraries which might not have any explicit F# support. But still, we can try to keep a correct mapping between AttributeTargets and emitted IL, at least where possible.

• Providing an annotation solution for libraries which are aware of the F# type system and are using e.g. Fsharp.Core reflection to work with it.

Allowing Target.Type could be helpful for the latter. But it also wouldn't solve the situation with DataMemberAttribute , would it?

[eiriktsarpalis]

But it also wouldn't solve the situation with DataMemberAttribute , would it?

It would not, but it's probably not the end of the world.