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

Reflection support for Tuple and ValueTuple #44318

Open
steveharter opened this issue Nov 5, 2020 · 2 comments
Open

Reflection support for Tuple and ValueTuple #44318

steveharter opened this issue Nov 5, 2020 · 2 comments
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Reflection
Milestone

Comments

@steveharter
Copy link
Member

Background and Motivation

When using Tuple and ValueTuple, metadata is hard to access:

  • The name of the members ("Item1", "Item2", etc) must be obtained through reflection. For Tuple, they are the property names. For ValueTuple, they are field names. Also, Tuple is an immutable reference type while ValueTuple is a mutable value type which further complicates the usage patterns.
  • When more than 7 elements are used, the Rest property\field must be used, which is another Tuple, and thus the total count is not obvious and must be calculated.
  • The "TransformName" or friendly parameter name used with ValueTuple must be obtained from reflection in a non-trivial manner by inspecting [TupleElementNames].

At runtime, the ITuple interface is useful to abstract away the Rest property\field and provide a count, although it doesn't support the "TransformName". However, similar behavior is not available through reflection. See dotnet/csharplang#1906.

Proposed API

  • Add extension methods to the existing System.Reflection.Extensions assembly.
    • This avoids runtime knowledge and pay-to-play for consumers.
  • These look-up the various metdata and return an new TupleInfo value type.
    • This is somewhat slow and no extra caching is performed (like similar cases elsewhere). Caching should be done at a higher level, if necessary.
  • The extensions should work for both runtime-based and designtime-based reflection types (via MetadataLoadContext).

API (in System.Reflection namespace):

public static class EventInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this EventInfo eventInfo);
}

+public static class FieldInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this FieldInfo fieldInfo);
}

public static class MemberInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this MemberInfo member);
}

public static class MethodInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this MethodInfo method);
}

+public static class ParameterInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this ParameterInfo parameter);
}

public static class PropertyInfoExtensions
{
+    public static TupleInfo[] GetTupleInfo(this PropertyInfo property);
}

public partial struct TupleInfo
{
    public readonly string Name { get; }
    public readonly string? TransformName { get; }
    public readonly System.Type Type { get; }
}

InvalidOperationException is thrown if the various metadata type (PropertyInfo, etc) is not a Tuple or ValueTuple.

Prototype at master...steveharter:ReflectionExt

@steveharter steveharter added api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Reflection labels Nov 5, 2020
@steveharter steveharter added this to the 6.0.0 milestone Nov 5, 2020
@steveharter steveharter self-assigned this Nov 5, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 5, 2020
@steveharter steveharter removed the untriaged New issue has not been triaged by the area owner label Nov 13, 2020
@jeffhandley
Copy link
Member

We won't get to this during .NET 6; moving to .NET 7.

@jeffhandley jeffhandley modified the milestones: 6.0.0, 7.0.0 Jul 7, 2021
@steveharter steveharter removed their assignment Jul 16, 2021
@ghost ghost added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Jul 16, 2021
@krwq krwq removed the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Jul 20, 2021
@buyaa-n buyaa-n modified the milestones: 7.0.0, 8.0.0 Jul 6, 2022
@steveharter
Copy link
Member Author

This is a lower-priority issue with no reported asks from the community. Moving to future.

@steveharter steveharter modified the milestones: 8.0.0, Future Dec 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Reflection
Projects
No open projects
Development

No branches or pull requests

5 participants