Why is TextWriter.Write(char) not abstract?

[habbes]

The virtual TextWriter.Write(char) method has default implementation that does nothing. I find this unintuitive and unexpected. It's possible to create a subclass of TextWriter that overrides Write(char[]) overload but not Write(char), such an implementation would be buggy because it would not properly handle calls to Write(char). The documentation does say that implementors must minimally implement TextWriter.Write(char), but wouldn't it be better to have the compile force you to do that by making it abstract? I think that would avoid unnecessary bugs.

[stephentoub]

It should have been abstract when it shipped over 20 years ago. Changing it now would be too breaking to be worthwhile.

[stephentoub]

What is the situation where you're hitting this? Analyzers aren't free, from either a development/maintenance perspective or from a run-time perspective of the time the build / IDE spends running them, so they need to be "worth it". :)

[colejohnson66]

An analyzer that flags not implementing Write(char). I’m not hitting this issue; Just suggesting a solution to the problem.

[habbes]

Hey thanks for the replies and apologies for my late response.

@stephentoub thanks for the clarification around the design and backwards compatibility concerns. I think an analyzer would be perfect. The scenario that caused to ask this question was a custom implementation of TextWriter that had overridden Write(char[]) but not Write(char). Since there was no warning or compiler error, this went on unnoticed for a while. Eventually we noticed incorrect output with some tests that called Write(char).

@colejohnson66 If we had an analyzer that flagged that we did not implement Write(char), that would have prevented the problem.

Alternatively, if the default implementation of Write(char) would call Write(char[]) instead of doing nothing, that would also work. This would be similar to the virtual Stream.WriteByte()'s default implementation which invokes Stream.Write(byte[]).

[gfoidl]

Since there was no warning or compiler error, this went on unnoticed for a while

Instead of an analyzer, which has cost to implement and maintain among others, unit tests could help for the custom TextWriter 😉 (I know, a "wonk answer" quite a lot won't like hear / read ...)

if the default implementation of Write(char) would call Write(char[]) instead of doing nothing, that would also work

What if existing code relies on Write(char) does nothing? That's the breaking change mentioned earlier, as that code would need adoption if such a change is done.

[habbes]

@gfoidl I understand changing the existing implementation of Write(char) would be a breaking change, I was just throwing it in there as a hypothetical.

As for the unit tests, the issue was caught by tests (luckily), but not by tests written specifically for that custom implementation of the TextWriter. The implementer did not test against Write(char) because they were not aware of that overload.

While one could argue that this a programmer error, I think it's more a design flaw than a programmer error because the language provides the (compile-time) tools to prevent against such mistakes (e.g. abstract methods). Since it's the expectation of the TextWriter that a *Write(char) actually writes a character (as the name implies), then it makes sense that someone who wants it to write nothing to be intentional about it by creating an override that does nothing. Since this path is not practical, I think a static analyzer is the next best thing.