Allow Refs as members in user defined types

[scolsen]

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.

[scolsen]

If #1012 is merged, Pointer.unsafe-alloc and Pointer.free may be used as workarounds for such cases. Instead of using a Ref as a type member, one uses a Ptr and frees it manually where needed.

[scolsen]

Actually, I haven't tried this yet, but presumably one can also get around this by casting the captured argument of an outer lambda to a reference:

(fn [x] (fn [y] (~f &x y))

Then of course f needs to be typed (Fn [&a b] ...).

It's definitely more work than simply supporting refs in members, but it may not be needed. We should document some of these techniques though, if we wind up not implementing ref members.

[eriksvedang]

My hunch is that we should allow it (it will require struct types to carry a lifetime with them though).

I think the lifetime checker should catch the error even without that feature being implemented, though. So let's fix the bug so that the error is detected first (and add tests for it) and then we can start thinking about how to lift that same restriction.

Does that sound like a good plan?

[scolsen]

Sounds great!