Compiler should warn on missing class-level or assembly-level [<ExtensionAttribute>]


When defining CLI-standard extension members, per docs one is supposed to add [<ExtensionAttribute>] to the member, its containing class, and the containing assembly.

It is easy to forget the class-level and (especially) the assembly-level attribute. Most F# code samples on this topic fail to include the assembly-level attribute. It would be nice if the F# compiler emitted a warning if it sees one or both of these is missing.

Motivation: When consuming extension methods from references assemblies, the old C# compiler had a bug where it didn't bother to check for the assembly-level ExtensionAttribute. That's why nobody remembers it! With the new Roslyn compilers, this is now enforced**. So it would be very useful for F# developers to be reminded when they are missing these.

** Sort of - we convinced them to special-case F# to preserve back-compat. Still, F# devs should start doing the right thing.


ovatsus wrote Jun 28, 2014 at 6:34 PM

If both the new and old C# compiler will still work without the assembly-level ExtensionAttribute, why force us to declare it? It's just more boilerplace. I know it's not correct according to spec, but for all practical reasons, the current behaviour is actually better

dsyme wrote Jun 30, 2014 at 3:18 PM

I think because the C# "fix" is a really a hack for F# assemblies, detected by libraries that reference FSharp.Core.

This is a crazy "what if" - but let's say in some future, long-distant iteration of F# we allowed people to optionally use a differently-named core library? For example, one where tuples and options were structs. That's not totally implausible, and people could probably even experiment with that today without too much trouble. But then suddenly the C# hack would stop working.

So I interpret the C# hack as saying "we confirm the need for ExtensionAttribute on assemblies, but are prepared to tolerate old F# asemblies". Like you I'd prefer they just dropped the need for ExtensionAttribute on assemblies, but we haven't convinced them of that.

latkin wrote Jul 3, 2014 at 10:41 PM

One would not be forced to do anything, it's a warning, not an error, and could be disabled if needed.

Although the C# compiler has a workaround (for now), the VB compiler will continue to ignore assemblies that do this incorrectly.