3 ms·

Well, if the doubtlessly complicated code needed to parse such uncommon borrowing scenarios is only called when such a scenario is found, then it should only af

• wredue 3y ago
  I doubt it all that uncommon. Rust reject A LOT of perfectly valid ideas. Or, at least, it used to. Apparently this has been getting better. If you look around at lifetime recommendations, for a while they were so annoying that most people were saying “just force a copy and don’t use lifetimes”.
  • pornel 3y ago
    There's more nuance to "don’t use lifetimes". Novices typically don't understand the relationship between owning and borrowing, and try to use temporary references where they semantically don't belong (in Rust ownership can't be as ambiguous as in GC languages, and references can't be made out of thin air — they borrow from somewhere that must already be owned/stored somewhere). So often the advice is not "don't use lifetimes, because the borrow checker can't handle them", but rather "don't use lifetimes where an owned value is required" or "don't use lifetimes until you understand how ownership works".
• tedunangst 3y ago
  If the scenarios were that uncommon, it wouldn't be worth fixing. And now that they're accepted, they will undoubtedly proliferate. This is the new common.
  • estebank 3y ago
    Language design and compiler engineering is about tackling progressively smaller niche cases, as the prior ones are addressed. One can draw a line in the sand and say "I'm done, the next niche use case is too niche and the added maintenance burden isn't worth it", but where that line is drawn is different for different products.