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

[KevinRansom]

Original opened at CodePlex by latkin

When defining CLI-standard extension members, per docs one is supposed to add [] 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.

comments
ovatsus wrote Jun 28, 2014 at 11:34 AM [x]
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 8:18 AM [x]
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 3:41 PM [x]
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.

[mexx]

I would vote for attaching the attributes automatically to the type and assembly.
Why bother the already overwhelmed programmer with more warnings?

More input:
As stated in the remarks section of ExtensionAttribute docs

If you are writing a compiler that supports extension methods, your compiler should emit this attribute on each extension method and on each class and assembly that contains one or more extension methods.

When our compiler supports extension methods, than we should do like the remark commands.
When not, we should do it to ease the life of the programmer.

[cartermp]

I will close this out in favor of https://github.com/fsharp/fslang-suggestions/issues/835, which has been approved