@rfcbot fcp слияние

Член команды @withoutboats предложил объединить это. Следующим шагом является проверка остальными членами команды, отмеченными тегами:

• [x] @Centril
• [x] @cramertj
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [] @pnkfelix
• [x] @scottmcm
• [x] @withoutboats

Обеспокоенность:

• реализация-работа-блокировка-стабилизация решена https://github.com/rust-lang/rust/issues/62149#issuecomment -517418610

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

См. Этот документ для получения информации о том, какие команды могут дать мне члены команды, отмеченные тегами.

(Просто зарегистрируйте существующие блокираторы в отчете выше, чтобы убедиться, что они не соскользнут)

@rfcbot касается реализации-работы-блокировки-стабилизации

Член команды ... предложил объединить это

Как можно объединить проблему Github (а не пулреквест)?

@vi Бот немного глуповат и не проверяет, проблема это или PR :) Здесь вы можете заменить «объединить» на «принять».

Вау, спасибо за исчерпывающее резюме! Я слежу лишь косвенно, но полностью уверен, что вы в курсе всего.

@rfcbot просмотрел

Можно ли явно добавить «Проблемы Triage AsyncAwait-Unclear» к блокираторам стабилизации (и / или зарегистрировать беспокойство по этому поводу)?

У меня есть https://github.com/rust-lang/rust/issues/60414, который я считаю важным (очевидно, это моя ошибка: p), и я хотел бы, по крайней мере, явно отложить его до стабилизации :)

Я просто хотел бы выразить благодарность сообществу за усилия, которые команды Rust вложили в эту функцию! Было много разработок, обсуждений и несколько сбоев в общении, но, по крайней мере, я и, надеюсь, многие другие уверены, что благодаря всему этому мы нашли лучшее решение для Rust. : тада:

(Тем не менее, я хотел бы видеть упоминание о проблемах с мостом к API-интерфейсам системы на основе завершения и асинхронной отмены в будущих возможностях. TL; DR им по-прежнему приходится передавать собственные буферы. Это проблема библиотеки, но одна с упоминанием.)

Я также хотел бы увидеть упоминание о проблемах с API на основе завершения. (см. этот внутренний поток для контекста). Принимая во внимание IOCP и введение io_uring , который может стать Пути для асинхронного ввода-вывода в Linux, я думаю, что важно иметь четкий путь для их обработки. Идеи гипотетического асинхронного отбрасывания IIUC не могут быть реализованы безопасно, а передача собственных буферов будет менее удобной и потенциально менее производительной (например, из-за худшего местоположения или из-за дополнительных копий).

@newpavlov Я реализовал аналогичные вещи для Fuchsia, и это вполне возможно обойтись без async drop. Для этого есть несколько различных способов, например использование пула ресурсов, при котором для получения ресурса потенциально необходимо дождаться завершения некоторых работ по очистке старых ресурсов. Текущий Futures API может использоваться и использовался для эффективного решения этих проблем в производственных системах.

Однако эта проблема касается стабилизации async / await, которая ортогональна дизайну Futures API, который уже стабилизировался. Не стесняйтесь задавать дополнительные вопросы или открывать вопрос для обсуждения по репо futures-rs.

@Ekleog

Можно ли явно добавить «Проблемы Triage AsyncAwait-Unclear» к блокираторам стабилизации (и / или зарегистрировать беспокойство по этому поводу)?

