Override Stream.ReadByte/WriteByte

[terrajobst]

The rule should flag types derived from Stream that don't override ReadByte or WriteByte.

Category: Performance

[jeffhandley]

Estimates:

• Analyzer: Small
• Fixer: Medium

[stephentoub]

Fixer: Medium

I don't think there's anything meaningful a fixer could do here

[carlossanlop]

This analyzer is related to #33789 . Let's consider adding this case to that one, instead of creating a new analyzer.

And just like in #33789, we should scope this to only types that are directly derived from Stream (and not a derived type).

• Suggested severity: Info
• Suggested milestone: Future
• Suggested category: Performance
• No fixer: VS already offers the option "Generate overrides", and the user can then select to override ReadByte and WriteByte:
  

[bartonjs]

Video

Knowing to override ReadByte and WriteByte is something that would show up in a performance analysis, and a performance-improvements focus would likely have already highlighted it.

Without usage on a specific Stream-derived type saying that ReadByte/WriteByte were even called, this is too low value considering the already high cost of implementing a Stream "properly", and so doesn't seem justified.

The group got sidetracked by theorizing about a DelgatingStream : Stream type and a new intermediate Stream type that rewrites everything in terms of fewer protected abstract methods focused on Span/Memory... but that's not really what this issue was about.