Take ReadOnlySpan<char> instead of string in friendly overloads

[jnm2]

Strings can always be passed as ReadOnlySpan<char>, but if what you have is a span, that can't be passed as a string without allocating. For example, here is a scenario where a previous API call populated some spans:

var productCode = (stackalloc char[39]);
var componentCode = (stackalloc char[39]);
if (PInvoke.MsiGetShortcutTarget(shortcutPath, productCode, null, componentCode) != 0)
{
    componentPath = null;
    return false;
}

const int bufferSize = 1024;
var buffer = (stackalloc char[bufferSize]);
uint length = bufferSize;

var result = PInvoke.MsiGetComponentPath(productCode.ToString(), componentCode.ToString(), buffer, ref length);

In order to avoid those two ToString allocations, I would now have to introduce an unsafe block for the first time, and use three fixed statements to pin the three spans being passed to MsiGetComponentPath.

Alternatively, the friendly overloads could always take ReadOnlySpan<char> instead of string.

[jevansaks]

I like this suggestion but most PWSTR-defined APIs require that the string be null-terminated. There's a good discussion in #1296 where @AArnott tried to fix a similar situation and ran into challenges.

If an API was truly char* and did not require null termination then ReadOnlySpan would be a nice upgrade, but changing it universally might cause more trouble since a compile-time enforcement of null termination, as guaranteed by the string type, would need to change into a runtime enforcement.

I'm open to other suggestions on how to avoid the allocations without losing the static validation of null termination (and without blowing up the overloads to have string versions and PWSTR versions). I do wish there was a way for PWSTR to be convertible from string.

[jnm2]

Since the friendly overload forces allocations, you would then switch to the pointer overload, and not have any enforcement of null termination anyway. Why is it so important for the friendly overload to do extra validation (on behalf of the API, not on behalf of the change to friendly parameter types) that is not done in the pointer overload?

[jevansaks]

The friendly overloads often have restrictions that the ABI does not -- e.g. enforcing that a buffer param and length are connected via Span. Where we can statically enforce a contract that the ABI is unable to, we'll try to do that.

I want allocation-free overloads too I'm just hoping we can come up with a solution that lets us have both static enforcement and no allocations.

[jnm2]

To statically flow the information, the only thing I can think of is some sort of wrapper type for Span that lends it the "zero-terminated" meaning, just like how PWSTR wraps a pointer and lends it the same meaning. Then you'd pass the span as (WSTR)buffer or something like that.

Ideally, MsiGetShortcutTarget would even take WSTR parameters in that case so that you can tell statically that it's not going to put a non-nul character at the end of the buffer.

[jevansaks]

Right, a NullTerminatedReadOnlySpan is where my head is at. I'll tinker with this at some point.