[This post is part of a series, "wish-list for future versions of VB"]


IDEA: Allow you to override an event. This idea requires some explanation. Currently, both VB and C# allow you define events in interfaces, and implement them:

Interface I1

    Event e As Action

End Interface


Class DI : Implements I1

    Public Event e() Implements I1.e

End Class


However, VB does not allow you to declare a MustInherit class with an event; and if a library (e.g. WPF) has created such a class in C#, then VB doesn't let you inherit from that class:

MustInherit Class C2

    MustOverride Event e As Action  ' declaration disallowed in VB

End Class


Class D2 : Inherits C2

    Public Overrides Event e() As Action  ' overriding disallowed in VB

End Class


Finally, VB doesn't let you declare an overridable event, or override it. C# does let you declare the overridable event but it behaves incorrectly when you try to actually override it...

Class C3

    Overridable Event e As Action  ' declaration disallowed in VB

End Class


Class D3 : Inherits C3

    Public Overrides Event As Action  ' overriding disallowed in VB; buggy in C#

End Class


IDEA: We should allow users to inherit from MustInherit classes and override their MustOverride events.

This is a parity issue. Without this, VB users are simply unable to use classes such as System.Windows.Documents.Serialization.SerializationWriter (which is a MustInherit class with a MustOverride event). Note that this is entirely CLS-compliant. The only VB workaround is mock-type injection voodoo.

We could go further and allow declaration of MustInherit or Overridable events, and we could go even further and provide a correct consumption of "Overridable events". But these seem like much less important.


Provisional evaluation from VB team: The most important parity issues for us are ones where VB users are shut out from libraries that are usable by C# developers. This is one such case. We therefore think this is an important problem to fix.