Runtime: BinaryReader should also accept String as path filename for contructor

[scls19fr]

Hello,

following same comparison of StreamWriter/StreamReader and BinaryWriter/BinaryReader exposed in dotnet/runtime#10642

I noticed that StreamReader can be construct with a String but not BinaryReader it will be nice to have a similar API ie also accept BinaryReader to be construct using String

Kind regards

https://github.com/dotnet/coreclr/blob/0fbd855e38bc3ec269479b5f6bf561dcfd67cbb6/src/System.Private.CoreLib/shared/System/IO/StreamReader.cs#L170

https://github.com/dotnet/coreclr/blob/26d4004e90f47036d6393222522cf529aa41c6bb/src/mscorlib/src/System/IO/BinaryReader.cs#L49

same for writer

https://github.com/dotnet/coreclr/blob/0fbd855e38bc3ec269479b5f6bf561dcfd67cbb6/src/System.Private.CoreLib/shared/System/IO/StreamWriter.cs#L132

https://github.com/dotnet/coreclr/blob/0fbd855e38bc3ec269479b5f6bf561dcfd67cbb6/src/System.Private.CoreLib/shared/System/IO/BinaryWriter.cs#L50

[AaronRobinsonMSFT]

@scls19fr What about creating a FileStream and then passing that into the BinaryReader/BinaryWriter. Wouldn't that work? Having knowledge of file semantics in the BinaryReader/BinaryWriter classes isn't ideal - which is why they take instances of Stream.

[scls19fr]

Why creating an additional object (FileStream) when you don't really need it. If you use a BinaryReader you will necessary need a stream with read file access. That should be implicit not explicit (or we should have an implicit way of doing)

[stephentoub]

Why creating an additional object (FileStream) when you don't really need it.

Are you talking about from a performance perspective? The implementation of StreamReader/Writer when provided with a path just construct a FileStream, so those constructors don't avoid that additional object.

That should be implicit not explicit (or we should have an implicit way of doing)

We actually wanted to remove those constructors from StreamReader/Writer in .NET Core, and did in 1.x; they were only added back in .NET Core 2.0 for compatibility.

I personally don't think it's worth adding such new overloads to BinaryReader/Writer in order to be able to write:
```C#
var reader = new BinaryReader(path);

instead of:
```C#
var reader = new BinaryReader(File.OpenRead(path));

Doesn't seem like there's enough benefit there.

[scls19fr]

My problem is about teaching VB.Net... not about performance issue.

[scls19fr]

It's a beginer course with very few time to spend... so the simpler it's, the better it is.

[stephentoub]

Sounds like a good opportunity then to teach about composability. :)