Краткий ответ

Метод Result::ok превращает Ok(T) в Some(T), а Err(E) — в None, поэтому значение ошибки E безвозвратно отбрасывается. Такой перевод оправдан только тогда, когда вызывающему коду важен сам факт наличия успешного значения, а причина ошибки не нужна или обрабатывается отдельно.

Исторический контекст

Result и Option разделяют две разные модели результата: Result сообщает об успехе или причине сбоя, а Option — о наличии или отсутствии значения. Явное преобразование между ними позволяет разработчику сознательно выбрать, какую информацию сохранить.

Метод ok решает практическую задачу адаптации API, когда детали ошибки не относятся к дальнейшей логике. При этом Rust не скрывает потерю данных: преобразование выполняется отдельным методом, а не неявно.

Постановка проблемы

Если преобразовать Result<T, E> в Option<T>, вызывающий код больше не сможет отличить ошибку сети от ошибки формата, отсутствия разрешений или любой другой причины. Все варианты Err становятся одним и тем же значением None.

Это может ухудшить диагностику, лишить программу возможности выполнить повторную попытку только для определённых ошибок и затруднить формирование корректного сообщения пользователю. Особенно опасно использовать ok в библиотечном коде или на границе, где причина ошибки ещё может быть полезна.

Подробное решение

Result::ok(self) потребляет исходный Result и выполняет преобразование:

Ok(value) становится Some(value);
Err(error) становится None.

Тип ошибки не переносится в новый тип и не сохраняется внутри Option. Поэтому после вызова ok получить исходную ошибку уже нельзя, если она предварительно не была записана, залогирована или обработана другим способом.

fn cached_port() -> Option<u16> {
    let parsed: Result<u16, ()> = Err(());
    parsed.ok()
}

fn main() {
    assert_eq!(cached_port(), None);
}

Если ошибка нужна вызывающему коду, следует оставить Result или сначала явно обработать её через match, map_err, логирование либо другой механизм. Если требуется только проверить успешность операции, можно использовать is_ok, не создавая Option.

Метод ok потребляет значение. Когда нужно преобразовать заимствованный Result, применяют, например, result.as_ref().ok(): тогда успешное значение будет представлено ссылкой, а исходный Result останется доступен. Это не сохраняет ошибку в полученном Option, но предотвращает перемещение самого результата.

Ситуация из практики

Сервис проверяет, есть ли у пользователя необязательная настройка. Внутри проверка читает файл и возвращает Result<Option<Config>, ReadError>: Ok(None) означает, что настройки нет, а Err — проблему чтения или повреждённые данные.

Вариант с ok упрощает код до Option<Config>, но смешивает отсутствие настройки с ошибкой чтения. Его плюс — простой интерфейс для сценария, где любая ошибка действительно означает «настройка недоступна». Минус — потеря возможности отличить штатное отсутствие файла от сбоя диска или некорректного содержимого.

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

Что кандидаты часто упускают

Вопрос: Чем ok отличается от проверки is_ok с точки зрения владения и результата?

Ответ: ok потребляет Result и возвращает Option<T>, потенциально перемещая успешное значение T. is_ok возвращает только bool и не извлекает значение, поэтому сам Result можно использовать дальше, если соблюдены обычные правила владения. Выбор зависит от того, нужно ли получить успешное значение или только проверить факт успеха.
Вопрос: Можно ли после вызова ok восстановить исходную ошибку из полученного Option?

Ответ: Нет. None не содержит информацию о том, какой именно вариант Err был отброшен. Восстановление возможно только если ошибка была сохранена отдельно до преобразования; сам Option не предоставляет для этого данных.
Вопрос: Почему ok может быть корректен для внутренней эвристики, но плохим выбором для публичного API?

Ответ: Внутренняя эвристика иногда интересуется только успешным результатом: например, пытается найти первый доступный источник и намеренно игнорирует причины неудачи. Публичный API обычно должен сохранить возможность диагностики и принятия разных решений вызывающим кодом. Возврат Option вместо Result скрывает контракт ошибки и вынуждает клиентов трактовать все сбои одинаково, поэтому такое упрощение должно быть частью осознанного дизайна интерфейса.