Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tracking]: Remove SafeFileHandle for Unix #61112

Closed
deeprobin opened this issue Nov 2, 2021 · 5 comments
Closed

[tracking]: Remove SafeFileHandle for Unix #61112

deeprobin opened this issue Nov 2, 2021 · 5 comments

Comments

@deeprobin
Copy link
Contributor

@deeprobin yeah it's a historical issue, and would need a hypothetical feature to fix: #26227 (comment)

Originally posted by @danmoseley in #60507 (comment)

@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Nov 2, 2021
@danmoseley
Copy link
Member

The proposal here is to find a way to move SafeFileHandle and such classes out of Microsoft.Win32.SafeHandles into some namespace that doesn't have the historic ties with Windows.

Unfortunately as far as I can see that requires a nonexistent feature that allows types to be forwarded between namespaces. I would expect we would need much more compelling reasons to do something like that. @jkotas has that ever come up?

@ghost
Copy link

ghost commented Nov 2, 2021

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

@deeprobin yeah it's a historical issue, and would need a hypothetical feature to fix: #26227 (comment)

Originally posted by @danmoseley in #60507 (comment)

Author: deeprobin
Assignees: -
Labels:

area-System.Runtime, untriaged

Milestone: -

@jkotas
Copy link
Member

jkotas commented Nov 2, 2021

Namespace forwarding is a very complex feature to build. It comes up occasionally when the technology names or positioning changes, the old names are not good fit anymore and people would like to stay compatible with old names and have new names at the same time.

In practice, the changes in technology names or positioning are often accompanied by other (breaking) changes, so namespace forwarding would not actually help to fully solve the problem in many cases.

@danmoseley
Copy link
Member

Thanks. @deeprobin I'm going to close this because we don't have sufficient compelling reason to make such a major investment - although I don't like the name either. thanks for opening this tracking issue though.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2021
@tannergooding tannergooding removed the untriaged New issue has not been triaged by the area owner label Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants