Inherit thread affinity from base types and members

[sharwell]

• Types derived from a type that requires the main thread should also have a main thread requirement
• Members derived from a member that requires the main thread should also have a main thread requirement

Then as a follow-up to the above:

• Members which have a main thread requirement due to inheritance should not report a warning if they are missing a ThrowIfNotOnUIThread call

[AArnott]

Members derived from a member that requires the main thread should also have a main thread requirement

By a derived member are you talking about an override member?

Members which have a main thread requirement due to inheritance should not report a warning if they are missing a ThrowIfNotOnUIThread call

I disagree. There is no guarantee that the caller has the threading analyzers applied to their project with the right analyzer turned to warning/error. At runtime something that requires the UI thread should still throw if it's not called on the UI thread in order to prefer throwing exceptions over deadlocking.

[sharwell]

By a derived member are you talking about an override member?

• override: Yes
• Explicit interface implementation: Yes
• Implicit interface implementation: Probably, but could be persuaded otherwise and may not be necessary. Biggest advantage would be code implementing an interface provided by some service, where the service only ever calls into the interface from the UI thread. By marking the interface and having it propagate to implementations, the analyzer could assume the entry point to each method in the implementation is on the UI thread.

[sharwell]

I disagree. There is no guarantee that the caller has the threading analyzers applied to their project with the right analyzer turned to warning/error. At runtime something that requires the UI thread should still throw if it's not called on the UI thread in order to prefer throwing exceptions over deadlocking.

This is fine, but if the behavior is kept it should use a different diagnostic ID. Otherwise it's an overwhelming source of noise for code that defines hundreds or thousands of event handlers for UI events.

[AArnott]

Event handlers I don't mind removing the requirement from under the conditions you proposed. It's members that are accessible in other ways that I think should still defend themselves from improper calling.

[sharwell]

That seems more relevant for a library or application with a public API. For a contained application, it's just noise (all the entry points to affinitized code would be analyzed separately).