ненене, спасибо, я не голодный) Просто суть в том что как раз имплицитность этой фигни очень упрощает жизнь вроде как, так что логика там у них немнооооожечко поехала.

Чутка другая история, лайфтаймы там вообще не нужны где они очевидны А тут типа чтоб не путали со структурами. Я не в восторге от нового синтаксиса, время покажет, мб реально упростит чтение чужого кода (в своем то я и так знаю где трейты, а где структуры, да и боксами пользуюсь ну очень редко)

Блин, все равно придерживаюсь позиции, что "чтобы не путали" можно и нужно делать через адекватное развитие devtools в этом случае. Посмотрим, естессно. Есть предположение, что глобально ничего не изменится, и все в большинстве своем продолжат писать как писали. Технически-то можно.

ненене, спасибо, я не голодный) Просто суть в том что как раз имплицитность этой фигни очень упрощает жизнь вроде как, так что логика там у них немнооооожечко поехала.

Блин, все равно придерживаюсь позиции, что "чтобы не путали" можно и нужно делать через адекватное развитие devtools в этом случае. Посмотрим, естессно. Есть предположение, что глобально ничего не изменится, и все в большинстве своем продолжат писать как писали. Технически-то можно.

А кто путает?

Тебе имена?

Мне интересно, кто не может в чтение растбука

> Additionally, a tweak to the way Cargo deals with targets has landed. Cargo will attempt to automatically discover tests, examples, and binaries within your project. However, sometimes explicit configuration is needed. But the initial implementation had a problem: let’s say that you have two examples, and Cargo is discovering them both. You want to tweak one of them, and so you add a [[example]] to your Cargo.toml to configure its settings. Cargo currently sees that you’ve set one explicitly, and therefore, doesn’t attempt to do any autodetection for the others. That’s quite surprising. Ахахаха, выливать с стейбл карго с недопилиной фичей. Красавцы. Хорошо что хоть не компилятор

так карго же не дорос до 1 )

При чем тут растбук?

Как ты в коде отличишь их?

Поинт же в том,что "люди путают"

Притом, что там описание трейтобжектов нормальное.

Это мне?

fn perimeter(shape: &Shape) -> f32 Это трейтобъект или структура?

Смотря что Shape

"typeof(null) == "object", но это нормально потому что описано на MDN"

С точки зрения интерфейса, тебя это волновать не должно

А это тут причем?

Меня как бы волнует че там, если мне нужен перформанс

Парень, реф на структуру и реф на трейтобжект - это две разные вещи

Парень, реф на структуру и реф на трейтобжект - это две разные вещи

Эм. Ты в сигнатуре интерыейс указываешь, а не требования к перформансу, не тупи

Эм. Ты в сигнатуре интерыейс указываешь, а не требования к перформансу, не тупи

да при том, что не надо косяки языка оправдывать хорошей документацией

А кто путает?

Я хочу знать во что скомпилируется мой код? И видеть явно где используется динамикдиспатч?

Тогда тебе надо указывать, как у тебя аргументы передаются: через регистр, через стоек и т.д

А при чем здесь именно сигнатура? Ты читаешь функцию и видишь это, но что это такое ты не понимаешь

Это дело LLVM уже, не мешай высокоуровневые вещи с байтоебством

Ух, ща ещё полетят предложения писать на асме. И пофиг, что Раст - не настолько низкоуровневый язык, но и не джава

А вообще, в расте диспетчеризация не входит в сигнатуру?

Теперь входит

чё вы придумываете? хотите &Object ? — пишите &Shape хотите &Trait ? — пишите &Shapable

чё вы придумываете? хотите &Object ? — пишите &Shape хотите &Trait ? — пишите &Shapable

чё вы придумываете? хотите &Object ? — пишите &Shape хотите &Trait ? — пишите &Shapable

Вроде и раньше входила, когда impl Trait не было

?