Ага, мы этим занимаемся каждую неделю. Запишите эту конкретную проблему (# 60414), я считаю ее важной и хотел бы, чтобы она была исправлена, но мы еще не смогли решить, должна ли она блокировать стабилизацию, тем более что это уже наблюдается в -> impl Trait functions.

@cramertj Спасибо! Я думаю, что проблема # 60414 в основном заключается в том, что «ошибка может возникнуть очень быстро сейчас», в то время как с -> impl Trait похоже, что никто даже не заметил ее раньше - тогда ничего страшного, если она все равно будет отложена, некоторые проблемы придется :) (FWIW это возникло в естественном коде в функции, где я возвращаю как () в одном месте, и T::Assoc в другом месте, из-за чего IIRC не смог заставить его скомпилировать - не проверял код с момента открытия # 60414, так что, возможно, я ошибаюсь)

@Ekleog Да, в этом есть смысл! Я определенно понимаю, почему это было бы больно - я создал поток zulip, чтобы больше погрузиться в эту конкретную проблему.

РЕДАКТИРОВАТЬ: неважно, я пропустил цель 1.38 .

@cramertj

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

Разве они не менее эффективны по сравнению с хранением буферов как части будущего состояния? Меня больше всего беспокоит то, что текущий дизайн не будет иметь нулевых затрат (в том смысле, что вы сможете создать более эффективный код, отказавшись async абстракции

@герцог

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

Эта проблема нацелена на 1.38, см. Первую строку описания.

@huxi спасибо, я это пропустил. Отредактировал свой комментарий.

@newpavlov

Разве они не менее эффективны по сравнению с хранением буферов как части будущего состояния? Меня больше всего беспокоит то, что текущий дизайн не будет иметь нулевую стоимость (в том смысле, что вы сможете создать более эффективный код, отказавшись от асинхронной абстракции) и менее эргономичным для API на основе завершения, и нет четкого способа исправить Это. Это ни в коем случае не шумиха, но я думаю, что важно не забывать о подобных недостатках в дизайне, поэтому просьба упомянуть об этом в OP.

Нет, не обязательно, но давайте перенесем это обсуждение в отдельную тему, поскольку она не связана со стабилизацией async / await.

(Тем не менее, я хотел бы видеть упоминание о проблемах с мостом к API-интерфейсам системы на основе завершения и асинхронной отмены в будущих возможностях. TL; DR им по-прежнему приходится передавать собственные буферы. Это проблема библиотеки, но одна с упоминанием.)

Я также хотел бы увидеть упоминание о проблемах с API на основе завершения. (см. этот внутренний поток для контекста). Учитывая IOCP и введение io_uring, которое может стать путем для асинхронного ввода-вывода в Linux, я думаю, что важно иметь четкий путь для их обработки.

Я согласен с Тейлором в том, что обсуждение проектов API в этом проблемном пространстве было бы не по теме, но я хочу затронуть один конкретный аспект этих комментариев (и это обсуждение io_uring в целом), который имеет отношение к стабилизации async / await: проблема сроки.

io_uring - это интерфейс, который появится в Linux в этом , 2019 году. Проект Rust работает над абстракцией фьючерсов с 2015 года, четыре года назад. Фундаментальный выбор в пользу опроса, основанного на API, основанного на завершении, произошел в 2015 и 2016 годах. На RustCamp в 2015 году Карл Лерш рассказал о том, почему он сделал этот выбор в mio, базовой абстракции ввода-вывода. В этом сообщении в блоге в 2016 году Аарон Турон рассказал о преимуществах создания абстракций более высокого уровня. Эти решения были приняты очень давно, и без них мы не смогли бы дойти до того, что мы сейчас находимся.

Предложения о том, что нам следует пересмотреть нашу базовую модель будущего, - это предложения о том, что нам следует вернуться к состоянию, в котором мы были 3 или 4 года назад, и начать с этого момента. Какого рода абстракция могла бы охватывать модель ввода-вывода на основе завершения без введения накладных расходов для примитивов более высокого уровня, как описал Аарон? Как мы сопоставим эту модель с синтаксисом, который позволяет пользователям писать «обычные аннотации Rust + второстепенные», как это делает async / await? Как мы сможем справиться с интеграцией этого в нашу модель памяти, как мы это сделали для этих конечных автоматов с помощью вывода? Попытка дать ответы на эти вопросы была бы не по теме этой темы; Дело в том, что ответить на них и доказать правильность ответов - это работа. То, что до сих пор составляет солидное десятилетие трудовых лет между разными участниками, придется переделывать снова.

Цель Rust - выпустить продукт, который люди смогут использовать, а это значит, что мы должны его выпустить . Мы не всегда можем перестать смотреть в будущее на то, что может стать большим событием в следующем году, и перезапускать наш процесс проектирования, чтобы учесть это. Мы делаем все, что в наших силах, исходя из ситуации, в которой мы оказались. Очевидно, может быть неприятно чувствовать, что мы едва пропустили что-то важное, но в настоящее время у нас нет полного представления: а) о том, какой лучший результат для обработки io_uring, б) насколько важным будет io_uring для экосистемы в целом. На основании этого мы не можем отменить 4 года работы.

Подобные, возможно, даже более серьезные ограничения Rust уже существуют в других областях. Хочу выделить одну, на которую я смотрел с Ником Фицджеральдом прошлой осенью: интеграция с wasm GC. План обработки управляемых объектов в wasm состоит в том, чтобы по существу сегментировать пространство памяти, чтобы они существовали в отдельном адресном пространстве от неуправляемых объектов (действительно, когда-нибудь во многих отдельных адресных пространствах). Модель памяти Rust просто не предназначена для обработки отдельных адресных пространств, и любой небезопасный код, который сегодня имеет дело с кучей памяти, предполагает, что существует только одно адресное пространство. Хотя мы набросали как критические, так и технически неразрывные, но чрезвычайно разрушительные технические решения, наиболее вероятный путь вперед - это признать, что наша история с wasm GC может быть не совсем оптимальной , потому что мы имеем дело с ограничениями Rust как это существует.

