Proposed support for Reflection functions that get type of generic var/const fields from a type variable

[lydia-duncan]

Here are the function prototypes I would expect to see based on what is currently present. Such functions would use PRIM_STATIC_FIELD_TYPE, as mentioned in #11816

// Get the type of the ith field in a class or record type. Causes a compilation error
// if i is not in 1..numFields(t).
// Note: could potentially get a version that returns param fields as well when relevant.
// I would expect this to apply to type fields and var/const fields in either case.
proc getFieldType(type t, param i: int) type

// Get the type of a field in a class or record by name.  Will generate a compilation
// error if a field with that name is not found.
// Note: ditto the above
proc getFieldType(type t, param s: string) type

[ben-albrecht]

For clarity, we can do this today for typed fields:

record R {
  param value: int;
}

var r = new R(1);
type t = r.type;
writeln(t.value); // prints 1

Unfortunately, this doesn't work so well for array type/param fields, due to the layers of abstraction, but there are some ways we might address this, e.g. adding type/param accessor methods for those fields or removing those layers of abstraction for those type/param fields (#12166).

I think #8543 captures this feature request.

[lydia-duncan]

Recording here for visibility - we discussed this in chat. I hadn't realized that the param and type cases worked when arrays weren't involved. My main focus was allowing us to get the type of generic var/const field when the type is instantiated, so I've updated the PR title to reflect that. I would still expect the functions to work for both type/param and generic var/const fields

[bradcray]

If we went with the proposals in the issue text above, I'd probably call them getFieldType() rather than getField() (which sounds to me like it's requesting the value).

That said, I'd prefer to get at the type of the field directly through the language syntax as proposed in issue #11816 rather than needing to use reflection.

[lydia-duncan]

Updated to reflect that suggestion.

I would also prefer to get it directly through the language, but I suspect implementing this is almost trivial so could be a good interim step. If we prioritize the other one quickly, though, I would be fine with closing this without implementing it

[bradcray]

If you were going to invest time implementing one of these two, I'd much rather have you implement the other.

[bradcray]

Looking at this again after some time has passed, while I still prefer the language-based syntax for querying a field's type (which I captured today in #26444), the first of the two routines Lydia proposes here has the benefit of not needing to know a field's name to determine its type (e.g., I could iterate over the fields querying all of their types). Given the time that's passed since we opened this, I'd also rather have the second routine than no capability to query a field's type at all.

I put a user issue tag on this because, cleaning up my inbox at the end of the year, I found such a request (from quite awhile back).