search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.36k stars 9.99k forks source link

FileMultipartSection.FileStream and MultipartSection.Body Nullability Differences #39966

Open jmzagorski opened 2 years ago

jmzagorski commented 2 years ago

Background and Motivation

Not sure if this is really an API proposal, but it was the only issue template that made sense to me.

I noticed FileMultipartSection.FileStream is marked as a Nullable Stream, but MultipartSection.Body Stream is not Nullable. It looks like FileMultipartSection.FileStream is only set from the MultipartSection.Body so I would assume that both would have the same Nullable reference type. My only thought is that MultipartSection.Body has a public setter so it "could" be set to null, but if so then FileMultipartSection.FileStream should be null too. I could be overlooking something.

Proposed API

Both to have the same Nullability if that assumption is correct

Usage Examples

Either changing the MultipartSection Body property to 

public Stream? Body { get; set; } = default;

or changing the FileMultipartSection.FileStream to 

public Stream FileStream => Section.Body;

Alternative Designs

Leave it as is. I could be looking at this wrong so I apolgize.

Risks

Could add warnings / errors to existing code that uses the Nullable feature if the change was to Stream and not Stream?

ghost commented 2 years ago

Thanks for contacting us. We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

ghost commented 2 years ago

Thanks for contacting us. We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.