Интересный аспект, который мы здесь стабилизируем, заключается в том, что мы делаем самодостаточные структуры доступными из безопасного кода. Что делает это интересным, так это то, что в Pin<&mut SelfReferentialGenerator> у нас есть изменяемая ссылка (хранящаяся как поле в Pin ), указывающая на все состояние генератора, и у нас есть указатель внутри этого состояния, указывающий в другой кусок государства. Этот внутренний указатель является псевдонимом изменяемой ссылки!

Насколько мне известно, изменяемая ссылка не используется для фактического доступа к той части памяти, на которую указывает указатель на другое поле. (В частности, не существует метода clone или такого, который мог бы читать поле указателя с использованием любого другого указателя, кроме самореферентного.) Тем не менее, это становится все ближе к наличию изменяемого псевдонима ссылки с нечто большее, чем что-либо еще в основной экосистеме, в частности все, что поставляется с самим rustc. «Линия», по которой мы здесь движемся, становится очень тонкой, и мы должны быть осторожны, чтобы не потерять все эти прекрасные оптимизации, которые мы хотим сделать на основе изменяемых ссылок.

Вероятно, на данный момент мы мало что можем с этим поделать, в частности, потому что Pin уже стабилен, но я считаю, что стоит отметить, что это значительно усложнит все правила, для которых разрешено использование псевдонимов и который не. Если вы думали, что Stacked Borrows - это сложно, приготовьтесь к тому, что ситуация ухудшится.

Копия https://github.com/rust-lang/unsafe-code-guidelines/issues/148

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

Люди говорили о том, чтобы все эти типы сопрограмм реализовывали Debug , похоже, что этот разговор также должен включать рекомендации по небезопасному коду, чтобы быть уверенным, что безопасно отлаживать печать.

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

Действительно. Такая реализация Debug , если она печатает поля с самими ссылками, скорее всего, запретит оптимизацию на основе ссылок на уровне MIR внутри генераторов.

Обновление по блокираторам:

Оба блокиратора высокого уровня достигли большого прогресса и, возможно, оба уже закончили (?). Было бы здорово получить дополнительную информацию от @cramertj @tmandry и @nikomatsakis :

• Проблема с несколькими сроками жизни должна была быть исправлена ​​с помощью # 61775.
• Вопрос размера более неоднозначен; всегда будет больше оптимизаций, но я думаю, что низко висящий плод отказа от очевидного экспоненциального увеличения ножных ружей в основном решен?

Это оставляет документацию и тестирование как основные препятствия для стабилизации этой функции. @Centril неоднократно выражал озабоченность по поводу того, что эта функция недостаточно хорошо протестирована или отполирована; @Centril есть ли где-нибудь, где вы перечислили конкретные проблемы, которые можно было бы

Не уверен, водит ли кто документацию. Любой, кто хочет сосредоточиться на улучшении древовидной документации в книге, справочнике и т. Д., Окажет большую услугу! Документация вне дерева, например, в репозитории Futures или areweasyncyet, имеет немного дополнительного времени.

На сегодняшний день у нас есть 6 недель до закрытия бета-версии, поэтому предположим, что у нас есть 4 недели (до 1 августа), чтобы сделать все это, чтобы быть уверенными, что мы не упустим 1.38.

Вопрос размера более неоднозначен; всегда будет больше оптимизаций, но я думаю, что низко висящий плод отказа от очевидного экспоненциального увеличения ножных ружей в основном решен?

Думаю, да, и некоторые другие недавно закрылись; но есть и другие проблемы с блокировкой .

@Centril есть ли где-нибудь, где вы перечислили конкретные проблемы, которые можно было бы

Там есть папка со списком вещей, которые мы хотели протестировать, и https://github.com/rust-lang/rust/issues/62121. Помимо этого, я постараюсь как можно скорее пересмотреть области, которые, по моему мнению, недостаточно протестированы. Тем не менее, некоторые области сейчас довольно хорошо протестированы.

Любой, кто хочет сосредоточиться на улучшении древовидной документации в книге, справочнике и т. Д., Окажет большую услугу!

Действительно; Буду рад пересмотреть PR к ссылке. Также cc @ehuss.

Я также хотел бы переместить async unsafe fn из MVP в его собственные ворота функций, потому что я думаю: а) он мало используется, б) он не особенно хорошо протестирован, в) он якобы ведет себя странно, потому что .await point - это не то место, где вы пишете unsafe { ... } и это понятно из "дырявой реализации POV", но не столько из POV эффектов, d) он мало обсуждался и не был включен в RFC ни этот отчет, и д) мы сделали это с помощью const fn и он работал нормально. (Я могу написать PR функции ворот)

