История изменений

Да, придётся назвать разные функции по разному.

Смысл перегрузки как раз в том, что они названы одинаково и содержатся в оверлоад сете, из которого выбираются в зависимости от полученных аргументов.

который предлагает другие средства для решения таких задач

Нет, он не предлагает никаких средств для решения такой задачи. Раст предлагает использовать трейты, которые хардкодят интерфейс и вынуждают адаптировать код под них.

конструктор с параметрами - это замыкание

Нет конечно. Без исключений нет никакой возможности вернуть ошибку из конструктора, а со статическими функциями вместо конструктора у вас не будет полиморфизма. Точнее, его в принципе не будет без перегрузки, вам придется все сводить к интерфейсам (трейтам). Вы просто предлагаете перенести задачу конструирования валидного T на плечи вызывающего кода, вызываемому же коду придется осуществлять дополнительную проверку на ошибки – она уже была осуществлена в замыкании, либо в теле конструктора. С тем же успехом можно переписать все это дело в

if v.capacity() > v.len() {
    v.push(Bar::new(a));
    // ...
} else {
    // ...
}

Реализуется. Перемещать или нет аргументы конструктора в замыкание решает тот, кто пишет замыкание.

Скажем так, я признаю, что с приседаниями в расте все же можно эмулировать conditional move, но считаю это малоосмысленным. Конструировать просто Bar неинтересно – задача же конструирования произвольного T все еще не решена. Тем более in-place. move по умолчанию это все еще move, пусть и дешевый. Когда в дело включается Pin, все становится еще интереснее.

Перемещать или нет аргументы конструктора в замыкание решает тот, кто пишет замыкание.

Вы привели три варианта, но из них только 1 осуществляет передачу владения куда-то. Кстати, реализовать все сразу я не смогу – Bar::new мономорфен по ссылке, и мне придется использовать, например, Bar::new для move/clone и Bar::from_ref для ссылки.

Дополню про exceptions: в расте очень много где используется Result<T, Box<dyn Error>>. На этом моменте любая выгода Result вместо исключения пропадает, а вот многочисленные проблемы (необходимость раскручивать стек руками, unwrap’ы, «грязный» интерфейс) остаются.

Да, придётся назвать разные функции по разному.

Смысл перегрузки как раз в том, что они названы одинаково и содержатся в оверлоад сете, из которого выбираются в зависимости от полученных аргументов.

который предлагает другие средства для решения таких задач

Нет, он не предлагает никаких средств для решения такой задачи. Раст предлагает использовать трейты, которые хардкодят интерфейс и вынуждают адаптировать код под них.

конструктор с параметрами - это замыкание

Нет конечно. Без исключений нет никакой возможности вернуть ошибку из конструктора, а со статическими функциями вместо конструктора у вас не будет полиморфизма. Вы просто предлагаете перенести задачу конструирования валидного T на плечи вызывающего кода, вызываемому же коду придется осуществлять дополнительную проверку на ошибки – она уже была осуществлена в замыкании, либо в теле конструктора. С тем же успехом можно переписать все это дело в

if v.capacity() > v.len() {
    v.push(Bar::new(a));
    // ...
} else {
    // ...
}

Реализуется. Перемещать или нет аргументы конструктора в замыкание решает тот, кто пишет замыкание.

Скажем так, я признаю, что с приседаниями в расте все же можно эмулировать conditional move, но считаю это малоосмысленным. Конструировать просто Bar неинтересно – задача же конструирования произвольного T все еще не решена. Тем более in-place. move по умолчанию это все еще move, пусть и дешевый. Когда в дело включается Pin, все становится еще интереснее.

Перемещать или нет аргументы конструктора в замыкание решает тот, кто пишет замыкание.

Вы привели три варианта, но из них только 1 осуществляет передачу владения куда-то. Кстати, реализовать все сразу я не смогу – Bar::new мономорфен по ссылке, и мне придется использовать, например, Bar::new для move/clone и Bar::from_ref для ссылки.