For Unison's record types, it is mentioned:
Creating a value for a Volunteer doesn't involve any additional overhead. There's no requirement for mentioning the field names.
But is it possible to specify the record's fields when creating a new record? I like to do this to improve readability (at the cost of increasing verbosity).
is it possible to specify the record's fields when creating a new record?
If you mean when creating a new instance of a Volunteer value, then no I don't believe that it's currently possible.
I like to do this to improve readability (at the cost of increasing verbosity)
For several reasons, this becomes interesting in the Unison language. Ultimately the data type, its constructors, and its fields are identified by the hash of their implementation. Field names like "age" are essentially just aliases for those hashes. In a particular code base you could potentially have zero, one, or many names associated with the "age" field. So it might not make sense for the compiler to store information about what label you gave each argument, as those are somewhat arbitrary and could change from codebase to codebase.
What might make sense in Unison is not storing the field names that you provided for each argument in the serialized code but instead having the pretty-printer specify field names when printing constructor calls for record types. However, this might be a bit verbose for some people, so you could imagine a world in which Unison has a configurable pretty-printer where users can specify things like "print field names for record type constructor calls as long as there are at least 2 arguments". If Unison were to gain this sort of pretty-printer functionality, the code parser would need to change to accept specifying constructor field names so the pretty-printed constructor calls generated valid code.
As far as I know, even without any pretty-printer changes it would be possible for the parser to accept and check the field names as suggested in the question. But it would most likely throw this information away when storing the code for the reasons that I mentioned before (names could vary in separate code bases).