Я нормально отношусь к дестабилизации async unsafe fn , хотя я скептически отношусь к тому, что мы закончим с другим дизайном, чем нынешний. Но кажется разумным дать нам время разобраться в этом!

Я создал https://github.com/rust-lang/rust/issues/62500 для перемещения async unsafe fn в отдельный элемент доступа и внес его в список блокировщиков. Думаю, нам, вероятно, также следует создать проблему с правильным отслеживанием.

Я очень скептически отношусь к тому, что мы достигнем другого дизайна для async unsafe fn и удивлен решением не включать его в начальный раунд стабилизации. Я написал несколько async fn s, которые небезопасны и, я полагаю, сделают их async fn really_this_function_is_unsafe() или что-то в этом роде. Это похоже на регресс базовых ожиданий пользователей Rust в плане возможности определять функции, для вызова которых требуется unsafe { ... } . Еще одно окно функций будет способствовать созданию впечатления, что async / await незавершено.

@cramertj, кажется, мы должны обсудить! Я создал для него тему Zulip , чтобы не допустить чрезмерной перегрузки этой проблемы с отслеживанием.

Что касается будущих размеров, оптимизированы случаи, влияющие на каждую точку await . Последняя оставшаяся проблема, о которой я знаю, - это # ​​59087, где любое заимствование будущего до ожидания может удвоить размер, выделенный для этого будущего. Это довольно прискорбно, но все же немного лучше, чем мы были раньше.

У меня есть представление о том, как исправить эту проблему, но если это не встречается чаще, чем я представляю, вероятно, это не должно быть препятствием для стабильного MVP.

Тем не менее, мне все еще нужно посмотреть на влияние этих оптимизаций на Fuchsia (это было заблокировано некоторое время, но должно исчезнуть сегодня или завтра). Вполне возможно, что мы обнаружим больше случаев, и нам нужно будет решить, следует ли какой-либо из них блокировать.

@cramertj (Напоминание: я использую async / await и хочу, чтобы он стабилизировался как можно скорее) Ваш аргумент звучит как аргумент в пользу задержки стабилизации async / await, а не для стабилизации async unsafe прямо сейчас без надлежащих экспериментов и размышлений.

Тем более, что он не был включен в RFC, и потенциально может вызвать еще один дерьмовый шторм «имплицитный признак в позиции аргумента», если он будет вытеснен таким образом.

[Боковое примечание, которое не заслуживает здесь обсуждения: «Еще одна функция создает впечатление, что async / await не завершена», я обнаруживал ошибку каждые несколько часов использования async / await, распространяемую немногими месяцы, законно необходимые команде rustc для их исправления, и это то, что заставляет меня говорить, что это незавершенное. Последняя проблема была исправлена ​​несколько дней назад, и я очень надеюсь, что не обнаружу еще одну, когда снова попытаюсь скомпилировать свой код с помощью более новой версии rustc, но ...]

Ваш аргумент звучит как аргумент в пользу отсрочки стабилизации async / await, а не для стабилизации небезопасного асинхронного режима прямо сейчас без надлежащих экспериментов и размышлений.

Нет, это не аргумент в пользу этого. Я считаю, что async unsafe готов, и не могу представить для него другой дизайн. Я считаю, что если его не включить в этот первоначальный выпуск, это приведет только к негативным последствиям. Я не верю, что отсрочка async / await в целом или async unsafe частности не даст лучшего результата.

не могу представить для этого другого дизайна

Альтернативный дизайн, хотя и тот, который определенно требует сложных расширений: async unsafe fn - это unsafe для .await , а не call() . Причина этого в том, что _не может быть сделано ничего опасного_ в точке, где вызывается async fn и создает impl Future . Все, что делает этот шаг, - это помещает данные в структуру (фактически, все async fn - это const для вызова). Фактическая точка опасности - продвигаться в будущее с помощью poll .

(imho, если unsafe происходит немедленно, unsafe async fn имеет больше смысла, а если unsafe задерживается, async unsafe fn имеет больше смысла.)

Конечно, если мы никогда не сможем сказать, например, unsafe Future где все методы Future небезопасны для вызова, тогда «поднятие» unsafe на создание impl Future , и контракт этого unsafe заключается в безопасном использовании полученного будущего. Но это также можно почти тривиально сделать без unsafe async fn , просто «обессахаривая» вручную в блок async : unsafe fn os_stuff() -> impl Future { async { .. } } .

