Please provide an example of this.
https://www.reddit.com/r/rust/comments/6kr7o5/lifetimes_nothing_escapes/
(consider in parallel the need for a trait as contributing to the overall 'bloat'.. the 2 things add up, whereas in C++ thats one direct implementation
... coming from C/C++ i'm used to workarounds 
.. and I'm suggesting a #[unsafe(borrowcheck=warnings)] as one such thing, an option to catch more use-cases.
thats why I do have bounds checks in my debug-builds, and many other checks , like NaN checks. The debug build will be used in stress tests, pushing a system to its limits with pathological cases; and you need to do that sort of thing to gain insights for performance aswell. e.g. we made something to automate frame rate testing ('which areas of a scene drop below 60fps'). Some people make a game play itself to train the AI.
to restate the point:
When there are other issues beyond lifetimes to check for: if the code passes those checks, the probability to lifetime problems is vastly lower. As such front loading one set of issues is not always a win
it's almost as if the 'full definition' of the program is somewhere between the code itself , and the tests.
This is why I keep talking about future tooling. It might be the case that an advanced tool or compiler could figure out more of the constraints from broader context, i.e. including the tests. (not just 'here's a function', but 'here's an set of examples of how it can be used.')
doesn't relate to the issue of indices (taking the rust philosophy to it's extreme, foo[i] would have to return an 'Option'? (to make you think about the fact the index could be out of range..)
I'm not saying what Rust does is useless, (and far from it, I fully support making globals unsafe), but what I'm seeing here is a bit like the 'pure OOP' / 'pure FP' zealotry where proponents of one aspect of a language see it as the be all and end all, rather than just one extra tool that , blended with others, provides an incremental step forward.
But as mentioned upthread, let’s talk about concrete usability issues with safe code. Everyone is interested in making that easier to write.
I know that provable safety is going to take markup; thats why (as explained above) sometimes I might want to dodge it. Other times defaults could be changed
One practical suggestion is the idea of a 'temp, a kind of 'opposite of' 'static: [Short lifetime, opposite of 'static?] This is doable now with for<'a> .. but that IMO is less ergonomic than it could be .. you have to look to one side, you've had to introduce another named symbol and you must read the context of useage to determine the intent, from a general purpose construct which is clearly intended to enable more complex cases.
Another suggestion I might make would be to free up the foo[i] syntax for safe or unsafe use, at the minute you'd have to hack it badly with something leaky. Something like this: make the language primitives fn safe_index(&self,i)->&T, unsafe fn unsafe_index(&self,i)->&T , and make the use of the operator user selectable, so if we're doing unsafe indexing most of the time, we can have it... if you really think about it, with [i] being a panic-point it might be something you want to abstract away anyway, so you might want to do some refactoring.. 'lets redefining it as unsafe to help track down all the uses..'