Provide a way to opt-out of structural typing.

[tannergooding]

Issue

Today there exist many cases where the language will allow some feature or functionality based on structural typing. Some examples are:

• foreach where the type implements a GetEnumerator extension
• Dispose on ref structs if a Dispose method exists
• Index patterns if a this[int index] and int Count { get; } or int Length { get; } properties exist
• etc

Give the diversity across the entire ecosystem and the possibility for domain specific terminology, this means there may be cases where a member exposed may conflict with the language assumptions about a given "shape".

Example

One such example is that in the space of numerics and euclidean vectors a common term is "length". This is sometimes also referred to as magnitude or norm, but length remains the most common domain terminology. Being vectors of n dimensions, they are also frequently indexable and thus, an integer based euclidean vector may be applicable for indexing or list patterns, despite the exposed Length being the wrong term and thus leading to potential bugs or issues.

There can be various other considerations here as well, such as Length being preferenced over Count when the user, for various reasons, may want the inverse.

Proposed Solution

There should be a way to opt-out a member or set of members from participating in structual based typing. One can imagine multiple scenarios for this ranging from a single big switch saying a type or member doesn't participate in any structural typing to more fine grained switches that indicate the type or member does not participate in a given scenario of structural typing (e.g. Length doesn't represent the language concept of "collection length").

With such a switch or set of switches, the compiler could also produce a more explicit error message indicating the type has been opted out of the given pattern.

[Richiban]

I get where you're coming from here, but what actual problem does this cause? What dangers are there and, if any, how likely are they to actually occur?

[Richiban]

Apologies if I'm slow to pick this up, but if a Vector is loosely defined as a collection of n elements then why shouldn't I be able to deconstruct it as a list?

When I read your first proposal I assumed that the Length property referred to the distance from the origin to the termination point of the Vector (such as in a Vector2D), which doesn't make sense really because that property is probably not going to be an int.

[Richiban]

Wait, I think I've answered my own question; one might want to define a VectorND type, in which case Length might be construed to be the number of dimensions instead of the magnitude of the Vector in space. Now I understand the potential confusion

[tannergooding]

Right, Length in the terms of a Euclidean vector is generally the magnitude (or norm) of the vector (basically its distance from zero). Where-as C# is assuming Length here means "number of elements in the collection".

If you have some Vector<T>, then its common for the property to be T Length (and not always some floating-point type) and you simply accept that the result may get truncated/rounded (e.g. if the actual length would be 1.34, you'll get 1 as the result).

• This is very common in user interfaces since you pixels are generally only addressable in terms of whole integers (sub-pixel rendering is generally just more advanced algorithms partially blending neighboring pixels; still using integer based indexing overall)

Length will get used here because its the "de facto" domain terminology used by most major libraries, irrespective of it being potentially confusing with regards to Length throughout the rest of the ecosystem.

• Domain specific terminology generally wins out over potential confusion with the rest of the ecosystem; because its often used by people who are working in that given domain and so its less confusing to them, overall

[HaloFour]

Has this come up in scenarios other than slicing? Is there a legit implementation of an indexer that accepts an Index/Range that could be implemented on those types to short-circuit the C# pattern-based logic?

Even so, it doesn't sound like a terribly bad idea to have an attribute that can disable the pattern, but it doesn't sound like it would come up in many other scenarios.

[tannergooding]

Has this come up in scenarios other than slicing?

Not that I'm aware of, but it is a general concern as the language adds more types of structural based patterns and looks at ways they could be provided in the future (such as "shapes").

Is there a legit implementation of an indexer that accepts an Index/Range that could be implemented on those types to short-circuit the C# pattern-based logic?

In this particular case, yes.

[huoyaoyuan]

It could be better if those features are marked by interface instead of structural typing from the start.

I think an attribute with scope of member/type/module can be used for marking that without introducing large overhead.

[hez2010]

Structural typing is always a workaround of lacking of type trait (shape). It's necessary to remove structural typing after adding shape to C#.

[tannergooding]

The language doesn't make breaking changes like that. The existing structural typing support will likely be here to stay even after the language looks at providing other nominal typing based features.

All of this functionality is already definable nominally today (simply using interfaces); there just isn't a way to implement some interface via "extension" for a type you don't own nor is there a built-in contract for it.
Likewise, there currently exist certain places (such as ref structs) where using interfaces or generics isn't possible.

[OJacot-Descombes]

We could give hints with attributes at type level. In the example of Vector2<T>, we could either opt out with a NonCountableAttribute or opt in with a CountableAttribute having a int fixedLength parameter. This “opt in” would work even if there is no Length or Count property. If there is such a property it would be ignored.

[mikechristiansenvae]

Perhaps a CountPropertyAttribute?

[CountProperty(nameof(Count))]
public struct Vector2<T>
{
    public T X { get; }
    public T Y { get; }
    public T Length => throw new NotImplementedException("Calculate the Magnitude");
    public T Count => 2;
}

Edit: Possibly also be able to opt-out:

[CountProperty(OptOut = true)]
public struct Vector2<T>
{
    public T X { get; }
    public T Y { get; }
    public T Length => throw new NotImplementedException("Calculate the Magnitude");
}

[Rekkonnect]

Whenever roles/extensions come in, to handle this scenario we would need some way for a type to mark itself as excluded from specific roles, should they happen to meet the structure, like:

// Assume the following role
role RCountable
{
    public int Count { get; }
}

public struct Vector2<T>
    neglect RCountable
{
    public T X { get; }
    public T Y { get; }
    public int Count => 2;
}

[HaloFour]

Given extensions would apply to types without the type even knowing that it exists, I would think that the relationship would be the other way around, in that the extension would declare that it would not work for specific types. That said, the majority of the type I would expect that the type and extension both know nothing about each other, so expecting either to opt out of the other doesn't feel like it would be particularly helpful.

[theunrepentantgeek]

If the behaviour of Vector2<T>.Count doesn't match the semantics expected by the role RCountable, then any code that tries to use it will come up with nonsense results, regardless of whether the syntax happens to line up.

I think it's very much like the way structural typing works in other tech stacks (e.g. TypeScript, Go, etc) - there's a theoretical issue where types that happen to be syntactically valid can be used, but in practical terms it's never a problem because the behaviour is wrong.

[CyrusNajmabadi]

I'd recommend just writing an analyzer for this. That's the best answer for when you want to layer additional domain specific restrictions on your code.

[tannergooding]

Analyzers are great, but they also aren't free or necessarily as integrated.

The main concern I have tends to be that the Roslyn API surface doesn't expose all the details and there's frequently things missed, even in the dotnet/roslyn-analyzers codebase (where we have experts from the .NET team writing these analyzers). This is especially true as new language features come out or the compiler decides to start optimizing new patterns.

As Roslyn continues exposing features that are based around structural typing, I think this is particularly relevant as it will lead to an increase in bugs, particularly in some of these common domains or even edge cases in well known types from the BCL. I really think this is one of those cases where an analyzer is simply not sufficient and where there really needs to be an attribute that Roslyn recognizes which will opt a particular assembly, type, or member out of consideration for structural typing.

[RenderMichael]

This would be useful with ImmutableArray’s Add method. I know it’s a breaking change but using it with object initialization is always a bug, and hopefully the runtime team could consider such a breaking change.

[CyrusNajmabadi]

The best way to opt out of anything is to just write an analyzer. That's what they're there for.