Question: temporary struct lifetime

[kevinjwz]

I am writing a value-type list implicitly convertible to Span<T>, as a temporary solution for "params Span".
As a first try:

[StructLayout(LayoutKind.Sequential)]
struct ValueList
{
	int length;
	int i0,i1,i2,i3;

	public static implicit operator Span<int>(in ValueList v) =>
		MemoryMarshal.CreateSpan(ref Unsafe.AsRef(v.i0), v.length);	

	public static ValueList List(int i0) => 
		new ValueList { length = 1, i0 = i0 };

	public static ValueList List(int i0, int i1) => 
		new ValueList { length = 2, i0 = i0, i1 = i1 };

	public static ValueList List(int i0, int i1, int i2) => 
		new ValueList { length = 3, i0 = i0, i1 = i1, i2 = i2 };

	public static ValueList List(int i0, int i1, int i2, int i3) => 
		new ValueList { length = 4, i0 = i0, i1 = i1, i2 = i2, i3 = i3 };
}

And the typical use case:

class Test
{
	static void Foo(Span<int> span) { }

	static void Main(string[] args)
	{
		Foo(ValueList.List(1, 2, 3));  // safe?
	}
}

The codes compile, but I don't know whether or not the temporary struct will be destroyed before calling Foo.
Is there any spec about this?

[kevinjwz]

Another unclear case:

static void Main(string[] args)
{
	Span<int> span = ValueList.List(1, 2, 3);
	// still safe to use span?
}

[svick]

I don't believe this is safe. Consider the following code:

static void Main()
{
    Span<int> span1 = ValueList.List(1, 2, 3);
    Span<int> span2 = ValueList.List(4, 5, 6);
    Console.WriteLine(span1[0]);
}

When I run it, it prints 4, which shows that span1 is not safe to use, because it got overwritten by another value.

I think this hinges on the lifetime of the temporary variable that is introduced by the compiler when passing a value to an in parameter (in this case, the parameter of the conversion operator). But unfortunately, I couldn't find the answer to that question in the closest thing to the spec for in parameters we have at the moment.

[SingleAccretion]

Yes, the first value list gets overwritten by the second. It is a bit weird though, because initially the lists are actually in different memory locations, but the JIT decides to copy each into the same one. See on Sharplab.

I guess it is not a bug since we are using Unsafe, but this is still rather curious.

[svick]

@SingleAccretion I think the JIT is required to do that overwrite, because the C# compiler decides to reuse the same local variable for both ValueLists in IL. Notice that there's only one [1] valuetype ValueList and that both use stloc.1.

[kevinjwz]

I am more concerned about passing ValueList as arguments, and a simple test shows it works for now.

class Test
{
	static void Foo(Span<int> span1, Span<int> span2)
	{
		Console.WriteLine(span1[0]);  // print 1
		Console.WriteLine(span2[0]);  // print 4
	}

	static void Main(string[] args)
	{
		Foo(ValueList.List(1, 2, 3), ValueList.List(4, 5, 6));
	}
}

[SingleAccretion]

I think the consensus among people here would be that you shouldn't use this code. This simple and innocent example breaks:

static void Main(string[] args)
{
   var a = PreserveReference(ValueList.List(1, 2, 3));
   var b = PreserveReference(ValueList.List(4, 5, 6));

   Console.WriteLine(a[0]); //Prints 4
}

static Span<int> PreserveReference(Span<int> span) => span.Slice(0);

[kevinjwz]

@SingleAccretion That's true, but my motivation is to pass length-variadic tuples as arguments without allocations, and returning references to the arguments is, IMO, pointless in most situations.

[SingleAccretion]

I am sorry, that's just me being wrong. The example was indeed OK.

[kevinjwz]

In this documentation, there are 2 sentences about the life time of temporary variables:

The life time of the argument temporaries matches the closest encompassing scope of the call-site.

The formal life time of temporary variables is semantically significant in scenarios involving escape analysis of variables returned by reference.

Does the first sentence mean:

static Span<int> ToSpan(in ValueList v) => v;

static void Main(string[] args)
{
	if (true)
	{
		var span = ToSpan(ValueList.List(1, 2, 3));
		// ValueList.List(1, 2, 3) still lives
	}
	// ValueList.List(1, 2, 3) is destroyed
}

And does it also appliy to implicit conversions?

[agocke]

I think the C# language spec states that the ref being passed to CreateSpan has a global lifetime, so the result is safe to return.

As for whether your code works, the spec would say, Unsafe class = lol UB

[kevinjwz]

@agocke I think this code didn't introduce a temporary variable.

