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
Need Span overloads for Path APIs #24264
Comments
FYI: The API review discussion was recorded - see https://youtu.be/9F_NsviGT0Y?t=552 (7 min duration) |
This change is pretty straight-forward. We'll need to clean up internal "index of" helpers and have existing APIs call these new public methods. Tests will need to be added. |
5 days assuming it's someone less familar with the area, including cleanup mentioned. |
Just to mention I don't like these changes. I think they make these very basic APIs considerably harder to use for beginners. Really. we shouldn't be littering I trust basic usability of .NET for very basic file system operations beginners stays on the radar of the people doing the API reviews. p.s. Adding overloads can also break type inference in F# code, but that's a separate matter. |
@dsyme assuming some folks do need these for perf (like ourselves) are you suggesting they should have gone on a new type? ( @jkotas Could tooling someday help here, somehow hiding overloads that differ only in ReadOnlySpan vs string, and just letting the compiler bind to the right one? (That doesn't help where the signature changes entirely eg the Try pattern ones) |
These weren't added for the coolness factor. These overloads are very important for I/O heavy solutions. Allocations for path manipulation is a significant drag on VS/MSBuild for example. They also aren't intended for beginners. The existing APIs are still there and can and should be used by people who don't care about allocations. We could, in theory, move them into a different class or namespace, but I'm afraid that boat has already sailed. Discoverability was judged to be more important for APIs that match existing ones- and that has been done throughout the framework. |
You are typing I guess there can be AI applied to it, classify the users and the APIs, and then decide that most of the users like you do not use Span Path APIs and do not show you those either. I am not saying it is a good idea ... just brainstorming. BTW: As some of you know I am worried that there are usability issues with the new Path APIs even for expert use. dotnet/coreclr#17429 (comment) and dotnet/coreclr#17528 (comment) has some of the discussions. |
If we could show a notional |
Note that the linked issues are APIs that haven't shipped and are very different from these ones, which are complete and part of 2.1. We're still trying to navigate the right pattern for APIs that take an output buffer. |
In order to reduce allocations for path generation and manipulation we need Span overloads for
System.IO.Path
APIs.Proposed API
Implementation Notes
The text was updated successfully, but these errors were encountered: