Yes. To be concrete, this is how it could work:
```
defmodule Records do
import Record
defrecord :a, [:x, :y]
defrecord :b, [:x, :y]
end
iex> Records.__records__()
[
a: [:x, :y],
b: [:x, :y]
]
```
Alternatively, this could become `Records.__info__(:records)`. In either case, to make this work I think we'd need `use Record`. Or, we'd have a new `defrecords/1` that defines both multiple records as well as this reflection function.
That's a good point. That's something I was aware of but I guess I haven't thought through the consequences which I think are: if by doing `defrecord` we'd store the fields somewhere (like the :persistent_term solution mentioned) we'll need to handle duplicates by erroring or at least warning.
For this reason, perhaps the other, "stateless", approach mentioned above is more suitable? Users will opt-in to use records so they'll handle conflicts themselves.
I mentioned we can configure inspect behaviour with `IEx.configure`; the `ExUnit.configure(inspect: ...) is not possible (I honestly thought it is) so in order to format records in ExUnit diffs we'd need that.
Even if we configure both IEx and ExUnit to use record definitions, anytime we do `IO.inspect(record)` we'd get non-formatted records output and so to format it we'd have to keep inspect record options everywhere. To take advantage of this feature we'd have to configure it in IEx, ExUnit and all IO.inspect calls; that's explicit but doesn't sound practical.
The only solutions I can think of at the moment are:
1. Going back to magically keeping record fields
2. Currently, we have essentially `Kernel.inspect(term, opts \\ [])`, `IO.inspect(term, opts \\ [])`; if we change it something along the lines of `Kernel.inspect(term, opts \\ default_opts())` and make these defaults configurable we could configure our records just once. So we're back to global state after all.
Neither option is perfect. I'll continue experimenting with this as a standalone library but it seems less likely it could be part of Elixir. What do you think?