Suspected bug when reporting on duplicate (equivalent) - generic type declarations.

[Korporal]

The following - illegal - code generates CS0264:

    public class A<T> 
    {

    }

    public class A<X>
    {

    }

This seems wrong to me since clearly there is no use of partial here.

[CyrusNajmabadi]

This is an example of a cascading error. The first error is the lack of 'partial'. The language requires that if there are two source types with the same name and same arity in a namespace.

At that point though, the program is in error and we the compiler can decide whatever it wants in terms of how to interpret things and how to proceed.

Here, we have chosen to interpret this as the user accidentally forgetting 'partial', and we take the interpretation that the types are actually partially and are merged together. This of course can lead to further errors (as can not merging them).

As strategies go, this serves us better than the opposite approach and leads to less false errors and more true ones.

The overall strategy is not a bug. That said, you could argue that errors/warnings related to 'partial correctness' (such as the message about the type parameter names) should not be issued if not all parts have the partial modifier. I don't think we'd have a problem taking a PR to make sucha change, provided it was lightweight in scope.

[Korporal]

The following elicits only CS0101

    public class A 
    {

    }

    public class A
    {

    }

as does

    public class A<T> 
    {

    }

    public class A<T>
    {

    }

This seems inconsistent with your explanation, why assume a partial is missing in the first example yet not assume that also in these other two examples?

[CyrusNajmabadi]

We assume partial is missing in all these cases listed. You can see that trivially with by expanding your examples. For example:

using System;

public class A
{
    private int X;
}

public class A
{
    void M()
    {
        Console.WriteLine(this.X);
    }
}

This issues no error about a reference to a non-existent definition 'X' because we interpret the above as being one type with two parts.

[CyrusNajmabadi]

This seems inconsistent with your explanation

It is not. In each case we assume these were intended to be partials, just that the user forgot to have the 'partial' modifier on them. That assumptions leads to some positive outcomes (like not erroring on this.X in the example above i provided). But it can also lead to negative outcomes (such as doing specific checks around partial types and producing specific warnings/errors to that scenario). We believe the positive results of this change outweigh the negatives.

[CyrusNajmabadi]

Also, as per my first response, this is an example of error tolerance strategy. In general we want to provide reasonable resilience to errors, producing less errant subsequent errors/warnings vs more. However, error recovery can always be tweaked if it has negative outcomes and the cost to address that is low. If you want to submit a change here such that these particular cascading diagnostics are suppressed unless partial is present on all parts, i think that would be acceptable (provided the change was suitably sized).

[CyrusNajmabadi]

If you would like to discuss such a PR more, i'd be happy to take this to gitter or discord to advise on how best to approach it. Thanks!

[Korporal]

This is confusing, if we assume these are two declarations each missing the partial keyword then there's surely no need to report a duplicate because that assumption eliminates it.

    public class A 
    {

    }

    public class A
    {

    }

If the analysis is that the user has left out a partial then surely mentioning that in the diagnostic message would be helpful?

The error reported is The namespace 'whatever' already contains a definition for 'A' not Multiple declarations for the same type within a namespace require the partial keyword be used on each one.

If the latter is what the analysis thinks the problem is, why not tell the user that? that seems like a better diagnostic message and could be consistently reported in each of the three cases.

It's simply the diagnostic that I think should be changed, not the analysis, anyway that's how it looks to me, do with it what you wish.

[CyrusNajmabadi]

then there's surely no need to report a duplicate because that assumption eliminates it.

The issue is that there's a duplicate. So we report that Our error recovery strategy is then to guys at what you meant and continue from there.

This is confusing,

As stated a couple of times already. We would accept reasonably sized PRs that improve the clarity of error recovery and any effected diagnostics past that point.

do with it what you wish.

If you find this situation confusing, we would welcome your assistance in improving it. As mentioned, I'm happy to work with you on gitter or discord to make a PR to improve the situation here.

All I was trying to do above was explain what error recovery was doing and why it led to the messages you're seeing.

[Korporal]

While we're here is there a reason why this is not allowed?

    public class Generic<T> where T : class
    {

    }

    public class Generic<T> where T : struct
    {

    }

It seems these are distinguishable and there's no prospect of ambiguity, so I am curious, in each of these cases we know more than just the lexical identifier of each generic arg, there is further metadata available to distinguish between them, seems the detection of duplicate generic signatures is disregarding that metadata.

[CyrusNajmabadi]

The runtime does not support overloading generics on constraints. The language could allow this, but would need something sensible to compile down to. We don't see there being any reasonable compilation strategy that would meet all our goals.

[Korporal]

then there's surely no need to report a duplicate because that assumption eliminates it.

The issue is that there's a duplicate. So we report that Our error recovery strategy is then to guys at what you meant and continue from there.

This is confusing,

As stated a couple of times already. We would accept reasonably sized PRs that improve the clarity of error recovery and any effected diagnostics past that point.

do with it what you wish.

If you find this situation confusing, we would welcome your assistance in improving it. As mentioned, I'm happy to work with you on gitter or discord to make a PR to improve the situation here.

All I was trying to do above was explain what error recovery was doing and why it led to the messages you're seeing.

Understood and thank you, I will see if I can suggest something practical here, thanks for your comments.