UTF8 string literals as ReadonlyMemory<byte>

[petrroll]

Summary

Allow no-allocation ReadonlyMemory<byte> typed utf8 string literals.

Motivation:

While utf8 string literals as ReadonlySpan are great in data-consuming scenarios s.a. parsing that usually happens within the context of a single non-async method, they are not usable when it comes to producing data. At least not in network services environment, where everything is async.

The issue isn't new. It is explicitly mentioned in the lang specification for this feature / proposal but its solution is less than ideal.

However, certain contexts, most notably within async functions, do not allow locals of ref struct types, so there would be a usage penalty in those situations, with a ToArray() call or similar being required.

The usage penalty is IMHO not the problem. The problem is that even though there's no need for allocations - as the backing byte array has forever lifetime...

Since the literals would be allocated as global constants, the lifetime of the resulting ReadOnlySpan would not prevent it from being returned or passed around to elsewhere

...due to he restrictions of ReadOnlySpan type, it cannot be stored in normal classes, it cannot participate in async functions etc. And .ToArray() even though it wouldn't need to, allocates. And from my testing JIT in .NET 9 doesn't seem to optimize that copy/allocaiton away.

using System;
[BenchmarkDotNet.Attributes.MemoryDiagnoser]
public class Benchmarks
{
    [BenchmarkDotNet.Attributes.Benchmark]
    public ReadOnlyMemory<byte> Sha256()
    {
        ReadOnlyMemory<byte> bytes = "SomeVeryVeryVeryVeryInterestingString"u8.ToArray();
        return bytes;
    }
}

^^ this allocates

Solution

I don't have any clear solution. I'm not sure if it's possible to add new natural type ReadonlyMemory in this case for utf8 literals, and have it choose based on the target type. But if it was, it'd be one way (I understand ReadonlySpan would need to remain default not to break stuff).

[huoyaoyuan]

If a same sequence is likely to be produced in common paths, then a static readonly byte[] field would work fine.

[petrroll]

Yes, it has a workaround but it's more ceremony and is not the first thing many / most choose. It's even not what docs hint at.

[colejohnson66]

Problem: Memory<T> is based, not on a T reference, but an object reference. It, by design, requires an already allocated object. If you say "ok, so have the compiler create a MemoryManager<T>", all you're doing is adding overhead when you want the span vs. just wrapping a normal T[] into a Memory<T>, or even holding just the T[].

TL;DR: Turning RVA into a Memory<byte> already requires allocations and would be slower than a plain byte[] a la static readonly byte[] MyData = "..."u8.ToArray().

[petrroll]

Why would

ReadOnly]Memory would demand a MemoryManager

Readonlymemory can wrap byte[] no? And if that's static/frozen then there's no access allocation. Definitely no memorymanager alloc or what am I missing?

[colejohnson66]

Language features can often be about simple convenience to the user.

Yes, but that's not what was being asked. Again: OP's original claim was that this could be allocation free:

Allow no-allocation ReadonlyMemory<byte> typed utf8 string literals.

That's not possible no matter what.

[jaredpar]

Again: OP's original claim was that this could be allocation free

I agree there is an allocation here for the byte[] hence not allocation free. But it would be amortized and that is often seen as a useful optimization.

Can you elaborate on your claim that this forces a MemoryManager<T> allocation?

[petrroll]

Fair point about there being allocation. (Even though in case of it gets frozen possibly so).

But allocation per process run on only first invocation or even before is for all intense and purposes and 99 % scenarios allocation free. It's not allocation free as in you can run it without any heap but well I doubt there's much you can. The runtime itself allocates bunch one time.

It's not just amortized like pooling it's one time only. Per location. Per whole process lifetime.

[colejohnson66]

Can you elaborate on your claim that this forces a MemoryManager<T> allocation?

I wasn't clear. I meant: you can either (a) heap-allocate a byte[] and copy out of RVA (the "abc"u8.ToArray()), or (b) create a custom MemoryManager<byte> type that wraps the RVA (of which only the compiler could do safely) and would also be heap-allocated. Both of those would then be wrapped into your ReadOnlyMemory<byte>.

In case it's not clear: I'm not debating the usability of this proposal. The current limitations on RVA are very annoying sometimes. My original comment was simply clarifying that the whole thing can't be allocation-free as OP desired. Yes, it's amortized over the course of the application, but so is static readonly byte[] MyStuff = "abc"u8.ToArray(). That's it.