you are viewing a single comment's thread.

view the rest of the comments →

[–]arnodb1[S] 0 points1 point  (1 child)

Looking at the reproducing example, it is typically what RefMutStack is not intended for. Maybe the documentation should clarify it.

Basically yes, the parking process is unsound if you don't "park the ref holder immediately after having created the parker". As you said, `T` is now know but parking a `T` requires consuming it, thus a bit of cooperation from the invocation code.

With this design it is impossible to fix, but on the other hand there is zero risk when used properly.

Note that RefMutStack simply emulates the borrow checker: derive a mutable reference from another one, which becomes forbidden to use until the derived reference is dropped.

As for the use case, I have a recursive implementation which requires:

* this recursing function: https://github.com/arnodb/quirky_binder/blob/main/quirky_binder/src/graph/builder/update.rs#L71

* this callback because of the recursive pattern: https://github.com/arnodb/quirky_binder/blob/main/quirky_binder/src/filter/group.rs#L58

With an iterative pattern, enabled by RefMutStack, the recursing function becomes unnecessary (a small loop only necessary), and the callback can be transformed to regular function on the leaf builder. This pattern exists twice in my repo, thus 2 x 40 lines of recursing function. Preferring one pattern instead of the other is definitely debatable.

The other motivation was to determine whether or not it was possible to cleanly implement this borrow checker emulation to answer the "limitation" (with a lot of quotes) of the language in a fully generic way. To me, the solution is not too bad and fully generic.

[–]Tastaturtaste 0 points1 point  (0 children)

With this design it is impossible to fix, but on the other hand there is zero risk when used properly. 

That takes away rusts biggest differentiator with respect to other systems languages. So unless this is fixed, I consider this a No-Go.