public static implicit operator Span<int>(in ValueList v) =>
	MemoryMarshal.CreateSpan(ref Unsafe.AsRef(v.i0), v.length);	

[kevinjwz]

I think I was working on a wrong direction.
My goal is to pass variable length tuples as arguments, why not just make the parameter type in ValueList?
But it brings a new problem. Suppose params Span<T> becomes available, and I want to use it to simplify my ValueList struct and lift the limitation on the max length.

ref struct ValueList
{
	Span<int> span;

	public static implicit operator Span<int>(in ValueList v) => span;

	public static ValueList List(params Span<int> args) => 
		new ValueList { span = args };
}

class Test
{
	static void Foo(in ValueList list) { }

	static void Main(string[] args)
	{
		Foo(ValueList.List(1, 2, 3));  // prevent zero-alloc optimization?
	}
}

I am not sure what will happen.
Current params Span<T> proposal

[kevinjwz]

Though not related to the title, there's a solution looks pretty:

[StructLayout(LayoutKind.Sequential)]
struct ValueList
{
	int length;
	int i0,i1,i2,i3;

	public static implicit operator Span<int>(in ValueList v) =>
		MemoryMarshal.CreateSpan(ref Unsafe.AsRef(v.i0), v.length);	
	
	// no syntax for one-element tuple
	public static implicit operator ValueList(int value) =>
		new ValueList { length = 1, i0 = value };

	public static implicit operator ValueList(in (int, int) tuple) =>
		new ValueList { length = 2, i0 = tuple.Item1, i1 = tuple.Item2 };

	public static implicit operator ValueList(in (int, int, int) tuple) =>
		new ValueList { length = 3, i0 = tuple.Item1, i1 = tuple.Item2, i2 = tuple.Item3  };

	public static implicit operator ValueList(in (int, int, int, int) tuple) =>
		new ValueList { length = 4, i0 = tuple.Item1, i1 = tuple.Item2, i2 = tuple.Item3, i3 = tuple.Item4 };
}

class Test
{
	static void Foo(in ValueList list1, in ValueList list2) { }

	static void Main(string[] args)
	{
		Foo((1, 2, 3), (4, 5, 6));
	}
}

[kevinjwz]

However, I still love the idea of using Span<T> to receive a tuple of arbitrary length.

[kevinjwz]

@agocke

I think the C# language spec states that the ref being passed to CreateSpan has a global lifetime, so the result is safe to return.

Now I understand what you meant. You meant that a Span<T> works like a ref (managed pointer), so anything the ref points to still lives as long as the Span<T> lives.
Doesn't that only works when the ref points to the interior of a heap object?

static Span<int> Foo()
{
    int i = 0;
    return MemoryMarshal.CreateSpan(ref i, 1);
}

The above compiles, but I don't believe i still lives after Foo returns.
I think the compiler didn't realize that MemoryMarshal.CreateSpan converts a ref to a Span<T>, just like Unsafe.AsRef etc.

[agocke]

Doesn't that only works when the ref points to the interior of a heap object?

Yes, but I believe that's what the ref-return lifetime of Unsafe.As is. If a method returns a ref and doesn't take any ref parameters, what else could it be ref-returning? Of course, that's not true for Unsafe.As because they violate the safety rules, but that's the point -- they're lying about the safety.

[kevinjwz]

@agocke

Doesn't that only works when the ref points to the interior of a heap object?

Yes, but I believe that's what the ref-return lifetime of Unsafe.As is.

I am not quite understand what you mean.

dotnet/runtime/issues/27295 seems related, but no one talked about temporary struct.

There is a guarantee in C++:

a temporary bound to a reference parameter in a function call exists until the end of the full expression containing that function call: if the function returns a reference, which outlives the full expression, it becomes a dangling reference.

https://en.cppreference.com/w/cpp/language/reference_initialization

To be clear, that's what I am mainly concerned about.

[agocke]

I'm saying that you're currently out of the bounds of the language. The Unsafe and MemoryMarshal APIs violate the Span safety rules, so the language behavior for your program is undefined.

[kevinjwz]

@agocke I agree with you. Those API should be used very carefully, in some performance-sensitive code.
But if the lifetime of the struct can be guaranteed, Unsafe.AsRef<T>(in T) shouldn't be a problem, since it merely does nothing in IL level.

[agocke]

So then the answer to your original question,

Is there any spec about this?

is yes, but you're out of bounds of the specification. Under the specification there's no way to observe the lifetime of an in temporary as a Span outside of the method call.

[kevinjwz]

@agocke Thanks.

Perhaps the best choice is to change parameter type to in ValueList, since it's clearer than Span. Users could unexpectly pass an array to Span, making "zero-alloc" meaningless.