You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I created some Extension-Methods in my Project so i could define new Conjunctions like these:
public static TConjunction AreNone<TConjunction, TRuleType>(
this GivenTypesThat<TConjunction, TRuleType> givenTypes)
where TConjunction : GivenTypesConjunction
where TRuleType : IType
=>
givenTypes.AreNot(ArchRuleDefinition.Types());
public static TConjunction AreConstructors<TConjunction, TRuleType>(
this GivenMembersThat<TConjunction, TRuleType> givenMembers)
where TConjunction : GivenMembersConjunction
where TRuleType : IMember
=>
givenMembers.HaveName(".ctor");
...
Sadly, after updating from 0.13.1 to 0.13.2 these Extensions are not working anymore, cause there is an issue with GivenTypesThat and GivenMembersThat, regarding their generics. My Compiler says, they would not use generics...
This may not be an issue, cause you may not intend the creation of extension methods for custom conjunctions, but i would like to know how i could adapt to your new version to use this option of creating my own conjunctions.
Hi @NielsApebs, in 0.13.2 the generic parameters of GivenTypesThat were removed, because the structure of the fluent syntax classes was improved. These extension methods could now be written as:
public static GivenTypesConjunction AreNone(this GivenTypesThat givenTypes)
=> givenTypes.AreNot(ArchRuleDefinition.Types());
I did not consider this a breaking change since it is non-breaking when using the library-provided fluent syntax or when using the FollowCustomPredicate fluent syntax and would need to think about whether we would want to consider this a breaking change. You can probably expect this to become stable for 1.0.
Activity
alexanderlinne commentedon Mar 2, 2026
Hi @NielsApebs, in 0.13.2 the generic parameters of
GivenTypesThatwere removed, because the structure of the fluent syntax classes was improved. These extension methods could now be written as:I did not consider this a breaking change since it is non-breaking when using the library-provided fluent syntax or when using the
FollowCustomPredicatefluent syntax and would need to think about whether we would want to consider this a breaking change. You can probably expect this to become stable for 1.0.