Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.
Это только чтоб программист явно соображал что делает? С другой стороны для тривиальных ф-ций оно само выводит. Какой-то сути не уловил очевидно.

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

Здравствуйте, glap, Вы писали:

G>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.
G>Это только чтоб программист явно соображал что делает? С другой стороны для тривиальных ф-ций оно само выводит. Какой-то сути не уловил очевидно.

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

В холиварных ветках столько экспертов по Расту, а с таким пустяком совсем никого

Здравствуйте, glap, Вы писали:

G>В холиварных ветках столько "экспертов" по Расту, а с таким пустяком совсем никого

Исправил

Здравствуйте, glap, Вы писали:

G>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.
G>Это только чтоб программист явно соображал что делает? С другой стороны для тривиальных ф-ций оно само выводит. Какой-то сути не уловил очевидно.

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

Я так и не понял в чём вопрос.
Зачем указывать время жизни или почему компилятор умеет выводить его самостоятельно ?

Как бы логика то прослеживается

fn first_word(s: &str) -> &str {

Равнозначно

fn first_word<'a>(s: &'a str) -> &'a str {

А это

fn longest(x: &str, y: &str) -> &str {

Равнозначно

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-elision

Здравствуйте, _NN_, Вы писали:

_NN>Я так и не понял в чём вопрос.
_NN>Зачем указывать время жизни или почему компилятор умеет выводить его самостоятельно ?

Значит я плохо сформулировал. Сведу например к этому:

Есть ли ситуации где компилятор принципиально не может вывести время жизни объектов?

Здравствуйте, glap, Вы писали:

G>Здравствуйте, _NN_, Вы писали:

_NN>>Я так и не понял в чём вопрос.
_NN>>Зачем указывать время жизни или почему компилятор умеет выводить его самостоятельно ?

G>Значит я плохо сформулировал. Сведу например к этому:

G>Есть ли ситуации где компилятор принципиально не может вывести время жизни объектов?

Например в объявлении структуры с ссылками нужно явно указать:

struct A
{
   a: &str
}

Compiling playground v0.0.1 (/playground)
error[E0106]: missing lifetime specifier
--> src/lib.rs:3:7
|
3 | a: &str
| ^ expected named lifetime parameter
|
help: consider introducing a named lifetime parameter
|
1 ~ struct A<'a>
2 | {
3 ~ a: &'a str
|

For more information about this error, try `rustc --explain E0106`.

https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-annotations-in-struct-definitions

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, glap, Вы писали:

G>>Значит я плохо сформулировал. Сведу например к этому:

G>>Есть ли ситуации где компилятор принципиально не может вывести время жизни объектов?

_NN>Например в объявлении структуры с ссылками нужно явно указать:

Почему при использовании нельзя автоматически вывести лучшее время жизни для этой ссылки? Исходя из контекста

Здравствуйте, glap, Вы писали:

_NN>>Например в объявлении структуры с ссылками нужно явно указать:
G>Почему при использовании нельзя автоматически вывести лучшее время жизни для этой ссылки? Исходя из контекста
Польза от любого автоматического вывода может быть только, если заранее известны намерения или ограничения. Тогда ими можно воспользоваться. В противном случае, можно всё что угодно свести к void*/object/добавьте себе по контексту, и быть формально правым, но абсолютно бесполезным на практике.

Здравствуйте, glap, Вы писали:

G>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.

Чтобы во время инкрементальной компиляции при пересборке реализации функции не надо было перепроверять все места, что её вызывают?

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, glap, Вы писали:

G>>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.

TB>Чтобы во время инкрементальной компиляции при пересборке реализации функции не надо было перепроверять все места, что её вызывают?

Т.е. мы облегчаем работу компилятора? Больше интересно с точки зрения дизайна языка.

Здравствуйте, Mystic Artifact, Вы писали:

MA>Здравствуйте, glap, Вы писали:

_NN>>>Например в объявлении структуры с ссылками нужно явно указать:
G>>Почему при использовании нельзя автоматически вывести лучшее время жизни для этой ссылки? Исходя из контекста
MA> Польза от любого автоматического вывода может быть только, если заранее известны намерения или ограничения. Тогда ими можно воспользоваться. В противном случае, можно всё что угодно свести к void*/object/добавьте себе по контексту, и быть формально правым, но абсолютно бесполезным на практике.

Типизация всё же нужна и по многим другим причинам. Скажем на неё завязана бизнес логика и её чтение существенно облегчается при явном указании типов. А есть ли пример когда явное указание времени жизни даёт преимущество перед автоматическим выводом (автопоиском кратчейшего времени жизни)?

Здравствуйте, glap, Вы писали:

G>Т.е. мы облегчаем работу компилятора?

Т.е. мы делаем вообще возможной инкрементальную сборку.
А значит, облегчаем жизнь и себе.

G>Больше интересно с точки зрения дизайна языка.
Можно и типы не указывать, ведь компилятор же всё может вывести. Сделать каждую функцию шаблонной с утиной типизацией. Только на практике это хорошо только для write-only кода, потому что когда ты сталкиваешься с ошибкой "в каком месте так вышло, что для этой залупы вывелся такой тип, а не такой", ради которой тебе приходится перелопачивать весь проект, а не одну функцию (и всё это на фоне гораздо более долгой сборки), то начинаешь понимать, что лучше как раз максимально много отметок оставлять в явном виде. По этой причине и auto в С++ — зло.

Так вот, с лайфтаймами то же самое. В более-менее сложной логике ты родишь, пытаясь понять, почему лайфтайм вывелся не тот, какой тебе казалось бы должен был вывестись.

Здравствуйте, glap, Вы писали:

G>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.
Проблема в том, что без аннотаций в сигнатуре, при изменении кода в теле функции может сломаться код-потребитель. Причём совершенно в другом crate'е.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, glap, Вы писали:

G>>Т.е. мы облегчаем работу компилятора?

TB>Т.е. мы делаем вообще возможной инкрементальную сборку.
TB>А значит, облегчаем жизнь и себе.

Нууу а разве нельзя из изменений в теле ф-ции разобраться автоматически, что изменение как-то повлияло на время жизни или нет. Отсечёт почти все случаи скорее всего?

TB>Так вот, с лайфтаймами то же самое. В более-менее сложной логике ты родишь, пытаясь понять, почему лайфтайм вывелся не тот, какой тебе казалось бы должен был вывестись.

Если не сильно трудно, то можно пример такой ситуации?

А так может быть нужна поддержка на стороне ИДЕ? Если есть такие проблемы, то пусть построит какое-то красивое дерево из которого всё сразу ясно. Место смерти объектов тоже можно как-то размечать. Вся эта информация уже есть у разборщика.

Из того, что я вижу (могу ошибаться, т.к. не пишу на самом деле ничего на нём), то тот же let используется почти везде без аннотации типа. Да и типизация всё же сильно больше важна для бизнес логики чем знание о том сколько прожил объект. Разве нет?

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, glap, Вы писали:

G>>Ради праздного интереса полистал учебник по Расту. Так сходу не могу врубиться зачем нужно вручную связывать время жизни объектов в сигнатуре ф-ций. Компилятор может сам отследить и по всем ветвлениям вывести для всех данных и вызовов.
C>Проблема в том, что без аннотаций в сигнатуре, при изменении кода в теле функции может сломаться код-потребитель. Причём совершенно в другом crate'е.

Так компилятор то будет знать, что сигнатура в реальности изменилась. Это можно разметить при экспорте.
Если явно изменить сигнатуру, то тоже всё сломается

Здравствуйте, glap, Вы писали:

G>Нууу а разве нельзя из изменений в теле ф-ции разобраться автоматически, что изменение как-то повлияло на время жизни или нет. Отсечёт почти все случаи скорее всего?

Можно конечно увидеть, что в такой-то функции foo поменялся лайфтайм, значит надо перепарсить заново функцию bar из другого крейта, потому что она вызывает foo, значит надо перепарсить baz ещё из какого-то крейта, потому что она вызывает bar итд...
Инкрементальная сборка идёт нафиг?

G>Если не сильно трудно, то можно пример такой ситуации?

Трудно. Поверь на опыте — чем больше подробностей указываем компилятору, тем предсказуемее результат компиляции.

G>А так может быть нужна поддержка на стороне ИДЕ? Если есть такие проблемы, то пусть построит какое-то красивое дерево из которого всё сразу ясно. Место смерти объектов тоже можно как-то размечать. Вся эта информация уже есть у разборщика.

И при ошибке компиляции тебе придётся изучать всё дерево целиков, а не только тело одной функции.

G>Из того, что я вижу (могу ошибаться, т.к. не пишу на самом деле ничего на нём), то тот же let используется почти везде без аннотации типа. Да и типизация всё же сильно больше важна для бизнес логики чем знание о том сколько прожил объект. Разве нет?

Знание о времени жизни нужно для того, чтобы понять, почему компилятор в таком-то месте увидел ошибку.

Здравствуйте, glap, Вы писали:

C>>Проблема в том, что без аннотаций в сигнатуре, при изменении кода в теле функции может сломаться код-потребитель. Причём совершенно в другом crate'е.
G>Так компилятор то будет знать, что сигнатура в реальности изменилась. Это можно разметить при экспорте.
Откуда потребитель функции будет об этом знать? Был код, который работал. После обновления — вдруг перестал, при этом никакие интерфейсные функции внешне не менялись.

G>Если явно изменить сигнатуру, то тоже всё сломается
Да, но это будет явное изменение в интерфейсе.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, glap, Вы писали:

C>>>Проблема в том, что без аннотаций в сигнатуре, при изменении кода в теле функции может сломаться код-потребитель. Причём совершенно в другом crate'е.
G>>Так компилятор то будет знать, что сигнатура в реальности изменилась. Это можно разметить при экспорте.
C>Откуда потребитель функции будет об этом знать? Был код, который работал. После обновления — вдруг перестал, при этом никакие интерфейсные функции внешне не менялись.

Соглашусь. Всё же всё должно быть ясно из голого кода.

Из ответов более менее составил себе картину. Всем спасибо!

Здравствуйте, glap, Вы писали:

G>Если не сильно трудно, то можно пример такой ситуации?

Вижу привели уже достаточно аргументов, но и это само по себе мне кажется достаточно важным. Например, у нас есть функция с сигнатурой fn(&str, &str) -> &str. В зависимости от того, что функция делает лайфтаймы будут разными. Может мы хотим вернуть более длинную строку, а может подстроку первого аргумента. Эта информация в сигнатуре будет полезна и тому, кто читает код, а не только компилятору.

Ещё несколько популярных заблуждений про лайфтамы описаны вот тут: https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md