Are there examples where borrow checker stands on your way? Like the mentioned (in comments) way of building a tree. I'm sure there should be really weird edge cases.
Newcomers to Rust often find that the borrow checker _always_ stands in their way, because they haven't internalized the rules yet. I've also spoken with a few frustrated ex-C++ers, who have some sort of pet pattern that works basically all the time, but the borrow checker doesn't like the 'basically.'
In general, any kind of analysis like the borrow checker will reject some valid programs, as it pays to be extra conservative. You then slowly expand the set of accepted programs, until hopefully, it matches the true set of valid programs, without accepting invalid ones.
> I've also spoken with a few frustrated ex-C++ers, who have some sort of pet pattern that works basically all the time, but the borrow checker doesn't like the 'basically.'
It's hard to remember specifics, as this is usually based off of someone jumping into IRC and asking a question about how a certain thing works. They're often very detailed things that require intimate knowledge of implementation details. Or threads like http://www.reddit.com/r/rust/comments/31mgav/what_would_the_... , which isn't really _wrong_, but unions are hard, and so people miss them.
This kind of thing happens any time you transition languages: when I started hacking on Rust, I was trying to figure out how to do the metaprogramming shenanigans that Ruby lets me do. Ironically, Rust's metaprogramming features are my biggest weakness as a Rust programmer, I don't really write my own macros.
> In general, any kind of analysis like the borrow checker will reject some valid programs, as it pays to be extra conservative. You then slowly expand the set of accepted programs, until hopefully, it matches the true set of valid programs, without accepting invalid ones.
I'm wondering, is this possible in principle?
Context: I'm thinking in terms of sound-and-decidable type-checking conservativeness [0], but perhaps that's a bad way of thinking about this? Perhaps borrow-checking is a special-enough case of type-checking that somehow isn't afflicted by this (how?) or gives up the soundness (does it?)?
Strictly speaking, [string UTF8String] is equivalent to '((const char <star>(<star>)(id, SEL))objc_msgSend)(string, selector)'. Since objc_msgSend is vararg function, it will promote it's arguments, so for example method taking float will be called with double. Casting to a proper function type works around that.
Oh good point, I hadn't considered vararg promotion!
Do you know if casting to a function also make objc_msgSend_stret and objc_msgSend_fpret unnecessary? I haven't yet worked with any methods that return structs or floating point values, so I haven't had to deal with them yet.
As you discovered, _stret/_fpret remain necessary.
objc_msgSend()'s type is not expressible in C; the only time it is correct to call objc_msgSend without a cast is when calling a method IMP with the literal vararg type of id (*method) (id self, SEL sel, ...);
