Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back TypedReference #19507

Closed
jkotas opened this issue Nov 29, 2016 · 10 comments
Closed

Bring back TypedReference #19507

jkotas opened this issue Nov 29, 2016 · 10 comments
Labels
api-approved API was approved in API review, it can be implemented area-System.Runtime
Milestone

Comments

@jkotas
Copy link
Member

jkotas commented Nov 29, 2016

TypedReference has not been very useful type so far, with non-trivial implementation cost, and that is why we have decided to not include it in .NET Standard.

However, the recent discussion #19484 revealed that it is a good building block for new high-performance reflection APIs that avoid boxing and address other reflection limitations. We should consider bringing it back.

The steps are:

  1. Bring TypedReference back (to .NET Standard 2.0?)
  2. Add methods to TypedReference that make it useful (e.g. use generic methods as a first class replacement for the undocumented C# __refvalue and similar keywords)
  3. Add high-performance reflection APIs that avoid boxing (see Proposal: Add new GetValue method to System.Reflection #19484 for discussion)

This issue is tracking the first step.

@jkotas
Copy link
Member Author

jkotas commented Nov 29, 2016

@karelz
Copy link
Member

karelz commented Nov 29, 2016

@weshaggard @danmosemsft any thoughts?

@danmoseley
Copy link
Member

I have no objection (I imagine the cost of (2) and (3) is the main consideration)

I'm not sure why we'd put it in Standard -- it may be present in other platforms, but it's used for (1) __arglist that is not necessarily present (dotnet/standard@6e3ad1) and (2) these new functions which won't be present.

@weshaggard
Copy link
Member

I also don't have any concerns as it is primarily a runtime/codegen/language feature then it is a library feature. If we did add it to .NET Standard 2.0 as @danmosemsft points out it can only contain the APIs that already exist in the full .NET framework.

@Thaina
Copy link

Thaina commented Jan 11, 2017

Could we also consider return ref in C# next version?

@jkotas
Copy link
Member Author

jkotas commented Jan 11, 2017

@Thaina I am not sure what you mean. ref returns are part of C# 7. dotnet/roslyn#118. Check the readme in Roslyn on how to get latest builds of C# 7 to give it a try. Also, any questions about this feature would be best asked in the Roslyn repo.

@Thaina
Copy link

Thaina commented Jan 11, 2017

@jkotas I thought you was mention this thread to me at dotnet/coreclr#8877

What I mean is reflection GetValue should be generic and could return ref instead of TypedReference so, maybe we could drop TypedReference?

edit: well, not directly this thread. I just track this from #19484. But still the same. TypeReference might not really need if we could return ref directly

@terrajobst
Copy link
Member

terrajobst commented Jan 11, 2017

We can certainly expose TypedReference in .NET Standard, but the new methods mentioned in @jkotas' point (2) will have to wait until we can rev the standard again.

The .NET Standard work is discussed in dotnet/standard#20.

@jkotas
Copy link
Member Author

jkotas commented Jan 11, 2017

I do not think we need to rush it to .NET Standard 2.0. It is good enough if we add it to netcoreapp first - together with the other APIs that will make it actually useful.

@terrajobst
Copy link
Member

The API was already approved and it's already added to .NET Standard and .NET Core.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-System.Runtime
Projects
None yet
Development

No branches or pull requests

7 participants