Wanted: Framework support for disallowing multiple instances of aspects.

[tg73]

Given that aspects do not have to be attributes, AttributeUsageAttribute.AllowMultiple is not the whole story when it comes to disallowing multiple instances of an aspect on a definition. Even if an aspect derives Attribute, the aspect can be applied by means other than declarative application in source code - for example, via fabrics. When adding aspects programatically at compile-time, the Metalama framework will always allow multiple instances to be applied, and it's left to the user to defend against this. For example:

public override void BuildAspect( IAspectBuilder<IMethod> builder )
{
    if ( builder.AspectInstance.SecondaryInstances.Length > 0 )
    {
        builder.Diagnostics.Report( CachingDiagnosticDescriptors.Cache.ErrorMultipleInstancesOfCachedAttribute );
        return;
    }
    ...

Further, there does not appear to be a way to find useful information to report to the user so that they could fix the problem - for example, by detailing the origin of the aspects applied, both declaratively and programmatically.

From experience, I'd say that the majority of aspects are designed for single rather than multiple application. Developers may wrongly assume that AttributeUsageAttribute.AllowMultiple will be effective, and that aspects are single application by default. The framework should make this intent easy to express and enforce, and provide useful feedback to users so that unintended multiple application can be diagnosed and fixed.

[gfraiteur]

Thank you for the suggestion.

However, it is more complicated than it looks like.

From experience, I'd say that the majority of aspects are designed for single rather than multiple applications.

There are many practical cases where the current behavior is optimal. The current behavior is to define a priority order of instances, to execute only the instance with higher priority, and to expose the other instances under SecondaryInstances. This strategy is optimal when, for instance, one aspect instance is inherited, and another aspect instance overrides the inherited value -- and in this case, we should not report any error. The same is when an attribute overrides a value provided by an instance provided by a fabric.

So we would need to refine this suggestion and determine in which circumstances the current strategy is not optimal.

Note that the feature could also be implemented under the Metalama.Extensions namespace.