Proposal Generic Attributes with constraints

[neurospeech]

Most of the time in registering dependency via attribute has no compile time error for registering wrong types. Let us consider..

   [DIGlobal(typeof(IEmailService))]
   public class SMSService: ISMSService{
   }

Lets assume that we are using Attribute DIGlobal to register dependency SMSService for service IEmailService.

What if there is a generic type called GenericAttribute<T>, which allows us to use generics in attributes.

 public class DIGlobalAttribute<TService,TOwner>: GenericAttribute<TOwner>
       where TOwner: TService
  {
  }

TOwner is the type on which GenericAttribute<TOwner> can be applied.

 // error... SMSService does not implement IEmailService
 [DIGlobal<IEmailService,>]
 public class SMSService: ISMSService{
 }

Note, TOwner does not need to be written in DIGlobal because TOwner is the class on which the attribute is declared. TOwner is the last type in generic parameters. Also TOwner is not specified while using using attribute because TOwner is the type on which attribute is applied. Here,
DIGlobal<IEmailService,> will substitute last generic attribute as DIGlobal<IEmailService,SMSService> automatically.

This isn't just limited to Dependency Injection but also in general registering attribute.

[yaakov-h]

To TOwner is implicitly whatever type (class or, I assume, interface) the attribute is applied to? I assume you then cannot apply a GenericAttribute<> to parameters, properties, etc.?

[Logerfo]

Duplicated #124

[neurospeech]

@yaakov-h yes

[neurospeech]

@Logerfo Difference from #124 is TOwner which is type restriction on where it can be applied.

[HaloFour]

You describe DIGlobalAttribute<TService,TOwner> but then use it as DIGlobalAttribute<T>. To the CLR those would be two distinct types and you wouldn't be able to omit one of the generic type arguments.

[neurospeech]

@HaloFour this is special case, TOwner is the type where this attribute is applied. Compiler will automatically substitute last TOwner as the same type where attribute is applied.

[jnm2]

@neurospeech That just won't work. I'd be in favor of DIGlobalAttribute<TService,> though. Or since @HaloFour will insist, DIGlobalAttribute<TService, *>.

[neurospeech]

@jnm2 skipping last generic parameter is only the case when attribute is applied, althought C# takes care of "Attribute" name as being optional, I think compiler can simply substitute class name as last parameter of generic argument list. I mean wrigint DIGlobal<TService,> , extra comma is ok, it does not hurt but it is kind of implicit here. Like how Func<T..., TRet> is implicit.

[jnm2]

@neurospeech The problem is that we need a convention to disambiguate between the two types DIGlobalAttribute<> and DIGlobalAttribute<,> if they both exist. Once we have that convention, it's much better to stick with it even if only DIGlobalAttribute<,> exists. It's more transparent to read and understand. And, if you ever do add a DIGlobalAttribute<> type, the meaning of your code won't silently change.

[neurospeech]

@jnm2 Ok, I am fine with DIGlobal<TService,> extra comma doesn't hurt, it is okay as long as there is a way to define attributes with generic constraints that will reduce half of debugging time dealing with DI and MEF and many other places.

[jnm2]

@neurospeech The other benefit is that potentially, you could choose to do either DIGlobalAttribute<TService,> or DIGlobalAttribute<,TService> if you preferred to switch the order of the type parameters for any reason.