Greatest Common SubType Inference + Array Literal

[AdamSpeight2008]

If you look at the object graph below you can see that TextRule inherits RuleDef

So it would be logical sense the when using on in an array literal with other RuleDef's that the inferred type of the array should be RuleDef() but on examination the declared type is Object().

WIth Option Strict On we get the warning message.
Cannot infer an element type, and Option Strict On does not allow 'Object' to be assumed. Specifying the type of the array might correct this error.

The extension method on the type string just create instances of the RuleDef

   <Extension>
    Public Function AsRef(s As String) As Rules.RuleRef
        Return New RuleRef(New RuleName(s))
    End Function
    <Extension>
    Public Function AsText(s As String) As Rules.TextRule
        Return New Rules.TextRule(s)
    End Function
    <Extension>
    Public Function AsAlt(a() As Rules.RuleDefinition) As Alternatives
        Return New Alternatives(a)
    End Function

But if I use a the exact same form of the array literal being used as the first argument of the exact same function. Except that in one we use is as as extension method the other not.

        Dim a0 = ({"IL_Header".AsRef, "HEX_4".AsRef, ": ".AsText }).AsAlt
        Dim a1 = RuleDef_Exts.AsAlt({"IL_Header".AsRef, "HEX_4".AsRef, ": ".AsText})

The first has an error, the second does not.
My expectation is for both to mean the same.

So this behaviour suggest that type-inference isn't correctly inferring the greatest common subtype for the array literal. In which the exampe would be RuleDef, Same behaviour exists with VS2013 version of VB.net. I shouldn't have to specify the type when it could be be inferred.

[dsaf]

C# has the same problem #1419. It's not just arrays by the way, also there is potential ambiguity in the presence of interfaces and nullability. I hope having VB.NET devs wanting same feature will increase the likelihood of it getting implemented :).

[gafter]

Why doesn't VB already do this

There was an explicit decision to have the VB compiler, in type inference, only produce types that were input to the inference process. The reason is that expanding the type inference to other types can result in very complex and nonintuitive results. See, for example, a stackoverflow question about infinite types in Java that result from type inference. It is all well and good to say that we should generalize the common-supertype computation, but actually doing so in practice - in a way that is intuitive to users - is very hard. We would need a specific concrete proposal (not just a list of options) along with a prototype to play with in order to move this kind of proposal forward. If the proposal includes special cases like "if there happens to be only a single common interface..." then it is unlikely to be seen as a good solution, as it will be fragile in the face of adding an interface to an existing class - a kind of fragility we like to avoid. I suspect any solution would require adding the concept of intersection types ala Java.

Any solution for C# would likely be applied equally to VB, so we're treating #1419 as covering both languages. Thus I am closing this issue as a duplicate.