Nullability of StreamReader and StreamWriter encoding parameter is not consistent

[jnm2]

❌ StreamReader(Stream, Encoding) does not throw when null is passed

❌ StreamReader(Stream, Encoding, bool) does not throw when null is passed

❌ StreamReader(Stream, Encoding, bool, int) does not throw when null is passed

✔ StreamReader(Stream, Encoding?, bool, int, bool) does not throw when null is passed

---

❌ StreamWriter(Stream, Encoding) does not throw when null is passed

❌ StreamWriter(Stream, Encoding, int) does not throw when null is passed

✔ StreamWriter(Stream, Encoding?, int, bool) does not throw when null is passed

[stephentoub]

The overloads where you have an X next to them historically have thrown when Encoding is null, and still do on .NET Framework. It was only recently changed for .NET Core, in dotnet/coreclr#24056, specifically because of a desire to have optional arguments.

We should probably change the other Encoding arguments to be nullable as well.

[stephentoub]

That said, it's strange that we allow null for Encoding with the Stream-based constructors but not with the string-based constructors.

@JeremyKuhne, what's the rhyme/reason for that?

[jnm2]

The overloads where you have an X next to them historically have thrown when Encoding is null, and still do on .NET Framework.

The overload without an X throws on .NET Framework also.

[stephentoub]

The overload without an X throws on .NET Framework also.

I understand that; I was commenting on the ones that are currently specified to take Encoding rather than Encoding?.

[JeremyKuhne]

it's strange that we allow null for Encoding with the Stream-based constructors but not with the string-based constructors.

what's the rhyme/reason for that?

Oversight, really. The original issue was targeting leaveOpen which has no meaning for the path constructors. I agree that we should be consistent with the path constructors and Encoding. @carlossanlop, any thoughts?