В своем коде, я могу, хоть что-то намудритть, используя try_reserv () в коллекциях, или там где происходит аллокация, что-бы избежать panic. Или использовать, failible_collections например. А что делать, если я использую 3-сторонний crate, где автор этого не сделал ? Т.е получается, что идеология rust вообще склонна "умалчивать" ошибки аллокации, сводя их всегда к panic ? И смысла нет, скурпулезно отслеживать ошибки аллокации в своем коде, если ты все равно используешь crates, где они не проверяются ?
вот прям в тему, правда это про ядро - но суть таже:
Linus Torvalds on Rust support in kernel: "... So if the Rust compiler causes hidden allocations that cannot be caught and returned as errors, then I seriously think that this whole approach needs to be entirely NAK'ed, and the Rust infrastructure - whether at the compiler level or in the kernel wrappers - needs more work..."
можно стандартную библиотеку собирать без флага, отвечающего за неявные ошибки аллокации
тогда крейты, полагающиеся на неявные ошибки аллокации, компилироваться не будут
т. е. почти все крейты
а чем он тут лучше чем раст или c++? Там реально все сторонние либы корректно обрабатывают нехватку памяти?
Я дальше доки не смотрел. Но типо try defer при аллокации это common pattern. Наверно и linter можно настроить чтоб не вызывать без try то что может вернуть ошибку. В целом это не вопрос языка, а скорее best practice из документации. В доке раста несколько я знаю нет рекомендации на ловлю паники при аллокации по дефолту
Обсуждают сегодня