-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[API Proposal]: Add File.WriteAllBytes taking ReadOnlySpan<byte> #99823
Comments
Tagging subscribers to this area: @dotnet/area-system-io |
I'm actually surprised we don't have these. Went searching and found #35054 (comment). @terrajobst, @bartonjs, those concerns seem a bit stale; do we still have such objections? |
I'd personally like to see us add span APIs here and to other places where similar objections had been made in the past (like The desire to reduce allocations exists no matter where you are and while users can achieve this by creating their own Particularly with |
My only hesitation is the ad infinitum pause. That is, is doing this enough? Should we be doing more at the same time? Where does it end? I don't see anything wrong with the specific segment of the proposal, personally. |
Synchronous |
Virtually all new APIs taking in buffers should be using ROS (sync) or ROM (async). If the API is popular, it should also takes arrays. For existing APIs this largely means adding overloads. It ends when we stop caring ;-) |
@neon-sunset I think we should only have ROS for the sync APIs and no ROM overloads: namespace System.IO;
public static class File
{
public static void WriteAllBytes(string path, ReadOnlySpan<byte> bytes);
public static Task WriteAllBytesAsync(string path, ReadOnlyMemory<byte> bytes, CancellationToken cancellationToken = default);
public static void AppendAllBytes(string path, ReadOnlySpan<byte> bytes);
public static Task AppendAllBytesAsync(string path, ReadOnlyMemory<byte> bytes, CancellationToken cancellationToken = default);
} |
So yes its a duplicate of:
But this convenience method would be very welcome. Its a bit strange that it is to convert to a byte array. You could also just consider to drop the previous byte[] and string based overloads. Yes, a breaking changes but I don't know how .NET deals with droppen such legacy overloads. Needs to happen sometimes anyway :-) |
public static class File
{
public static void WriteAllBytes(string path, ReadOnlySpan<byte> bytes);
public static Task WriteAllBytesAsync(string path, ReadOnlyMemory<byte> bytes, CancellationToken cancellationToken = default);
public static void WriteAllText(string path, ReadOnlySpan<char> contents);
public static void WriteAllText(string path, ReadOnlySpan<char> contents, Encoding encoding);
public static Task WriteAllTextAsync(string path, ReadOnlyMemory<byte> contents, CancellationToken cancellationToken = default);
public static Task WriteAllTextAsync(string path, ReadOnlyMemory<byte> contents, Encoding encoding, CancellationToken cancellationToken = default);
public static void AppendAllBytes(string path, ReadOnlySpan<byte> bytes);
public static Task AppendAllBytesAsync(string path, ReadOnlyMemory<byte> bytes, CancellationToken cancellationToken = default);
public static void AppendAllText(string path, ReadOnlySpan<char> contents);
public static void AppendAllText(string path, ReadOnlySpan<char> contents, Encoding encoding);
public static Task AppendAllTextAsync(string path, ReadOnlyMemory<char> contents, CancellationToken cancellationToken = default);
public static Task AppendAllTextAsync(string path, ReadOnlyMemory<char> contents, Encoding encoding, CancellationToken cancellationToken = default);
} |
EDITED by @stephentoub on 4/21/2024:
Exact same shape as existing APIs that take
byte[]
/string
, just takingReadOnlySpan<byte/char>
instead for sync andReadOnlyMemory<byte/char>
for async.Background and motivation
Today, File.ReadAllBytes takes byte[] representing the bytes. It would be good to have an overload that takes ReadOnlySpan (sync ReadAllBytes) and ReadOnlyMemory (async ReadAllBytesAsync)
API Proposal
API Usage
Alternative Designs
Risks
No response
The text was updated successfully, but these errors were encountered: