Stream related constants for default constructor parameters should be public

[scottdorman]

The Stream classes have various constants that define default values (for things like the default buffer size) which are either internal or private. These should become public so they can be referenced by calling code (to provide the proper defaults when having to use some of the various constructor overloads).

In addition, there are a few defaults used (for example, the default encoding for StreamReader) which are not defined by a constant but instead repeated in the various constructor overloads as a direct parameter. These should be pulled out as new public constants as well.

Originally posted by @JeremyKuhne in https://github.com/dotnet/corefx/issues/8173#issuecomment-477301802

[svick]

to provide the proper defaults

.Net already has a way to do this: optional parameters with defaults. Is providing these values as their own members really better than optional parameters?

[JeremyKuhne]

.Net already has a way to do this: optional parameters with defaults. Is providing these values as their own members really better than optional parameters?

Normally no. In this case, however, we've got existing constructors that make adding default parameters untenable.

[scottdorman]

Optional parameters with defaults won't work in this case, as @JeremyKuhne mentioned. Unless the decision from (https://github.com/dotnet/corefx/issues/470#issuecomment-147809240) is going to be reversed (or ignored), optional parameters aren't recommended on public API surfaces. Also, @svick, this is the same issue you referenced in #17157:

Assuming optional arguments are okay (they probably aren't, see #13995),

[GSPP]

If these values are made public it should be a static property. const is burned into calling binaries at compile time and it also precludes any ability to chose a dynamic value at runtime.

I personally think this should not be public and any issues with constructor overloads should be dealt with in a different way. Various ideas for that have been proposed. A solution such as new FileStream(..., FileStream.DefaultBufferSize, ...) seems unappealing to me.

[carlossanlop]

@GSPP if we add it as a a static property to the Stream base class, we would not be able to make it virtual because it's static.

I mention this because many of our own stream-derived types define their own internal or private defaultBufferSize fields, with different values, so they would need to be able to override it. Here's a query with all the places where we already define a DefaultBufferSize. Notice they are internal or private, and a lot of the results belong to stream-derived classes: https://source.dot.net/#q=defaultbuffersize

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.