Idea / Feature

[94sedighi]

Idea / Feature

We have a bunch of Properties and Methods in PropertyInfoExtensions.cs, PropertyInfoSelector.cs, MethodInfoSelector.cs, TypeSelector.cs in pending PRs. We can easily use them to extend to following Assertions:

PropertyInfoAssertions.cs and PropertyInfoSelectorAssertions.cs with:

• [Not]BeAbstract()
• [Not]BeStatic()

TypeSelectorAssertions:cs with:

• [Not]BeAbstract()
• [Not]BeSealed()
• [Not]BeStructs()
• [Not]BeInterfaces()

MethodInfoSelector.cs with:

• [Not]BeAbstract()

Some other ideas would be:
PropertyInfoSelector.cs and MethodInfoSelector.cs with:

• ThatAre[Not]Overridable

What do you guys think?

[jnyrup]

As with PRs, please use an single issue per proposed API - but read the rest of this comment before you open six new issues.

This issue proposes 6 different kinds of APIs (abstract, static, sealed, structs, interfaces, overridable) which makes it harder to discuss (and eventually approve) each API separately.
If the proposals were split into separate issues, it will also be easier for you to come up with a more descriptive title than "Idea / Feature" which is, I'm sorry to say, unusable.

Also an API needs to "pull its own weight".
It means that we don't want to include everything in FluentAssertions just because "we can" or "it's easy to implement".
E.g. #1886 is a prime example of a proposed API that is both well-defined in terms of shape and implementation and don't have any edge cases, but we find the use-cases are so limited, so we're hesitant to approving it.
A better argument to add an API is, like I mentioned in #2054, if it brings consistency between our assertions, e.g. PropertyInfoSelector and MethodInfoSelector.

So a good API proposal needs to describe a use-cases and if possible what pitfalls/limitations there are.
E.g. in #2056 you're excluding decimal for the check if a Type is to be considered a struct.
I don't immediately know why that is, but it looks like a concern that could influence whether an API should be added and hence should be discussed in the issue instead of a PR.

Two examples of how to improve a proposal.
#1884 suggested to add BeDefined and listed two possible workarounds that he can use today.
#1886 describes in words a use-case for the proposed Implies and a code snippet of how to use it.

We will help with the exact shape of the API, but the proposer needs to do some of the work as well.