Вдобавок к этому, однако, возникает вопрос, существует ли на самом деле способ иметь инварианты, которые необходимо сохранять после запуска poll ing, которые не нужно сохранять при создании. В Rust часто используется конструктор unsafe для безопасного типа (например, Vec::from_raw_parts ). Но главное здесь то, что после построения тип _ нельзя_ неправильно использовать; область действия unsafe завершена. Такая оценка небезопасности является ключом к гарантиям Rust. Если вы введете unsafe async fn который упаковывает безопасный impl Future с требованиями к тому, как и когда он опрашивается, а затем передаете его в безопасный код, этот безопасный код внезапно оказывается внутри вашего небезопасного барьера. И это _ очень_ вероятно произойдет, как только вы воспользуетесь этим будущим любым способом, кроме немедленного его ожидания, поскольку оно, скорее всего, будет проходить через _ некоторый_ внешний комбинатор.

Я предполагаю, что TL; DR этого заключается в том, что определенно есть углы async unsafe fn которые следует обсудить должным образом, прежде чем стабилизировать его, особенно с потенциальным введением направления const Trait (у меня есть черновик блога сообщение об обобщении этого на "систему слабых" эффектов "с любым ключевым словом fn ). Тем не менее, unsafe async fn может быть достаточно ясным относительно «порядка» / «позиционирования» unsafe для стабилизации.

Я считаю, что основанная на эффектах черта unsafe Future не только недоступна для всего, что мы знаем, как выразить на языке или компиляторе сегодня, но что в конечном итоге это будет худший дизайн из-за дополнительного эффекта - полиморфизм, который потребуются комбинаторам.

Ничего небезопасного сделать нельзя в точке, где вызывается async fn и создает имплицитное будущее. Все, что делает этот шаг, - это помещает данные в структуру (фактически, все async fn вызываются как const). Фактическая точка небезопасности - опросы в будущее.

Это правда, что, поскольку async fn не может запускать какой-либо пользовательский код до .await ed, любое неопределенное поведение, вероятно, будет отложено до вызова .await . Я думаю, однако, что есть важное различие между точкой UB и точкой unsafe ty. Фактическая точка unsafe ty - это то место, где автор API решает, что пользователь должен пообещать, что выполняется набор нестатически проверяемых инвариантов, даже если результат нарушения этих инвариантов не приведет к UB пока позже в другом безопасном коде. Одним из распространенных примеров этого является функция unsafe для создания значения, реализующего признак с помощью безопасных методов (именно то, что это такое). Я видел, как это использовалось, чтобы гарантировать, что, например, типы, реализующие Visitor -trait, реализации которых полагаются на инварианты unsafe могут быть надежно использованы, требуя unsafe для создания типа. Другие примеры включают такие вещи, как slice::from_raw_parts , которые сами по себе не вызывают UB (не считая инвариантов валидности типа), но доступ к результирующему срезу будет.

Я не верю, что async unsafe fn представляет собой уникальный или интересный случай здесь - он следует хорошо зарекомендовавшему себя шаблону для выполнения поведения unsafe за безопасным интерфейсом, требуя unsafe конструктор.

@cramertj Тот факт, что вам даже

Напомним, цитата из ридми:

Вам необходимо выполнить этот процесс, если [...]:

• Любое семантическое или синтаксическое изменение языка, не являющееся исправлением ошибки.
• [... а также нецитированные материалы]

Я не говорю, что в текущий дизайн произойдут какие-либо изменения. На самом деле, подумав об этом несколько минут, я подумал, что это, вероятно, лучший дизайн, который я мог придумать. Но процесс - это то, что позволяет нам избежать того, чтобы наши убеждения стали опасными для Rust, и нам не хватает мудрости многих людей, которые следят за репозиторием RFC, но не читают каждую проблему, не следуя процессу здесь.

Иногда имеет смысл не следовать процессу. Здесь я не вижу срочности, которая могла бы служить основанием для игнорирования процесса только во избежание двухнедельной задержки FCP.

Поэтому, пожалуйста, позвольте rust быть честным со своим сообществом в отношении обещаний, которые он дает в собственном файле readme, и просто держите эту функцию ниже ворот функций, пока не будет хотя бы принятый RFC и, надеюсь, еще какое-то его использование в дикой природе. Будь то шлюз функции async / await целиком или просто шлюз небезопасно-асинхронной функции, мне все равно, но просто не стабилизируйте то, что (AFAIK) мало использовалось за пределами async-wg и почти не известно в общее сообщество.

Я пишу первый проход по справочному материалу для книги. Попутно я заметил, что в RFC async-await сказано, что поведение оператора ? еще не определено. И все же, похоже, он отлично работает в асинхронном блоке ( игровая площадка ). Должны ли мы переместить это в отдельное окно функций? Или это было решено в какой-то момент? Я не видел этого в отчете о стабилизации, но, возможно, пропустил.

(Я также задавал этот вопрос в Zulip и предпочел бы ответы там, так как мне легче управлять.)

Да, это обсуждалось и решалось вместе с поведением return , break , continue et. al. которые все делают «единственно возможное» и ведут себя так, как если бы они были внутри замыкания.

let f = unsafe { || {...} }; также безопасно вызывать, а IIRC это эквивалентно перемещению unsafe внутрь закрытия.
То же самое для unsafe fn foo() -> impl Fn() { || {...} } .

Для меня это достаточно прецедент, когда «небезопасная вещь происходит после выхода из области unsafe ».

То же самое и в других местах. Как указывалось ранее, unsafe не всегда находится там, где мог бы быть потенциальный UB. Пример:

    let mut vec: Vec<u32> = Vec::new();

    unsafe { vec.set_len(100); }      // <- unsafe

    let val = vec.get(5).unwrap();     // <- UB
    println!("{}", val);

Мне это просто кажется неправильным пониманием небезопасности - unsafe не означает, что «здесь происходит небезопасная операция» - это означает «Я гарантирую, что соблюдаю необходимые инварианты здесь». Хотя вы можете поддерживать инварианты в точке ожидания, поскольку он не включает в себя переменных параметров, это не очень очевидный сайт для проверки того, что вы поддерживаете инварианты. Это имеет гораздо больше смысла и гораздо больше соответствует тому, как работают все наши небезопасные абстракции, чтобы гарантировать соблюдение инвариантов на сайте вызова.

Это связано с тем, почему представление о небезопасности как об эффекте приводит к неточным интуициям (как утверждал Ральф, когда эта идея впервые была высказана в прошлом году). Небезопасность специально, преднамеренно, не заразна. Хотя вы можете писать небезопасные функции, которые вызывают другие небезопасные функции и просто перенаправляют их инварианты вверх по стеку вызовов, это не обычный способ использования unsafe, и на самом деле это синтаксический маркер, используемый для определения контрактов на значения и ручной проверки этого вы их поддерживаете.

Так что дело не в том, что для каждого проектного решения нужен целый RFC, но мы работали над тем, чтобы обеспечить большую ясность и структуру того, как принимаются решения. Список основных моментов для принятия решения в открытии этого выпуска является тому примером. Используя доступные нам инструменты, я хотел бы попытаться достичь структурированного консенсуса по этой проблеме небезопасных асинхронных fns, так что это сводный пост с опросом.

async unsafe fn

async unsafe fns - это асинхронные функции, которые можно вызывать только внутри небезопасного блока. Внутри их тело считается небезопасным прицелом. Основной альтернативой было бы сделать async unsafe fns небезопасным для ожидания , а не для вызова. Есть ряд веских причин предпочесть тот дизайн, в котором называть их небезопасно:

1. Синтаксически это согласуется с поведением неасинхронных небезопасных функций, которые также небезопасно вызывать.
2. Это больше соответствует тому, как небезопасно работает в целом. Небезопасная функция - это абстракция, которая зависит от некоторых инвариантов, поддерживаемых ее вызывающей стороной. То есть дело не в том, что речь идет о маркировке «где происходит небезопасная операция», а в том, «где инвариант гарантированно соблюдается». Гораздо разумнее проверять, поддерживаются ли инварианты на сайте вызова, где аргументы фактически указаны, чем на сайте ожидания, отдельно от того, когда аргументы были выбраны и проверены. Это очень нормально для небезопасных функций в целом, которые часто определяют какое-то состояние, которое другие безопасные функции ожидают быть правильными.
3. Это больше согласуется с понятием десугарирования сигнатур async fn, где вы можете смоделировать сигнатуру как эквивалент удаления модификатора async и упаковки возвращаемого типа в будущем.
4. Альтернативу невозможно реализовать в ближайшей или среднесрочной перспективе (имеется в виду несколько лет). Невозможно создать будущее, которое было бы небезопасно опрашивать на языке Rust, разработанном в настоящее время. Какое-то «небезопасное как эффект» было бы огромным изменением, которое имело бы далеко идущие последствия и потребовало бы рассмотрения того, как оно обратно совместимо с небезопасным, как оно уже существует сегодня (например, обычные небезопасные функции и блоки). Добавление async unsafe fns существенно не меняет ситуацию, тогда как async unsafe fns в текущей интерпретации unsafe имеет реальные практические варианты использования в краткосрочной и среднесрочной перспективе.

@rfcbot ask lang "

Понятия не имею, как провести опрос с помощью rfcbot, но, по крайней мере, я его номинировал.

Член команды @withoutboats обратился к командам: T-lang за консенсусом по:

«Принимаем ли мы стабилизацию async unsafe fn как async fn, вызывать которую небезопасно?»

• [x] @Centril
• [x] @cramertj
• [x] @eddyb
• [] @joshtriplett
• [x] @nikomatsakis
• [] @pnkfelix
• [] @scottmcm
• [x] @withoutboats

@withoutboats

Я хотел бы нанести удар по структурированному консенсусу по этой проблеме небезопасных async fns, так что это сводный пост с опросом.

Спасибо, что написали. Обсуждение убедило меня, что async unsafe fn как он работает сегодня ночью, ведет себя правильно. (Вероятно, следует добавить некоторые тесты, поскольку он выглядел скудным.) Кроме того, не могли бы вы внести в отчет вверху части отчета + описание того, как ведет себя async unsafe fn ?

Это больше соответствует тому, как небезопасно работает в целом. Небезопасная функция - это абстракция, которая зависит от некоторых инвариантов, поддерживаемых ее вызывающей стороной. То есть дело не в том, что речь идет о маркировке «где происходит небезопасная операция», а в том, «где инвариант гарантированно соблюдается». Гораздо разумнее проверять, поддерживаются ли инварианты на сайте вызова, где аргументы фактически указаны, чем на сайте ожидания, отдельно от того, когда аргументы были выбраны и проверены. Это очень нормально для небезопасных функций в целом, которые часто определяют какое-то состояние, которое другие безопасные функции ожидают быть правильными.

Как человек, не обращающий слишком пристального внимания, я согласен и думаю, что решение здесь - хорошая документация.

Я мог бы ошибиться здесь, но с учетом этого

• Futures комбинаторны по своей природе, принципиально то, что они могут быть составлены.
• Точки ожидания внутри будущей реализации обычно являются невидимой деталью реализации.
• будущее очень далеко от контекста выполнения, и реальный пользователь может находиться между ними, а не в корне.

Мне кажется, что инварианты, зависящие от конкретного ожидающего использования / поведения, находятся где-то между плохой идеей и невозможностью безопасного правила.

Если есть случаи, когда ожидаемое выходное значение - это то, что участвует в поддержании инвариантов, я предполагаю, что в будущем может просто быть выход, который является оболочкой, требующей небезопасного доступа, например

struct UnsafeOutput<T>(T);
impl<T> UnsafeOutput<T> {
    unsafe fn unwrap(self) -> T { self.0 }
}

Учитывая, что значение unsafe предшествует значению async в этом "раннем небезопасном состоянии", я был бы гораздо более счастлив, если бы порядок модификаторов был unsafe async fn чем async unsafe fn , потому что unsafe (async fn) гораздо более явно отображает это поведение, чем async (unsafe fn) .

Я с радостью соглашусь, но я твердо уверен, что в представленном здесь порядке упаковки есть unsafe снаружи, и порядок модификаторов может помочь прояснить это. ( unsafe - модификатор async fn , а не async модификатор unsafe fn .)

Я с радостью приму и то, и другое, но я твердо уверен, что в представленном здесь порядке упаковки есть unsafe снаружи, и порядок модификаторов может помочь прояснить это. ( unsafe - модификатор async fn , а не async модификатор unsafe fn .)

Я был с вами до вашего последнего пункта в скобках. Запись @withoutboats дает мне довольно ясно понять, что, если небезопасность рассматривается на сайте вызова, на самом деле у вас есть unsafe fn (который вызывается в асинхронном контексте).

Я бы сказал, мы покрасим велосипедную навесу async unsafe fn .

Я думаю, что async unsafe fn имеет больше смысла, но я также считаю, что мы должны грамматически принимать любой порядок между async, unsafe и const. Но для меня async unsafe fn имеет больше смысла, поскольку вы удаляете асинхронный код и изменяете возвращаемый тип, чтобы "десахарировать" его.

Альтернативу невозможно реализовать в ближайшей или среднесрочной перспективе (имеется в виду несколько лет). Невозможно создать будущее, которое было бы небезопасно опрашивать на языке Rust, разработанном в настоящее время.

FWIW Я столкнулся с аналогичной проблемой, о которой упоминал в RFC2585, когда дело доходит до замыканий внутри unsafe fn и свойств функции. Я не ожидал, что unsafe async fn вернет Future с безопасным методом poll , а вместо этого вернет UnsafeFuture с unsafe метод опроса. (*) Тогда мы могли бы заставить .await также работать с UnsafeFuture s, когда он используется внутри блоков unsafe { } , но не иначе.

Эти две будущие черты будут огромным изменением по сравнению с тем, что у нас есть сегодня, и они, вероятно, внесут много проблем с возможностью компоновки. Значит, корабль для исследования альтернатив, вероятно, ушел. В частности, поскольку это будет отличаться от того, как сегодня работают черты Fn (например, у нас нет черты UnsafeFn или аналогичной, и моя проблема в RFC2585 заключалась в том, что создание замыкания внутри unsafe fn возвращает закрытие, которое impls Fn() , то есть безопасное для вызова, даже если это закрытие может вызывать небезопасные функции.

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

(*) Мы можем предоставить общий набор UnsafeFuture для всех Future s, а также можем предоставить UnsafeFuture unsafe метод Future который безопасен для poll .

Вот мои два цента:

• Объяснение @cramertj (https://github.com/rust-lang/rust/issues/62149#issuecomment-510166207) убеждает меня, что unsafe async-функции - это правильный дизайн.
• Я предпочитаю фиксированный порядок ключевых слов unsafe и async
• Я немного предпочитаю порядок unsafe async fn потому что порядок кажется более логичным. Подобно «быстрому электромобилю» против «быстрому электрическому автомобилю». В основном потому, что async fn обессахаривает fn . Итак, логично, что два ключевых слова находятся рядом друг с другом.

Я думаю, что let f = unsafe { || { ... } } должно сделать f безопасным, признак UnsafeFn никогда не должен вводиться, и априори .await ing и async unsafe fn должны быть безопасно. Любой UnsafeFuture требует веского обоснования!

Все это следует потому, что unsafe должно быть явным, а Rust должен подтолкнуть вас обратно в безопасную страну. Также по этому токену f ... должно _не_ быть небезопасным блоком, следует принять https://github.com/rust-lang/rfcs/pull/2585 и async unsafe fn должно быть безопасное тело.

Я думаю, что последний пункт может оказаться весьма важным. Возможно, что в каждом async unsafe fn будет использоваться блок unsafe , но аналогично большинству из них будет полезен некоторый анализ безопасности, и многие из них звучат достаточно сложно, чтобы легко допустить ошибку.

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

Итак, мой комментарий здесь: https://github.com/rust-lang/rust/issues/62149#issuecomment -511116357 - очень плохая идея.

Признак UnsafeFuture потребует от вызывающего написать unsafe { } для опроса будущего, но вызывающий не знает, какие обязательства должны быть там подтверждены, например, если вы получите Box<dyn UnsafeFuture> unsafe { future.poll() } безопасно? Для всех фьючерсов? Вы не можете знать. Так что это было бы совершенно бесполезно, как указал @rpjohnst в разногласиях для аналогичной черты UnsafeFn .

Требовать, чтобы будущее всегда было безопасным для опроса, имеет смысл, и процесс построения будущего, которое должно быть безопасным для опроса, может быть небезопасным; Полагаю, вот что такое async unsafe fn . Но в этом случае элемент fn может задокументировать, что необходимо поддержать, чтобы возвращенное будущее можно было безопасно опросить.

@rfcbot реализация-работа-блокировка-стабилизация

Насколько мне известно, есть еще 2 известных блокиратора реализации (https://github.com/rust-lang/rust/issues/61949, https://github.com/rust-lang/rust/issues/62517), и это будет еще будет хорошо добавить несколько тестов. Я разрешаю свою заботу о том, чтобы rfcbot не был нашим блокировщиком по времени, и тогда мы фактически заблокируем исправления.

@rfcbot разрешить реализацию-работу-блокировку-стабилизацию

: bell: Сейчас наступает последний период для комментариев , согласно обзору выше . : звонок:

Зарегистрирован PR стабилизации в https://github.com/rust-lang/rust/pull/63209.

Последний период комментариев с предложением о слиянии в соответствии с приведенным выше обзором завершен .

Как автоматизированный представитель процесса управления, я хотел бы поблагодарить автора за их работу и всех, кто внес свой вклад.

RFC скоро будет объединен.

Интересный аспект, который мы здесь стабилизируем, заключается в том, что мы делаем самодостаточные структуры доступными из безопасного кода. Что делает это интересным, так это то, что в Pin <& mut SelfReferentialGenerator> у нас есть изменяемая ссылка (сохраненная как поле в Pin), указывающая на все состояние генератора, и у нас есть указатель внутри этого состояния, указывающий на другую часть состояния. . Этот внутренний указатель является псевдонимом изменяемой ссылки!

Как продолжение этого, @comex действительно удалось написать некоторый (безопасный) асинхронный код на Rust, который нарушает аннотации LLVM noalias том виде, в