Type-mismatched [<DefaultParameterValue>] is not ignored enough

[IS4Code]

There is an inconsistency in how an incorrect placement of [<DefaultParameterValue>] is handled. Usually, in most situations, the parameter is simply not treated as optional at all, but if it is of type obj, it seems it is still considered optional.

Repro steps

open System.Runtime.InteropServices

type C =
  static member Foo([<Optional>][<DefaultParameterValue("hello")>] obj: obj) =
    printfn "%A" obj

C.Foo()

Expected behavior

C.Foo() should fail to compile, since the attribute has mismatched type and thus even [<Optional>] is ignored.

Actual behavior

The code compiles and passes null to Foo, in contrary to the warning:

FS3211 The default value does not have the same type as the argument. The DefaultParameterValue attribute and any Optional attribute will be ignored. Note: 'null' needs to be annotated with the correct type, e.g. 'DefaultParameterValue(null:obj)'.

Known workarounds

Providing a different type than obj (as far as I can tell) correctly stops the code from being compilable at all.

Related information

Environment: https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAOgCUBXJbASzwQIElyEAneNJgNwoGMEIBYAKAHYMiFAGEUAXgEoUOAIaVOKangBGTFADEYMABQBtADwB5OJRhJ5wAHwBdYwBEEYeSWDYACvMbzquRgA1axIEPQAiAAsEYGAYcIBKexQYNQArEBT0hKkZWRQ4RgpyMFRwgFIAQXCstIEBMQIdfQSgA=

[T-Gro]

It should behave as if using any other mismatched type annotation, indeed.

[T-Gro]

Figured out what is happening - the method is indeed typechecked as one without optional arguments, but the C.Foo() call is interpreted as passing Unit to C.Foo. Which satisfies being an obj, and is emited as null at runtime.

I will check if there are some places which intentionally relly on having a Unit passed, cannot imagine any right now.

[T-Gro]

If you remove the attributes, it stops producing the FS3211 warning, and the code still runs - treating () as an argument which fits obj.

[IS4Code]

Ah, the optional parameter was a red herring then. Thank you for investigating this!

Do you know of a way that would make C.Foo() (or some other call syntax) fail to compile in this case? The call now makes sense to me based on F# rules, but it might be confusing and could cause bugs when overloads are changed. I suppose with --checknulls+ there would be at least a warning, but still with obj | null one might not want to include unit into the set of accepted argument types.

Otherwise we can close this.

[T-Gro]

I will check if we couldn't expand the warnings on implicit conversions.
In this case, the conversion is from Unit to obj.

I am certain there will be hypothetical use cases for which a full error would be a breaking change, but I believe a warning should be acceptable.