Skip to content

Conversation

jaredpar
Copy link
Member

No description provided.

@jaredpar jaredpar requested a review from a team as a code owner May 29, 2025 22:55
@jaredpar jaredpar requested a review from agocke May 29, 2025 22:55
@jaredpar
Copy link
Member Author

@agocke, @AaronRobinsonMSFT PTAL


Conforming runtimes will ensure that `TypedReference`, `RuntimeArgumentHandle` and `ArgIterator` are defined as `ref struct`. Further `TypedReference` must be viewed as having a `ref` field to a `ref struct` for any possible type (it can store any value). That combined with the above rules will ensure references to the stack do not escape beyond their lifetime.

```csharp
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AaronRobinsonMSFT here you go.

// Error: safe-to-escape is current method which is not returnable
return tr;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to confirm the following example:

struct OS
{
    public IS inner;
}

struct IS
{ }

TypedReference M4(TypedReference os)
{
    // os contains a 'ref OS'
    // Return a 'ref IS' via the TypedReference
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you trying to get the following to compile?

TypedReference M4(TypedReference os)
{
  ref IS local = __refvalue(os, IS);
  return __makeref(local);
}

That will compile. It's logically equivalent to the following:

TR M(TR tr)
{
    ref int local = ref tr.field;
    return new TR { field = ref local };
}

ref struct TR
{
    public ref int field;
}

@En3Tho
Copy link

En3Tho commented May 30, 2025

@jaredpar I wonder if there is some document describing your view of the C# lifetime system with goals, imaginary syntax and so on? I'm really curious how you envision such a big feature/change. (Even if it might never come).

@jaredpar
Copy link
Member Author

I'm really curious how you envision such a big feature/change. (Even if it might never come).

Which change are you referring to here: a world where we have explicit lifetimes?

@En3Tho
Copy link

En3Tho commented May 31, 2025

@jaredpar Yes, explicit lifetime annotations in C#. How they would work with IDisposable, would they work with reference types, pointers?

What would be design goals: is it to enhance ref usage only or to enable developers with something like automatic disposal on scope exit?

I think it's fun to experiment with such features and I'm curious what do you have in mind.

@En3Tho
Copy link

En3Tho commented Jun 2, 2025

@jaredpar Yes, explicit lifetime annotations in C#. How they would work with IDisposable, would they work with reference types, pointers?

What would be design goals: is it to enhance ref usage only or to enable developers with something like automatic disposal on scope exit?

I think it's fun to olay with such features and I'm curious what do you have in mind.

@jaredpar
Copy link
Member Author

jaredpar commented Jun 2, 2025

Yes, explicit lifetime annotations in C#. How they would work with IDisposable, would they work with reference types, pointers?

I've never sat down and wrote a doc about this because I wanted to focus on how far we could take the existing system. Once we know the limitations of how far you can take scoped plus a few expert level attributes it helps define what is left and what level of investment you would use to solve those problems.

Once I get pas this though, I will likely sit down and write a doc for where we'd go beyond scoped.which wolud include explicit lifetime rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants