In some cases, our lack of support for Refs as members of user defined types can result in ownership problems. In particular, when mapping anonymous functions over the inhabitants of some type t these functions may need to take ownership when doing so is either not necessary or can lead to memory errors such as double frees. In particular, this can happen when currying lambdas, causing more than one lambda to capture the same value.

#997 (comment) has a concrete illustration of this issue.

Should we permit Refs in user defined types? In theory there should be no issue doing so for sumtypes. For product types, the getters become a bit hairy. The current signature of getters is as follows:

getter: my-type-member: (Fn [(Ref MyType)] (Ref t))

When t is a reference, the signature concretizes to:

(Fn [(Ref MyType)] (Ref (Ref t)))

So, if we do want to support this, we'd have to determine precisely what a Ref to a Ref means, what copying it looks like, how (if at all) that affects ownership, etc.

Note: There is already a workaround to this behavior using Ptr types. Ptrs behave similarly to Refs but are unmanaged, ensuring that problems arising from the anonymous function ownership described above can be circumvented--the user just needs to free these pointers manually in the capturing functions.