Updated draft for the safety of ref-like types such as Span<T>

[VSadov]

No description provided.

[davkean]

This needs explaining - you've not explained "intermediate span values" previously.

[VSadov]

Basicaly M1(M2()) is ok in an async method, even if M2() returns a span. Will add an example.

[davkean]

What's the rationale for this? It's not clear to me (not being involved in this, why this rule exists)

[VSadov]

If we classified one variable as safe to return and another variable as stack-referring, we will need to prevent assignments from second to the first, since that would invalidate the classification (and we do not want to do global data flow analysis - it is hardly tractable).

The goal here is to prevent such assignments while not causing too much inconvenience. The call boundary is an issue though.

If I make a call like M1(p1: ref safeToReturn), I am risking that M1 will do p1 = stackalloc int[10];

In a more complex case I am making a call like M2(p1: ref safeToReturn, p2: unsafeToReturn) and M2 does p1 = p2;.

We need to make both scenarios illegal.
The original proposal simply disallowed passing spans by reference. It was found too restricting so we need something else.

In this proposal assigning stack-referring values to parameters (or to anything other than stack-referring locals) is disallowed. That handles the p1 = stackalloc int[10];case.

The other case is harder. Inside M2 we cannot tell whether assigning the second parameter to the first is unsafe, so we disallow at the call side passing an ordinary span variable by reference and any kind of stack-referring spans in the same call, so that M2 could assign one parameter to another without worrying.

Thanks for commenting. I will add these details to the document.

[jkotas]

We are going to need attribute to mark ref-like types - to avoid spooky action at a distance when Span is embedded in other structs.

[VSadov]

@jkotas - yes, we will use [Obsolete] with a well-known message in metadata. That will also allow us to error on compilers that are not aware of span requirements.

And in the source we will use ref struct S1

We had some follow up discussions on that. I will add that to the document.

[jkotas]

[Obsolete] with a well-known message may be fine to poison the type for old compilers; but I do not think that it should be the ultimate way to identify these types. Note that these types need to be identified accross the board - in the runtime, tools, etc.

[VSadov]

It is possible to add another attribute, but it would always have to be combined with the Obsolete.
It is possible, but seems a bit redundant.

[VSadov]

Note that the Obsolete message must be precise or we cannot distinguish it from an ordinary obsolete attribute.

It does feel that having two attributes having distinct meanings is more direct way of doing this, but there is also the part that they will have to be always emitted in pairs makes it seem a bit redundant.

We should think about this.
There is nothing inherently wrong with having "IsRefStructAttribute"

[svick]

Will it somehow be possible to create a ref-like struct that contains ref fields?

[mgravell]

Firstly: I love this very much; this would remove the unsafe from much of my stack span code.

Probably simply "no" (and that's fine), but: is there any utility to exposing something akin to array initializer syntax here?

Span<int> sp = stackalloc { 1, 42, 13 };

(Note preserving the stackalloc keyword to retain the intent in the code)

[mikedn]

This is interesting. It doesn't require unsafe but the resulting code is unverifiable. It would seem that we're moving towards a system where the managed compiler(s) are responsible for ensuring type safety and not the runtime.

[mikedn]

Can perhaps modreq be used instead of this Obsolete based hack? It seems that the main problem with an old compiler using these types is the possibility of exposing references to stack locations that have been "freed" and this can only happen via method calls.

Other improper uses of ref-like types will be blocked by the runtime. Sure, it would be it would be nice to be blocked at compile time but using Obsolete for that is quite ugly.

[davkean]

@mikedn It's an interesting idea, and definitely falls in the spirit of what they were designed for (think of some the C++ modifiers; IsUdtReturn, IsByValue, etc).

[omariom]

@VSadov

Will such scenario be allowed?

private void M()
{
    var myStruct = new MyStruct(stackalloc int[10]);
    Foo(myStruct);
    Bar(myStruct.ReadOnlyView);
}

private void Foo(MyStruct myStruct)
{
}

private void Bar(ReadOnlySpan<int> roSpan)
{
}

reflike struct MyStruct
{
    private Span<int> span;

    MyStruct(Span<int> span) => this.span = span;
    
    public ReadOnlySpan<int> ReadOnlyView => span.AsReadOnly(); 
}

[VSadov]

@omariom - not exactly like that, stackalloc can be used only when initializing a local, so you would need one more span-typed variable, but yes, conceptually the above example will work. At least according to the rules in the proposal.

[mgravell]

to me, though, it does also prompt the question of whether there should also be a syntax for initializing a stack-allocated span into a local *without* requiring "unsafe" (for "stackalloc"). Probably ties more into #535 than this though - is specific to span. On 4 Jun 2017 3:40 a.m., "Vladimir Sadov" <[email protected]> wrote: @omariom <https://github.com/omariom> - not exactly like that, stackalloc can be used only when initializing a local, so you would need one more span-typed variable, but yes, conceptually the above example will work. At least according to the rules in the proposal. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#472 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsPgvdW74zF9ET-qTs9zwdWO4VIZnks5sAhkmgaJpZM4NDv60> .

[omariom]

@VSadov

stackalloc can be used only when initializing a local, so you would need one more span-typed variable

It should be relaxed for safe (Spans) case.