Proposal: Allow ROS<byte> v = [] + ""u8

[am11]

What works today:

ReadOnlySpan<byte> magic = "hello"u8 + " magic!"u8;

What doesn't work:

// prepend byte-order-mark
ReadOnlySpan<byte> magic = [0xEF, 0xBB, 0xBF] + "hello"u8 + " magic!"u8;

error CS0019: Operator '+' cannot be applied to operands of type 'collection expressions' and 'ReadOnlySpan<byte>'

In practice, this means we have to give up the nice u8 syntax when a binary prefix is required (e.g. https://github.com/dotnet/runtime/blob/b7f05cd78da27007f3dc378696697c0268251a58/src/installer/managed/Microsoft.NET.HostModel/Bundle/Bundler.cs#L237).

[RikkiGibson]

It looks like spreads would do what you are asking for

ReadOnlySpan<byte> magic = [0xEF, 0xBB, 0xBF, .."hello"u8, .." magic!"u8];

[am11]

It works as local field but not as property (not a compile-time constant?):

    // works
    private static ReadOnlySpan<byte> magic1 =>
        "hello"u8 + " magic!"u8;

    //     error CS9203: A collection expression of type
    // 'ReadOnlySpan<byte>' cannot be used in this context because
    // it may be exposed outside of the current scope.
    private static ReadOnlySpan<byte> magic2 =>
        [0xEF, 0xBB, 0xBF, .."hello"u8, .." magic!"u8];

[RikkiGibson]

Yes unfortunately this is a bit of a gap in the language. Even though the spread values are "constant-like" (e.g. spelling out the bytes as elements (byte)'h', (byte)'e', ... would work), we still give the resulting ROS a lifetime of current-block. That is something LDM could consider relaxing in the future with an accompanying optimization to store the whole sequence in the assembly's data segment.

In this case, I suggest using an ImmutableArray<byte> property type and converting to span as needed. Note the get;/initializer is important here to avoid allocing a new array on each access.

    private static ImmutableArray<byte> magic2 { get; } =
        [0xEF, 0xBB, 0xBF, .."hello"u8, .." magic!"u8];

    void M() { ReadOnlySpan<byte> span = magic2.AsSpan(); ... }

[am11]

That is something LDM could consider relaxing in the future with an accompanying optimization to store the whole sequence in the assembly's data segment.

That sounds promising! Here’s a nuanced example illustrating the idea:

ReadOnlySpan<byte> magic1 = [0xEF, 0xBB, 0xBF, .."hello"u8, .." magic!"u8];

ReadOnlySpan<byte> constant = "hello"u8;
ReadOnlySpan<byte> magic2 = [0xEF, 0xBB, 0xBF, ..constant, .." magic!"u8];

ReadOnlySpan<byte> constant = "hello"u8;
ReadOnlySpan<byte> variable = Get();
ReadOnlySpan<byte> magic3 = [0xEF, 0xBB, 0xBF, ..constant, ..variable];

magic1 and magic2 could become const data [0xEF, 0xBB, 0xBF, 0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x20, 0x6D, 0x61, 0x67, 0x69, 0x63, 0x21], and magic3 with 'best effort': [0xEF, 0xBB, 0xBF, 0x68, 0x65, 0x6C, 0x6C, 0x6F] followed by the existing List.Add.ToArray flow.

[RikkiGibson]

Yes that would be more of a stretch goal, but, something that might be possible given the right design. See spec.

A u8 literal doesn't have a constant value. That is because ReadOnlySpan cannot be the type of a constant today. If the definition of const is expanded in the future to consider ReadOnlySpan, then this value should also be considered a constant. Practically though this means a u8 literal cannot be used as the default value of an optional parameter.

This means that the language/compiler's existing mechanisms for propagating constant values, aren't able to "just work" as easily with utf8 strings.