Create FS-1128-allow-static-members-in-interfaces.md

[gusty]

Click “Files changed” → “⋯” → “View file” for the rendered RFC.

[abelbraaksma]

A couple of questions, though some of them could be just logged, and answered later, I guess. I also think we need more concrete examples here, both from defining (multiple/single inheritance?) and consuming (how does the implementing syntax look?).

[abelbraaksma]

I think we need to define "properly compiled" here. Do we follow the C# approach? Can we pick details from their approach?

I also think we need to answer a bunch of questions (from the top of my head, not sure if everything needs to be answered):

• What happens when we inherit a static interface?
• How will default interop here?
• Are static properties allowed and how do we define get|set
• Are static indexers allowed?
• Can we combine with Abstract or does it have to be an Interface
• You use [<Interface>], I assume it also works with type TT = [...] interface end?
• How is implementing an interface with static members going to work?
• How do we deal with the standard of F# for explicit interfaces, is that relevant here?
• How is the diamond problem dealt with (it's different from normal interfaces, as we don't have an instance)?
• From all C# features on static interfaces, what parts are we going to support and what parts aren't we?
• Are all members public?
• How does the IL-compiled structure look like? (I assume we can link to C# here, there must be a design somewhere)
• If you implement an interface with both static and instance members in an object expression, do you need to implement the static members too? How does this extend the object expression syntax?
• We should also ensure that signature files understand the new syntax and if we generate an fsi file, that it includes these new types.

[gusty]

Do we follow the C# approach?

Absolutely, I don't see any need to diverge from them and on the contrary, doing so can be problematic.

Can we pick details from their approach?

Sure, below most answers are based on existing situation. The goal here is to allow them to be written in F#, not to change anything, therefore we'll keep existing behavior.

What happens when we inherit a static interface?

Right now nothing happens when inheriting an interface with a static member => we'll keep this existing behavior.

How will default interop here?

Right now, existing interfaces with static fields can be used to parameterize default implementations for non-static members, but in F# we can't write default implementations => we'll keep this existing behavior.

Are static properties allowed and how do we define get|set

Right now they are allowed in C#. For F# it's better to re-use the same syntax as for Abstract Classes.

Are static indexers allowed?

Right now AFAIK they are not allowed => we'll keep this existing behavior.

Can we combine with Abstract or does it have to be an Interface

Right now Abstracts can have static members => we'll keep this existing behavior.

You use [], I assume it also works with type TT = [...] interface end?

Yes, I don't see a reason why it shouldn't be allowed.

How is implementing an interface with static members going to work?

Right now nothing changes whether it has static members or not => we'll keep this existing behavior.

How do we deal with the standard of F# for explicit interfaces, is that relevant here?

IMHO it's not relevant, as soon as we have an instance (which we can eventually auto-upcast or not) we're talking about instance members, not statics and since that's the current behavior => we'll keep this existing behavior.

How is the diamond problem dealt with (it's different from normal interfaces, as we don't have an instance)?

Right now it's not dealt, there is no such problem as all calls have to be explicit Interface.method => we'll keep this existing behavior.

From all C# features on static interfaces, what parts are we going to support and what parts aren't we?

All, we support the same features, let's not restrict anything.

Are all members public?

Right now they can be either public or privates => we'll keep this existing behavior.

How does the IL-compiled structure look like? (I assume we can link to C# here, there must be a design somewhere)

Yes, same as C# it looks like this => we'll keep this existing behavior.

If you implement an interface with both static and instance members in an object expression, do you need to implement the static members too? How does this extend the object expression syntax?

Right now you don't need to do anything as they can't be inherited => we'll keep this existing behavior.

We should also ensure that signature files understand the new syntax and if we generate an fsi file, that it includes these new types.

Sure, we need to ensure that.

[dsyme]

Could you add all these questions and resolutions to the RFC please?

[dsyme]

I think we could then merge this RFC

[gusty]

Done !

[dsyme]

@gusty Thanks for this! Note also the similarity with dotnet/fsharp#14132, the RFC for that is TBD

[gusty]

I see, maybe both RFCs can be implemented in that PR.