High-level proposal: put the borrow-checker for the API service.

[Levitanus]

Well, I'm not an active user of the high-level. But for the next realization, I think it's good to think of lifetime and mutability not in terms of underlying pointers, but in terms of underlying objects.

Several examples of such restrictions:

• If project adds track — this mutates the project. And track should have the lifetime shorter than Project has.
• If Take is constructed (or received from item) — it should have lifetime shorter, than parent item.

This way, the API would be forced to have hierarchic structure, which would guarantee lifetimes of children up to the root plugin context. And, also, it will guarantee memory-safety on exiting of contexts.

I'm thinking, that it would be possible to reduce the amount of checks for validity to the:

• moment of object construction
• and the moment of CSurf call.

The validity checks make a real penalty. In Python version of API they are made in every FFI call and take about of 50% of FFI time. I don't think, this will differ a lot in rust.

[helgoboss]

Thanks for the input. At the moment, the high-level API is intended for my own use only. I already have big structural changes of this API in mind, also including similar changes in terms of validity checks and lifetime considerations as you are suggesting. Until that happens, please hold back posting issues about it. It would probably be better to make reaper-high a private repo but it's too much effort, so all I can do at the moment is to ask people not to look at it or deal with it ;) Thanks.