RFC: Single-entry / multiple-exit regions for borrows

[Rendered](https://github.com/zwarich/rfcs/blob/seme-regions/active/0000-seme-regions.md)
Is there a reason you want to go with this specific evaluation order? A Google search did not produce any documentation on this.

Your workaround would work for simple cases. It will break apart unpredictably at more complex cases. Such unpredictably would really frustrate the users.
What about debug mode with optimizations disabled? Would it still reorder stuff?
 
What to do if you need a mutable borrow to evaluate parameters:

    obj.paint(obj.x, obj.y, obj.getCachedOrDownloadImage())

Or a mutable borrow to get to the function to call:

    obj.getSomethingMutablyBorrowsObj().someFunction(obj.name)  

To generalize self is just another parameter. If more than one parameter needs to borrow ob after a mutable borrow is done, there is no way out.

We can either define an order that would work for most cases or leave it undefined and let compiler to figure out if there is a evaluation order that complies with borrow restrictions.

It's much more likely that self will need a mutable borrow of obj than the other parameters. 
Thus I'm for evaluating self last to allow more code to work.