# Design Decisions for this Library ## Ownership Rust embraces the concept of **Ownership** and **Borrowing**. In Rust-wording wlc does *borrow* you *references* of `View`s and `Output`s, while the library itself *owns* them. Since the compiler may not know, when a `View` or `Output` may get deallocated, the lifetime of `View`s and `Output`s passed to the user is limited to the current callback of wlc. There is no way I know of to reflect this relationship any better, although we know a `View` or `Output` will get deallocated after the `view/output_destroyed` callback. ## Weak References Wlc however lets you still store View and Output handles and gracefully handles `NULL`-Pointers of already deallocated Views and Outputs, still expecting you to correctly manage them. Rust gives the opportunity to express this behaviour with Weak-References just like Rc or Arc in the standard library. ## Interior Mutablity Furthermore a View or Output is actually no real pointer just an ID handle by wlc internally. wlc does not expose the actual type, but instead lets us modify the internal state of the Views and Output through well defined function, that take and return by-value. I make the argument, that `View` and `Output` act like e.g. `Cell` and are meant to be used as if they had Interior Mutablity. I have not yet found an exception to this rule that was crutial for functionality. All probablematic functions have been adapted or are not provided by a safe api call. If this turns out to be wrong and potentially unsafe, this library will be rewritten to return `Rc>` and `Rc>` instead. Giving the rather huge circumstances for developers, I will try to avoid this if anyhow possible.