Allow fixed to be omitted when taking a pointer to stack allocated memory?

[danmoseley]

(I used Microsoft (R) Visual C# Compiler version 3.0.19.6812 (231aeb8b))

using System;

class Program
{
        public static unsafe void Main(string[] args)
        {
            Span<uint> span = stackalloc uint[1];
            fixed (uint* pSpan = span) { } // legal
            uint* pSpan2 = span; // not legal
        }
}

Where the compiler can prove that the pointer is to a stack allocated memory, can the language allow fixed to be omitted?

BTW the error is CS0029 Cannot implicitly convert type 'System.Span<uint>' to 'uint*' but perhaps it could say ..except in a fixed context ?

[yaakov-h]

Where the compiler can prove that the pointer is to a stack allocated memory

How can it prove that a given Span<> points to stack-allocated memory? A Span could be wrapping an array or heap-allocated memory.

perhaps it could say ..except in a fixed context ?

Would this require checking for an analyzing a GetPinnableReference() candidate?

[tannergooding]

A user who knows a Span is definitely backed by stack-allocated memory can use Unsafe.AsPointer to get a T* without pinning.

[john-h-k]

@yaakov-h stackalloc and Span<> are special together, the span is not just an arbitrary one. Firstly, it allows you to directly init a span with a stackalloc (rather than explicitly passing the size), and it allows you to stackalloc in a safe context provided you assign it to a span rather than a pointer, and also, the compiler won't let you return a span initialized with a stackalloc

Span<byte> WillNotCompileButAlsoDoesNotNeedUnsafe()
{
    Span<byte> span = stackalloc byte[128];
    return span;
}

It seems perfect plausible, from a design perspective, that span should also get special treatment here.

[yaakov-h]

Firstly, it allows you to directly init a span with a stackalloc (rather than explicitly passing the size)

The compiler just emits a call to one of Span<T>'s constructors, specifically .ctor(void *, int32). It's still a Span.

it allows you to stackalloc in a safe context provided you assign it to a span rather than a pointer

IIRC the safety issue before C# 7.2 was due to user code using pointers, not due to the use of stackalloc itself. Now that the compiler generates code around a very short-lived pointer, the compiler can guarantee it's safety.

the compiler won't let you return a span initialized with a stackalloc

Hmm, I didn't know that one, but it does make sense. So there's already some flow analysis going on?

[john-h-k]

Yep. My point with the first two wasn't that they weren't a span or anything, just that it's already treated as a special type to the language - this proposition wouldn't just add special behaviour for some random type, it is consistent with current behaviour. Given it already recognises them for the return restriction, it could allow &span.GetPinnableReference() and &span[int] without needing to pin them first