This is the original design proposed by the Keyword Generics Initiatve in the
-Feb 2023 Progress Report.
-
The "explainer" is "end-user readable" documentation that explains how to use the feature being deveoped by this initiative.
diff --git a/searchindex.js b/searchindex.js
index 10ce770..643a4b1 100644
--- a/searchindex.js
+++ b/searchindex.js
@@ -1 +1 @@
-Object.assign(window.search, {"doc_urls":["index.html#keyword-generics-initiative","index.html#what-is-this","index.html#current-status","index.html#how-can-i-get-involved","index.html#building-documentation","updates/index.html#-updates","updates/progress-report-february-2023.html#progress-report-february-2023","updates/progress-report-february-2023.html#introduction","updates/progress-report-february-2023.html#an-async-example","updates/progress-report-february-2023.html#a-const-example","updates/progress-report-february-2023.html#combining-const-and-async","updates/progress-report-february-2023.html#adding-support-for-types","updates/progress-report-february-2023.html#consistent-syntax","updates/progress-report-february-2023.html#the-tentative-plan","updates/progress-report-february-2023.html#conclusion","CHARTER.html#-keyword-generics-charter","CHARTER.html#proposal","CHARTER.html#a-broad-perspective-on-language-extensions","CHARTER.html#membership","evaluation/index.html#-evaluation","evaluation/syntax/index.html#syntax","evaluation/syntax/_template.html#design","evaluation/syntax/_template.html#base-reference","evaluation/syntax/_template.html#always-async","evaluation/syntax/_template.html#maybe-async","evaluation/syntax/_template.html#generic-over-all-modifier-keywords","evaluation/syntax/_template.html#notes","evaluation/syntax/attributes.html#design","evaluation/syntax/attributes.html#base-reference","evaluation/syntax/attributes.html#always-async","evaluation/syntax/attributes.html#maybe-async","evaluation/syntax/attributes.html#generic-over-all-modifier-keywords","evaluation/syntax/attributes.html#notes","evaluation/syntax/const-bool-like-effects.html#design","evaluation/syntax/const-bool-like-effects.html#base-reference","evaluation/syntax/const-bool-like-effects.html#always-async","evaluation/syntax/const-bool-like-effects.html#maybe-async","evaluation/syntax/const-bool-like-effects.html#generic-over-all-modifier-keywords","evaluation/syntax/const-bool-like-effects.html#notes","evaluation/syntax/const-bool-like-effects.html#some-nice-things-about-the-syntax","evaluation/syntax/const-bool-like-effects.html#specific-behavior","evaluation/syntax/const-bool-like-effects.html#impl-blocks","evaluation/syntax/const-bool-like-effects.html#description","evaluation/syntax/const-bool-like-effects.html#foreffect","evaluation/syntax/const-bool-like-effects.html#semi-formal-description","evaluation/syntax/const-bool-like-effects.html#foreffect-bounds-and-traits","evaluation/syntax/effect-as-a-clause.html#design","evaluation/syntax/effect-as-a-clause.html#base-reference","evaluation/syntax/effect-as-a-clause.html#always-async","evaluation/syntax/effect-as-a-clause.html#maybe-async","evaluation/syntax/effect-as-a-clause.html#generic-over-all-modifier-keywords","evaluation/syntax/effect-as-a-clause.html#notes","evaluation/syntax/postfix-question-mark.html#design","evaluation/syntax/postfix-question-mark.html#base-reference","evaluation/syntax/postfix-question-mark.html#always-async","evaluation/syntax/postfix-question-mark.html#maybe-async","evaluation/syntax/postfix-question-mark.html#generic-over-all-modifier-keywords","evaluation/syntax/postfix-question-mark.html#notes","evaluation/syntax/where-effect-bounds.html#design","evaluation/syntax/where-effect-bounds.html#base-reference","evaluation/syntax/where-effect-bounds.html#always-async","evaluation/syntax/where-effect-bounds.html#maybe-async","evaluation/syntax/where-effect-bounds.html#generic-over-all-modifier-keywords","evaluation/syntax/where-effect-bounds.html#notes","evaluation/syntax/where-effect-bounds.html#trait-effect-bounds","evaluation/syntax/where-effect-bounds.html#explicit-generic-over-all-modifier-keywords","evaluation/syntax/where-effect-bounds.html#explicit","evaluation/syntax/where-effect-bounds.html#backwards-compatible-to-introduce-new-keywords-in-the-language","evaluation/syntax/where-effect-bounds.html#limitations","evaluation/syntax/where-effect-bounds.html#effect-sets","evaluation/progress-report-feb-2023.html#design","evaluation/progress-report-feb-2023.html#base-reference","evaluation/progress-report-feb-2023.html#always-async","evaluation/progress-report-feb-2023.html#maybe-async","evaluation/progress-report-feb-2023.html#generic-over-all-modifier-keywords","evaluation/progress-report-feb-2023.html#notes","explainer/index.html#-explainer","explainer/effect-generic-trait-declarations.html#summary","explainer/effect-generic-trait-declarations.html#motivation","explainer/effect-generic-trait-declarations.html#guaranteeing-api-consistency","explainer/effect-generic-trait-declarations.html#guide-level-explanation","explainer/effect-generic-trait-declarations.html#trait-definitions","explainer/effect-generic-trait-declarations.html#trait-implementations","explainer/effect-generic-trait-declarations.html#method-markers","explainer/effect-generic-trait-declarations.html#reference-level-explanation","explainer/effect-generic-trait-declarations.html#effect-lowering","explainer/effect-generic-trait-declarations.html#effect-lowering-with-lifetimes","explainer/effect-generic-trait-declarations.html#effect-states","explainer/effect-generic-trait-declarations.html#concrete-impls-and-coherence","explainer/effect-generic-trait-declarations.html#trait-bounds","explainer/effect-generic-trait-declarations.html#super-traits","explainer/effect-generic-trait-declarations.html#todo-prerequisites","explainer/effect-generic-trait-declarations.html#drawbacks","explainer/effect-generic-trait-declarations.html#const-effect-states","explainer/effect-generic-trait-declarations.html#todo-additional-syntax","explainer/effect-generic-trait-declarations.html#todo-direction","explainer/effect-generic-trait-declarations.html#prior-art","explainer/effect-generic-trait-declarations.html#unresolved-questions","explainer/effect-generic-trait-declarations.html#todo-syntax","explainer/effect-generic-trait-declarations.html#alternatives","explainer/effect-generic-trait-declarations.html#todo-do-nothing-null-hypothesis","explainer/effect-generic-trait-declarations.html#future-possibilities","explainer/effect-generic-trait-declarations.html#todo-integration-with-other-keywords","explainer/effect-generic-trait-declarations.html#todo-effect-generic-types-and-bodies","explainer/effect-generic-trait-declarations.html#todo-effect-sets","explainer/effect-generic-trait-declarations.html#todo-normalize-const","archive/index.html#archive","archive/evaluation/effects-in-rust.html#effects-in-rust","archive/evaluation/effects-in-rust.html#what-do-we-mean-by-effect-in-this-section","archive/evaluation/effects-in-rust/async.html#asynchrony-scoped-effect","archive/evaluation/effects-in-rust/async.html#description","archive/evaluation/effects-in-rust/async.html#feature-status","archive/evaluation/effects-in-rust/async.html#feature-categorization","archive/evaluation/effects-in-rust/async.html#positions-available","archive/evaluation/effects-in-rust/async.html#refinements","archive/evaluation/effects-in-rust/async.html#cancellation-safe-futures","archive/evaluation/effects-in-rust/async.html#fused-futures","archive/evaluation/effects-in-rust/async.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/async.html#asynchrony","archive/evaluation/effects-in-rust/async.html#compile-time-execution","archive/evaluation/effects-in-rust/async.html#fallibility","archive/evaluation/effects-in-rust/async.html#iteration","archive/evaluation/effects-in-rust/async.html#unwinding","archive/evaluation/effects-in-rust/async.html#memory-safety","archive/evaluation/effects-in-rust/async.html#immovability","archive/evaluation/effects-in-rust/async.html#object-safety","archive/evaluation/effects-in-rust/async.html#ownership","archive/evaluation/effects-in-rust/async.html#thread-safety","archive/evaluation/effects-in-rust/const.html#compile-time-execution-scoped-effect","archive/evaluation/effects-in-rust/const.html#description","archive/evaluation/effects-in-rust/const.html#feature-status","archive/evaluation/effects-in-rust/const.html#feature-categorization","archive/evaluation/effects-in-rust/const.html#positions-available","archive/evaluation/effects-in-rust/const.html#refinements","archive/evaluation/effects-in-rust/const.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/const.html#asynchrony","archive/evaluation/effects-in-rust/const.html#compile-time-execution","archive/evaluation/effects-in-rust/const.html#fallibility","archive/evaluation/effects-in-rust/const.html#iteration","archive/evaluation/effects-in-rust/const.html#unwinding","archive/evaluation/effects-in-rust/const.html#memory-safety","archive/evaluation/effects-in-rust/const.html#immovability","archive/evaluation/effects-in-rust/const.html#object-safety","archive/evaluation/effects-in-rust/const.html#ownership","archive/evaluation/effects-in-rust/const.html#thread-safety","archive/evaluation/effects-in-rust/const.html#references","archive/evaluation/effects-in-rust/try.html#fallibility-scoped-effect","archive/evaluation/effects-in-rust/try.html#feature-status","archive/evaluation/effects-in-rust/try.html#description","archive/evaluation/effects-in-rust/try.html#refinements","archive/evaluation/effects-in-rust/try.html#feature-categorization","archive/evaluation/effects-in-rust/try.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/try.html#asynchrony","archive/evaluation/effects-in-rust/try.html#compile-time-execution","archive/evaluation/effects-in-rust/try.html#fallibility","archive/evaluation/effects-in-rust/try.html#iteration","archive/evaluation/effects-in-rust/try.html#may-panic","archive/evaluation/effects-in-rust/try.html#memory-unsafety","archive/evaluation/effects-in-rust/try.html#must-not-move","archive/evaluation/effects-in-rust/try.html#object-safety","archive/evaluation/effects-in-rust/try.html#ownership","archive/evaluation/effects-in-rust/try.html#thread-safety","archive/evaluation/effects-in-rust/gen.html#iteration-scoped-effect","archive/evaluation/effects-in-rust/gen.html#feature-status","archive/evaluation/effects-in-rust/gen.html#description","archive/evaluation/effects-in-rust/gen.html#technical-overview","archive/evaluation/effects-in-rust/gen.html#refinements","archive/evaluation/effects-in-rust/gen.html#positions-available","archive/evaluation/effects-in-rust/gen.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/gen.html#asynchrony","archive/evaluation/effects-in-rust/gen.html#fallibility","archive/evaluation/effects-in-rust/gen.html#compile-time-execution","archive/evaluation/effects-in-rust/gen.html#thread-safety","archive/evaluation/effects-in-rust/gen.html#immovability","archive/evaluation/effects-in-rust/gen.html#unwinding","archive/evaluation/effects-in-rust/panic.html#unwinding-scoped-effect","archive/evaluation/effects-in-rust/panic.html#feature-status","archive/evaluation/effects-in-rust/panic.html#description","archive/evaluation/effects-in-rust/panic.html#refinements","archive/evaluation/effects-in-rust/panic.html#feature-categorization","archive/evaluation/effects-in-rust/panic.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/panic.html#asynchrony","archive/evaluation/effects-in-rust/panic.html#compile-time-execution","archive/evaluation/effects-in-rust/panic.html#fallibility","archive/evaluation/effects-in-rust/panic.html#iteration","archive/evaluation/effects-in-rust/panic.html#unwinding","archive/evaluation/effects-in-rust/panic.html#memory-safety","archive/evaluation/effects-in-rust/panic.html#immovability","archive/evaluation/effects-in-rust/panic.html#object-safety","archive/evaluation/effects-in-rust/panic.html#ownership","archive/evaluation/effects-in-rust/panic.html#thread-safety","archive/evaluation/effects-in-rust/unsafe.html#memory-safety-scoped-effect","archive/evaluation/effects-in-rust/unsafe.html#asynchrony","archive/evaluation/effects-in-rust/unsafe.html#compile-time-execution","archive/evaluation/effects-in-rust/unsafe.html#fallibility","archive/evaluation/effects-in-rust/unsafe.html#iteration","archive/evaluation/effects-in-rust/unsafe.html#unwinding","archive/evaluation/effects-in-rust/unsafe.html#memory-safety","archive/evaluation/effects-in-rust/unsafe.html#immovability","archive/evaluation/effects-in-rust/unsafe.html#object-safety","archive/evaluation/effects-in-rust/unsafe.html#ownership","archive/evaluation/effects-in-rust/unsafe.html#thread-safety","archive/evaluation/effects-in-rust/unsafe.html#references","archive/evaluation/effects-in-rust/pin.html#immovability-data-type-effect","archive/evaluation/effects-in-rust/pin.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/pin.html#asynchrony","archive/evaluation/effects-in-rust/pin.html#compile-time-execution","archive/evaluation/effects-in-rust/pin.html#fallibility","archive/evaluation/effects-in-rust/pin.html#iteration","archive/evaluation/effects-in-rust/pin.html#unwinding","archive/evaluation/effects-in-rust/pin.html#memory-safety","archive/evaluation/effects-in-rust/pin.html#immovability","archive/evaluation/effects-in-rust/pin.html#object-safety","archive/evaluation/effects-in-rust/pin.html#ownership","archive/evaluation/effects-in-rust/pin.html#thread-safety","archive/evaluation/effects-in-rust/sized.html#object-safety-data-type-effect","archive/evaluation/effects-in-rust/sized.html#asynchrony","archive/evaluation/effects-in-rust/sized.html#compile-time-execution","archive/evaluation/effects-in-rust/sized.html#fallibility","archive/evaluation/effects-in-rust/sized.html#iteration","archive/evaluation/effects-in-rust/sized.html#unwinding","archive/evaluation/effects-in-rust/sized.html#memory-safety","archive/evaluation/effects-in-rust/sized.html#immovability","archive/evaluation/effects-in-rust/sized.html#object-safety","archive/evaluation/effects-in-rust/sized.html#ownership","archive/evaluation/effects-in-rust/sized.html#thread-safety","archive/evaluation/effects-in-rust/ownership.html#ownership-data-type-effect","archive/evaluation/effects-in-rust/ownership.html#description","archive/evaluation/effects-in-rust/ownership.html#feature-status","archive/evaluation/effects-in-rust/ownership.html#feature-categorization","archive/evaluation/effects-in-rust/ownership.html#positions-available","archive/evaluation/effects-in-rust/ownership.html#refinements","archive/evaluation/effects-in-rust/ownership.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/ownership.html#asynchrony","archive/evaluation/effects-in-rust/ownership.html#compile-time-execution","archive/evaluation/effects-in-rust/ownership.html#fallibility","archive/evaluation/effects-in-rust/ownership.html#iteration","archive/evaluation/effects-in-rust/ownership.html#unwinding","archive/evaluation/effects-in-rust/ownership.html#memory-safety","archive/evaluation/effects-in-rust/ownership.html#immovability","archive/evaluation/effects-in-rust/ownership.html#object-safety","archive/evaluation/effects-in-rust/ownership.html#ownership","archive/evaluation/effects-in-rust/ownership.html#thread-safety","archive/evaluation/effects-in-rust/ownership.html#references","archive/evaluation/effects-in-rust/send.html#thread-safety-data-type-effect","archive/evaluation/effects-in-rust/send.html#interactions-with-other-effects","archive/evaluation/effects-in-rust/send.html#asynchrony","archive/evaluation/effects-in-rust/send.html#compile-time-execution","archive/evaluation/effects-in-rust/send.html#fallibility","archive/evaluation/effects-in-rust/send.html#iteration","archive/evaluation/effects-in-rust/send.html#unwinding","archive/evaluation/effects-in-rust/send.html#memory-safety","archive/evaluation/effects-in-rust/send.html#immovability","archive/evaluation/effects-in-rust/send.html#object-safety","archive/evaluation/effects-in-rust/send.html#ownership","archive/evaluation/effects-in-rust/send.html#thread-safety","archive/evaluation/effect-hierarchy.html#implications-of-the-effect-hierarchy","archive/evaluation/grouping-keyword-generics.html#grouping-keyword-generics","archive/evaluation/introducing-new-keyword-generics.html#adding-new-keyword-generics","archive/evaluation/mir-desugaring.html#mir-desugaring","archive/evaluation/mir-desugaring.html#examples","archive/evaluation/mir-desugaring.html#implementation-side","archive/evaluation/overloading-keyword-generics.html#overloading-keyword-generics","archive/evaluation/prior-art.html#prior-art","archive/evaluation/prior-art.html#c-noexceptnoexcept","archive/evaluation/prior-art.html#c-implicits-and-constexpr","archive/evaluation/prior-art.html#rust-maybe-async-crate","archive/evaluation/prior-art.html#rust-fn-main","archive/evaluation/prior-art.html#zig-async-functions","archive/evaluation/prior-art.html#swift-async-overloading"],"index":{"documentStore":{"docInfo":{"0":{"body":3,"breadcrumbs":4,"title":3},"1":{"body":16,"breadcrumbs":1,"title":0},"10":{"body":261,"breadcrumbs":8,"title":3},"100":{"body":25,"breadcrumbs":9,"title":4},"101":{"body":0,"breadcrumbs":7,"title":2},"102":{"body":5,"breadcrumbs":8,"title":3},"103":{"body":26,"breadcrumbs":10,"title":5},"104":{"body":8,"breadcrumbs":8,"title":3},"105":{"body":17,"breadcrumbs":8,"title":3},"106":{"body":0,"breadcrumbs":2,"title":1},"107":{"body":18,"breadcrumbs":5,"title":2},"108":{"body":92,"breadcrumbs":6,"title":3},"109":{"body":0,"breadcrumbs":7,"title":3},"11":{"body":172,"breadcrumbs":8,"title":3},"110":{"body":75,"breadcrumbs":5,"title":1},"111":{"body":18,"breadcrumbs":6,"title":2},"112":{"body":46,"breadcrumbs":6,"title":2},"113":{"body":91,"breadcrumbs":6,"title":2},"114":{"body":8,"breadcrumbs":5,"title":1},"115":{"body":51,"breadcrumbs":7,"title":3},"116":{"body":49,"breadcrumbs":6,"title":2},"117":{"body":0,"breadcrumbs":6,"title":2},"118":{"body":0,"breadcrumbs":5,"title":1},"119":{"body":0,"breadcrumbs":7,"title":3},"12":{"body":382,"breadcrumbs":7,"title":2},"120":{"body":0,"breadcrumbs":5,"title":1},"121":{"body":0,"breadcrumbs":5,"title":1},"122":{"body":0,"breadcrumbs":5,"title":1},"123":{"body":0,"breadcrumbs":6,"title":2},"124":{"body":0,"breadcrumbs":5,"title":1},"125":{"body":0,"breadcrumbs":6,"title":2},"126":{"body":0,"breadcrumbs":5,"title":1},"127":{"body":0,"breadcrumbs":6,"title":2},"128":{"body":0,"breadcrumbs":11,"title":5},"129":{"body":52,"breadcrumbs":7,"title":1},"13":{"body":122,"breadcrumbs":7,"title":2},"130":{"body":29,"breadcrumbs":8,"title":2},"131":{"body":16,"breadcrumbs":8,"title":2},"132":{"body":58,"breadcrumbs":8,"title":2},"133":{"body":6,"breadcrumbs":7,"title":1},"134":{"body":0,"breadcrumbs":8,"title":2},"135":{"body":0,"breadcrumbs":7,"title":1},"136":{"body":0,"breadcrumbs":9,"title":3},"137":{"body":0,"breadcrumbs":7,"title":1},"138":{"body":0,"breadcrumbs":7,"title":1},"139":{"body":0,"breadcrumbs":7,"title":1},"14":{"body":54,"breadcrumbs":6,"title":1},"140":{"body":0,"breadcrumbs":8,"title":2},"141":{"body":0,"breadcrumbs":7,"title":1},"142":{"body":0,"breadcrumbs":8,"title":2},"143":{"body":0,"breadcrumbs":7,"title":1},"144":{"body":0,"breadcrumbs":8,"title":2},"145":{"body":7,"breadcrumbs":7,"title":1},"146":{"body":0,"breadcrumbs":7,"title":3},"147":{"body":1,"breadcrumbs":6,"title":2},"148":{"body":1,"breadcrumbs":5,"title":1},"149":{"body":42,"breadcrumbs":5,"title":1},"15":{"body":66,"breadcrumbs":4,"title":3},"150":{"body":41,"breadcrumbs":6,"title":2},"151":{"body":0,"breadcrumbs":6,"title":2},"152":{"body":0,"breadcrumbs":5,"title":1},"153":{"body":0,"breadcrumbs":7,"title":3},"154":{"body":0,"breadcrumbs":5,"title":1},"155":{"body":0,"breadcrumbs":5,"title":1},"156":{"body":0,"breadcrumbs":5,"title":1},"157":{"body":0,"breadcrumbs":6,"title":2},"158":{"body":0,"breadcrumbs":5,"title":1},"159":{"body":0,"breadcrumbs":6,"title":2},"16":{"body":61,"breadcrumbs":2,"title":1},"160":{"body":0,"breadcrumbs":5,"title":1},"161":{"body":0,"breadcrumbs":6,"title":2},"162":{"body":0,"breadcrumbs":7,"title":3},"163":{"body":18,"breadcrumbs":6,"title":2},"164":{"body":1,"breadcrumbs":5,"title":1},"165":{"body":13,"breadcrumbs":6,"title":2},"166":{"body":55,"breadcrumbs":5,"title":1},"167":{"body":53,"breadcrumbs":6,"title":2},"168":{"body":0,"breadcrumbs":6,"title":2},"169":{"body":27,"breadcrumbs":5,"title":1},"17":{"body":194,"breadcrumbs":5,"title":4},"170":{"body":20,"breadcrumbs":5,"title":1},"171":{"body":20,"breadcrumbs":7,"title":3},"172":{"body":29,"breadcrumbs":6,"title":2},"173":{"body":22,"breadcrumbs":5,"title":1},"174":{"body":23,"breadcrumbs":5,"title":1},"175":{"body":0,"breadcrumbs":7,"title":3},"176":{"body":1,"breadcrumbs":6,"title":2},"177":{"body":1,"breadcrumbs":5,"title":1},"178":{"body":6,"breadcrumbs":5,"title":1},"179":{"body":41,"breadcrumbs":6,"title":2},"18":{"body":11,"breadcrumbs":2,"title":1},"180":{"body":0,"breadcrumbs":6,"title":2},"181":{"body":0,"breadcrumbs":5,"title":1},"182":{"body":0,"breadcrumbs":7,"title":3},"183":{"body":0,"breadcrumbs":5,"title":1},"184":{"body":0,"breadcrumbs":5,"title":1},"185":{"body":0,"breadcrumbs":5,"title":1},"186":{"body":0,"breadcrumbs":6,"title":2},"187":{"body":0,"breadcrumbs":5,"title":1},"188":{"body":0,"breadcrumbs":6,"title":2},"189":{"body":0,"breadcrumbs":5,"title":1},"19":{"body":26,"breadcrumbs":2,"title":1},"190":{"body":0,"breadcrumbs":6,"title":2},"191":{"body":0,"breadcrumbs":9,"title":4},"192":{"body":0,"breadcrumbs":6,"title":1},"193":{"body":0,"breadcrumbs":8,"title":3},"194":{"body":0,"breadcrumbs":6,"title":1},"195":{"body":0,"breadcrumbs":6,"title":1},"196":{"body":0,"breadcrumbs":6,"title":1},"197":{"body":0,"breadcrumbs":7,"title":2},"198":{"body":0,"breadcrumbs":6,"title":1},"199":{"body":0,"breadcrumbs":7,"title":2},"2":{"body":37,"breadcrumbs":3,"title":2},"20":{"body":0,"breadcrumbs":3,"title":1},"200":{"body":0,"breadcrumbs":6,"title":1},"201":{"body":0,"breadcrumbs":7,"title":2},"202":{"body":3,"breadcrumbs":6,"title":1},"203":{"body":0,"breadcrumbs":8,"title":4},"204":{"body":0,"breadcrumbs":6,"title":2},"205":{"body":0,"breadcrumbs":5,"title":1},"206":{"body":0,"breadcrumbs":7,"title":3},"207":{"body":0,"breadcrumbs":5,"title":1},"208":{"body":0,"breadcrumbs":5,"title":1},"209":{"body":0,"breadcrumbs":5,"title":1},"21":{"body":12,"breadcrumbs":4,"title":1},"210":{"body":0,"breadcrumbs":6,"title":2},"211":{"body":0,"breadcrumbs":5,"title":1},"212":{"body":0,"breadcrumbs":6,"title":2},"213":{"body":0,"breadcrumbs":5,"title":1},"214":{"body":0,"breadcrumbs":6,"title":2},"215":{"body":0,"breadcrumbs":10,"title":5},"216":{"body":0,"breadcrumbs":6,"title":1},"217":{"body":0,"breadcrumbs":8,"title":3},"218":{"body":0,"breadcrumbs":6,"title":1},"219":{"body":0,"breadcrumbs":6,"title":1},"22":{"body":37,"breadcrumbs":5,"title":2},"220":{"body":0,"breadcrumbs":6,"title":1},"221":{"body":0,"breadcrumbs":7,"title":2},"222":{"body":0,"breadcrumbs":6,"title":1},"223":{"body":0,"breadcrumbs":7,"title":2},"224":{"body":0,"breadcrumbs":6,"title":1},"225":{"body":0,"breadcrumbs":7,"title":2},"226":{"body":0,"breadcrumbs":8,"title":4},"227":{"body":0,"breadcrumbs":5,"title":1},"228":{"body":0,"breadcrumbs":6,"title":2},"229":{"body":7,"breadcrumbs":6,"title":2},"23":{"body":1,"breadcrumbs":5,"title":2},"230":{"body":61,"breadcrumbs":6,"title":2},"231":{"body":2,"breadcrumbs":5,"title":1},"232":{"body":0,"breadcrumbs":6,"title":2},"233":{"body":0,"breadcrumbs":5,"title":1},"234":{"body":0,"breadcrumbs":7,"title":3},"235":{"body":0,"breadcrumbs":5,"title":1},"236":{"body":0,"breadcrumbs":5,"title":1},"237":{"body":0,"breadcrumbs":5,"title":1},"238":{"body":0,"breadcrumbs":6,"title":2},"239":{"body":0,"breadcrumbs":5,"title":1},"24":{"body":1,"breadcrumbs":5,"title":2},"240":{"body":0,"breadcrumbs":6,"title":2},"241":{"body":0,"breadcrumbs":5,"title":1},"242":{"body":0,"breadcrumbs":6,"title":2},"243":{"body":4,"breadcrumbs":5,"title":1},"244":{"body":0,"breadcrumbs":10,"title":5},"245":{"body":0,"breadcrumbs":7,"title":2},"246":{"body":0,"breadcrumbs":6,"title":1},"247":{"body":0,"breadcrumbs":8,"title":3},"248":{"body":0,"breadcrumbs":6,"title":1},"249":{"body":0,"breadcrumbs":6,"title":1},"25":{"body":1,"breadcrumbs":7,"title":4},"250":{"body":0,"breadcrumbs":6,"title":1},"251":{"body":0,"breadcrumbs":7,"title":2},"252":{"body":0,"breadcrumbs":6,"title":1},"253":{"body":0,"breadcrumbs":7,"title":2},"254":{"body":0,"breadcrumbs":6,"title":1},"255":{"body":0,"breadcrumbs":7,"title":2},"256":{"body":162,"breadcrumbs":6,"title":3},"257":{"body":374,"breadcrumbs":7,"title":3},"258":{"body":135,"breadcrumbs":9,"title":4},"259":{"body":44,"breadcrumbs":5,"title":2},"26":{"body":0,"breadcrumbs":4,"title":1},"260":{"body":58,"breadcrumbs":4,"title":1},"261":{"body":70,"breadcrumbs":5,"title":2},"262":{"body":188,"breadcrumbs":5,"title":3},"263":{"body":0,"breadcrumbs":5,"title":2},"264":{"body":40,"breadcrumbs":5,"title":2},"265":{"body":63,"breadcrumbs":6,"title":3},"266":{"body":7,"breadcrumbs":7,"title":4},"267":{"body":57,"breadcrumbs":6,"title":3},"268":{"body":34,"breadcrumbs":6,"title":3},"269":{"body":14,"breadcrumbs":6,"title":3},"27":{"body":42,"breadcrumbs":4,"title":1},"28":{"body":37,"breadcrumbs":5,"title":2},"29":{"body":36,"breadcrumbs":5,"title":2},"3":{"body":65,"breadcrumbs":2,"title":1},"30":{"body":36,"breadcrumbs":5,"title":2},"31":{"body":36,"breadcrumbs":7,"title":4},"32":{"body":0,"breadcrumbs":4,"title":1},"33":{"body":10,"breadcrumbs":6,"title":1},"34":{"body":37,"breadcrumbs":7,"title":2},"35":{"body":117,"breadcrumbs":7,"title":2},"36":{"body":155,"breadcrumbs":7,"title":2},"37":{"body":35,"breadcrumbs":9,"title":4},"38":{"body":59,"breadcrumbs":6,"title":1},"39":{"body":0,"breadcrumbs":8,"title":3},"4":{"body":10,"breadcrumbs":3,"title":2},"40":{"body":16,"breadcrumbs":7,"title":2},"41":{"body":19,"breadcrumbs":7,"title":2},"42":{"body":313,"breadcrumbs":6,"title":1},"43":{"body":227,"breadcrumbs":6,"title":1},"44":{"body":146,"breadcrumbs":8,"title":3},"45":{"body":59,"breadcrumbs":8,"title":3},"46":{"body":177,"breadcrumbs":5,"title":1},"47":{"body":37,"breadcrumbs":6,"title":2},"48":{"body":31,"breadcrumbs":6,"title":2},"49":{"body":34,"breadcrumbs":6,"title":2},"5":{"body":28,"breadcrumbs":2,"title":1},"50":{"body":37,"breadcrumbs":8,"title":4},"51":{"body":12,"breadcrumbs":5,"title":1},"52":{"body":6,"breadcrumbs":6,"title":1},"53":{"body":41,"breadcrumbs":7,"title":2},"54":{"body":21,"breadcrumbs":7,"title":2},"55":{"body":17,"breadcrumbs":7,"title":2},"56":{"body":20,"breadcrumbs":9,"title":4},"57":{"body":30,"breadcrumbs":6,"title":1},"58":{"body":22,"breadcrumbs":5,"title":1},"59":{"body":37,"breadcrumbs":6,"title":2},"6":{"body":6,"breadcrumbs":9,"title":4},"60":{"body":49,"breadcrumbs":6,"title":2},"61":{"body":40,"breadcrumbs":6,"title":2},"62":{"body":55,"breadcrumbs":8,"title":4},"63":{"body":0,"breadcrumbs":5,"title":1},"64":{"body":41,"breadcrumbs":7,"title":3},"65":{"body":27,"breadcrumbs":9,"title":5},"66":{"body":8,"breadcrumbs":5,"title":1},"67":{"body":18,"breadcrumbs":10,"title":6},"68":{"body":6,"breadcrumbs":5,"title":1},"69":{"body":69,"breadcrumbs":6,"title":2},"7":{"body":113,"breadcrumbs":6,"title":1},"70":{"body":20,"breadcrumbs":6,"title":1},"71":{"body":37,"breadcrumbs":7,"title":2},"72":{"body":33,"breadcrumbs":7,"title":2},"73":{"body":33,"breadcrumbs":7,"title":2},"74":{"body":40,"breadcrumbs":9,"title":4},"75":{"body":10,"breadcrumbs":6,"title":1},"76":{"body":28,"breadcrumbs":2,"title":1},"77":{"body":105,"breadcrumbs":6,"title":1},"78":{"body":137,"breadcrumbs":6,"title":1},"79":{"body":93,"breadcrumbs":8,"title":3},"8":{"body":300,"breadcrumbs":7,"title":2},"80":{"body":0,"breadcrumbs":8,"title":3},"81":{"body":53,"breadcrumbs":7,"title":2},"82":{"body":51,"breadcrumbs":7,"title":2},"83":{"body":107,"breadcrumbs":7,"title":2},"84":{"body":0,"breadcrumbs":8,"title":3},"85":{"body":162,"breadcrumbs":7,"title":2},"86":{"body":179,"breadcrumbs":8,"title":3},"87":{"body":110,"breadcrumbs":7,"title":2},"88":{"body":73,"breadcrumbs":8,"title":3},"89":{"body":127,"breadcrumbs":7,"title":2},"9":{"body":225,"breadcrumbs":7,"title":2},"90":{"body":131,"breadcrumbs":7,"title":2},"91":{"body":21,"breadcrumbs":7,"title":2},"92":{"body":0,"breadcrumbs":6,"title":1},"93":{"body":52,"breadcrumbs":8,"title":3},"94":{"body":7,"breadcrumbs":8,"title":3},"95":{"body":17,"breadcrumbs":7,"title":2},"96":{"body":20,"breadcrumbs":7,"title":2},"97":{"body":7,"breadcrumbs":7,"title":2},"98":{"body":27,"breadcrumbs":7,"title":2},"99":{"body":0,"breadcrumbs":6,"title":1}},"docs":{"0":{"body":"initiative status: active","breadcrumbs":"👋 Welcome » keyword generics initiative","id":"0","title":"keyword generics initiative"},"1":{"body":"This page tracks the work of the keyword generics initiative ! To learn more about what we are trying to do, and to find out the people who are doing it, take a look at the charter .","breadcrumbs":"👋 Welcome » What is this?","id":"1","title":"What is this?"},"10":{"body":"We've covered ?async, and we've covered ?const. Now what happens if we were to use them together? Let's take a look at what the Read trait would look like when if we extended it using our designs for ?const and ?async: trait ?const ?async Read { ?const ?async fn read(&mut self, buf: &mut [u8]) -> Result; ?const ?async fn read_to_string(&mut self, buf: &mut String) -> Result { .. }\n} /// Read from a reader into a string.\n?const ?async fn read_to_string(reader: &mut impl ?const ?async Read) -> io::Result { let mut string = String::new(); reader.read_to_string(&mut string).await?; Ok(string)\n} That's sure starting to feel like a lot of keywords, right? We've accurately described exactly what's going on, but there's a lot of repetition. We know that if we're dealing with a ?const ?async fn, most arguments probably will also want to be ?const ?async. But under the syntax rules we've proposed so far, you'd end up repeating that everywhere. And it probably gets worse once we start adding in more keywords. Not ideal! So we're very eager to make sure that we find a solution to this. And we've been thinking about a way we could get out of this, which we've been calling effect/.do-notation. This would allow you to mark a function as \"generic over all modifier keywords\" by annotating it as effect fn, and it would allow the compiler to insert all the right .await, ?, and yield keywords in the function body by suffixing function calls with .do. Just to set some expectations: this is the least developed part of our proposal, and we don't intend to formally propose this until after we're done with some of the other proposals. But we think it's an important part of the entire vision, so we wanted to make sure we shared it here. And with that out of the way, here's the same example we had above, but this time using the effect/.do-notation: trait ?effect Read { ?effect fn read(&mut self, buf: &mut [u8]) -> Result; ?effect fn read_to_string(&mut self, buf: &mut String) -> Result { .. }\n} /// Read from a reader into a string.\n?effect fn read_to_string(reader: &mut impl ?effect Read) -> std::io::Result { let mut string = String::new(); reader.read_to_string(&mut string).do; // note the singular `.do` here string\n} One of the things we would like to figure out as part of effect/.do is a way to enable writing conditional effect-bounds. For example: there may be a function which is always async, may never panic, and is generic over the remainder of the effects. Or like we're seeing with APIs such as Vec::reserve and Vec::try_reserve : the ability to panic xor return an error. This will take more time and research to figure out, but we believe it is something which can be solved.","breadcrumbs":"✏️ Updates » Progress Report February 2023 » Combining const and async","id":"10","title":"Combining const and async"},"100":{"body":"effect differences are inherent, which means they have to be solved somewhere effect composition is where it gets bad; we have an async version of the stdlib, not an async + fallible version things like linearity seem quite far out of reach right without this","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » TODO: Do nothing (null hypothesis)","id":"100","title":"TODO: Do nothing (null hypothesis)"},"101":{"body":"","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » Future possibilities","id":"101","title":"Future possibilities"},"102":{"body":"fallible functions generator functions linearity","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » TODO: Integration with other keywords","id":"102","title":"TODO: Integration with other keywords"},"103":{"body":"types functions /// Before: the base implementation\nimpl Into for Cat { fn into(self) -> Loaf { self.nap() }\n} /// Before: the async implementation\nimpl async Into for AsyncCat { async fn into(self) -> AsyncLoaf { self.async_nap().await }\n} // After: a single implementation\n...","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » TODO: Effect-generic types and bodies","id":"103","title":"TODO: Effect-generic types and bodies"},"104":{"body":"named effect sets unify core and std via sets","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » TODO: Effect sets","id":"104","title":"TODO: Effect sets"},"105":{"body":"const fn is maybe-const const {} is always const this is super annoying lol, and that's why this system doesn't work for const right now","breadcrumbs":"📚 Explainer » Effect Generic Trait Declarations » TODO: Normalize const","id":"105","title":"TODO: Normalize const"},"106":{"body":"","breadcrumbs":"📦 Archive » Archive","id":"106","title":"Archive"},"107":{"body":"Rust has a number of built-ins which sure look a lot like effects. In this section we cover what those are, how they're in use today, touch on some of the pain-points experienced by them.","breadcrumbs":"📦 Archive » Effects in Rust » Effects in Rust","id":"107","title":"Effects in Rust"},"108":{"body":"For the purpose of this section we're considering effects in the broadest terms: \"Any built-in language mechanism which triggers a bifurcation of the design space\". This means: anything which causes you to create a parallel, alternate copy of the same things is considered an effect in this space. This is probably not the definition we'll want to use in other sections, since effects should probably only ever apply to functions. In this section we're going to use \"effect\" as a catch-all term for \"things that sure seem effect-y\". When discussing effects we'll differentiate between: Scoped Effects : which are effects which apply to functions and scopes, such as async fn which are reified as traits or types such as impl Iterator. Data-Type Effects : which are Effects which apply to data types, encoded as auto-traits. For example: the Send auto-trait is automatically implemented on structs as long as its contained types are Send, and marks it as \"thread-safe\".","breadcrumbs":"📦 Archive » Effects in Rust » What do we mean by \"effect\" in this section?","id":"108","title":"What do we mean by \"effect\" in this section?"},"109":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Asynchrony (Scoped Effect)","id":"109","title":"Asynchrony (Scoped Effect)"},"11":{"body":"Something we're keen on doing is not just adding support for ?async and to apply to functions, traits, and trait bounds. We would like ?async to be possible to use with types as well. This would enable the ecosystem to stop having to provide both sync and async versions of crates. It would also enable the stdlib to gradually \"asyncify\" just like we have been with const. The challenge with async types, especially in the stdlib, is that their behavior will often have to be different when used in async and non-async contexts. At the very lowest level async system calls work a bit differently from non-async system calls. But we think we may have a solution for that too in the form of the is_async compiler built-in method. Say we wanted to implement ?async File with a single ?async open method. The way we expect this to look will be something like this: /// A file which may or may not be async\nstruct ?async File { file_descriptor: std::os::RawFd, // shared field in all contexts async waker: Waker, // field only available in async contexts !async meta: Metadata, // field only available in non-async contexts\n} impl ?async File { /// Attempts to open a file in read-only mode. ?async fn open(path: Path) -> io::Result { if is_async() { // compiler built-in function // create an async `File` here; can use `.await` } else { // create a non-async `File` here } }\n} This would enable authors to use different fields depending on whether they're compiling for async or not, while still sharing a common core. And within function bodies it would be possible to provide different behaviors depending on the context as well. The function body notation would work as a generalization of the currently unstable const_eval_select intrinsic, and at least for the function bodies we expect a similar is_const() compiler built-in to be made available as well.","breadcrumbs":"✏️ Updates » Progress Report February 2023 » Adding support for types","id":"11","title":"Adding support for types"},"110":{"body":"Asynchrony in Rust enables non-blocking operations to be authored in an imperative fashion. This can be helpful for performance reasons, but feature-wise it enables \"arbitrary concurrency\" and \"arbitrary cancellation\" of computations. These can in turn be composed and leveraged by higher-level control-flow primitives such as \"arbitrary timeouts\" and \"arbitrary parallel execution\". Asynchrony in Rust is implemented using a pair of keywords. async is used to create an async context which is reified into a state machine backed by the Future trait. And .await is used on the call-site to access the values inside of an async context. Because .await can only be called inside of async contexts, it eventually needs to be consumed by a top-level function which knows how to run a future to completion.","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Description","id":"110","title":"Description"},"111":{"body":"async/.await in Rust is considered \"MVP stable\". This means the reification of the effect is stable, and both the async and .await keywords exist in the language, but not all keyword positions are available yet.","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Feature Status","id":"111","title":"Feature Status"},"112":{"body":"Position Syntax Effect async Yield N/A Apply .await Consume thread::block_on †, async fn main ‡ Reification impl Future † thread::block_on is not yet part of the stdlib, and only exists as a library feature. An example implementation can be found in the Wake docs. ‡ async fn main is not yet part of the language, and only exists as a proc-macro extension as part of the ecosystem. It chiefly wraps the existing fn main logic in a thread::block_on call.","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Feature categorization","id":"112","title":"Feature categorization"},"113":{"body":"Position Available Example Manual trait impl ✅ impl Future for Cat {} Free functions ✅ async fn meow() {} Inherent functions ✅ impl Cat { async fn meow() {} } Trait methods ⏳ trait Cat { async fn meow() {} } Trait declarations ❌ async trait Cat {} Block scope ✅ fn meow() { async {} } Argument qualifiers ❌ fn meow(cat: impl async Cat) {} Data types † ❌ async struct Cat {} Drop † ❌ impl async Drop for Cat {} Closures ❌ async ǀǀ {} Iterators ❌ for await cat in cats {} † In non-async Rust if you place a value which implements Drop inside of another type, the destructor of that value is run when the enclosing type is destructed. This is called drop-forwarding . In order for drop-forwarding to work with async drop, some form of \"async value\" notation will be required.","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Positions Available","id":"113","title":"Positions Available"},"114":{"body":"Modifier Description cancellation-safe Has no associated future-local state","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Refinements","id":"114","title":"Refinements"},"115":{"body":"\"cancellation-safety\" is currently more like a term of art than an first-class term. It is a property used and relied upon by ecosystem APIs, but it is not represented in the type system anywhere. Which means APIs which rely on \"cancellation-safety\" do so without compiler-backing, which makes them a notorious source of bugs. This should probably be fixed, and when we do we probably will not want to call it \"cancellation-safety\" since it relates less to \"cancellation\" and more to the statefulness of futures, and whether or not they can be recreated without side-effects or data loss.","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Cancellation-Safe Futures","id":"115","title":"Cancellation-Safe Futures"},"116":{"body":"A FusedFuture super-trait also exists, but it does not meaningfully feel like a modifier of the \"async\" effect. It only adds an is_terminated method which returns a bool. It does not inherently change the semantic functioning of the underlying Iterator trait, or enhance it with behavior which is otherwise absent. This is different from e.g. FusedIterator which says something about the behavior of the Iterator::next function. It's also worth noting that the FusedFuture trait is mostly useful for the select! control-flow construct. Without that, FusedFuture would likely not see much use ( ref ).","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Fused Futures","id":"116","title":"Fused Futures"},"117":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Interactions with other effects","id":"117","title":"Interactions with other effects"},"118":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Asynchrony","id":"118","title":"Asynchrony"},"119":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Compile-time Execution","id":"119","title":"Compile-time Execution"},"12":{"body":"As we alluded to earlier in the post: one of the biggest challenges we see in language design is adding features in a way that makes them feel like they're in harmony with the rest of the language - and not something which stands out as noticably different. And because we're touching on something core to Rust, the way we do keywords, we have to pay extra close attention here to make sure Rust keeps feeling like a single language. Luckily Rust has the ability to make surface-level changes to the language through the edition system. There are many things this doesn't let us do, but it does allow us to require syntax changes. A possibility we're exploring is leveraging the edition system to make some minor changes to const and async so they feel more consistent with one another, and with ?const and ?async. For const this means there should be a syntactic distinction between const declarations and const uses. Like we mentioned earlier in the post, when you write const fn you get a function which can be evaluated both at runtime and during compilation. But when you write const FOO: () = ..; the meaning of const there guarantees compile-time evaluation. One keyword, different meanings. So for that reason we're wondering whether perhaps it would make more sense if we changed const fn to ?const fn. This would make it clear that it's a function which may be const-evaluated, but doesn't necessarily have to - and can also be called from non-const contexts. //! Define a function which may be evaluated both at runtime and during\n//! compilation. // Current\nconst fn meow() -> String { .. } // Proposed\n?const fn meow() -> String { .. } For async we're considering some similar surface-level changes. The Async WG is in the process of expanding the \"async functions in traits\" design into an design covering \"async traits\" entirely, largely motivated by the desire to be able to add + Send bound to anonymous futures. There are more details about this in [\"Lightweight, Predictable Async Send Bounds\"][bounds-post] by Eric Holk. But it would roughly become the following notation: struct File { .. }\nimpl async Read for File { // async trait declaration async fn read(&mut self, buf: &mut [u8]) -> io::Result { .. } // async method\n} async fn read_to_string(reader: &mut impl async Read) -> io::Result { // async trait bound let mut string = String::new(); reader.read_to_string(&mut string).await?; Ok(string)\n} This would make impl ?async Read and impl async Read consistent with each other. And it would open the door for trait ?async traits to be passed to impl async Read and be guaranteed to be always interpreted as trait async. Which is another nice consistency gain. The final thing we're looking at is async-notation for types. To implement inherent ?async methods on types, our current design requires the type to also be marked as ?async. In order to bring ?async and async closer together, we're exploring whether it might also make sense to require types to be marked as async as well: //! Proposed: define a method on a maybe-async type\nstruct ?async File { .. }\nimpl ?async File { ?async fn open(path: PathBuf) -> io::Result { .. }\n} //! Current: define a method on an always-async type\nstruct File { .. }\nimpl File { async fn open(path: PathBuf) -> io::Result { .. }\n} //! Proposed: define a method on an always-async type\nstruct async File { .. }\nimpl async File { async fn open(path: PathBuf) -> io::Result { .. }\n} We already have something similar going on for \"always-const\" arguments via the const-generics system. These look something like this: fn foo() {} Every \"always-const\" argument to the function must always be marked by const, so it wouldn't be entirely without precedent for every \"always-async\" type to always require to be marked using async. So we're exploring some of what might be possible here.","breadcrumbs":"✏️ Updates » Progress Report February 2023 » Consistent syntax","id":"12","title":"Consistent syntax"},"120":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Fallibility","id":"120","title":"Fallibility"},"121":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Iteration","id":"121","title":"Iteration"},"122":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Unwinding","id":"122","title":"Unwinding"},"123":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Memory-Safety","id":"123","title":"Memory-Safety"},"124":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Immovability","id":"124","title":"Immovability"},"125":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Object-Safety","id":"125","title":"Object-Safety"},"126":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Ownership","id":"126","title":"Ownership"},"127":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Asynchrony » Thread-Safety","id":"127","title":"Thread-Safety"},"128":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Compile-time Execution (Scoped Effect)","id":"128","title":"Compile-time Execution (Scoped Effect)"},"129":{"body":"The const keyword marks functions as \"is allowed to be evaluated during compilation\". When used in scope position its meaning changes slightly to: \"this will be evaluated during compilation\". There is no way to declare \"must be evaluated at compilation\" functions, causing the meaning of \"const\" to be context-dependent. declaration usage keyword never applies fn meow() {} fn hello() { meow() } keyword always applies - const CAT: () = {}; keyword conditionally applies const fn meow() {} const fn hello() { meow() }","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Description","id":"129","title":"Description"},"13":{"body":"We plan to initially focus our efforts on the async and const keywords only. We're feeling ready to start converting some of our designs into RFCs, and start putting them out for review. In the coming months we expect to start writing the following proposals (in no particular order): ?async fn notation without trait bounds, including an is_async mechanism. trait async declarations and bounds. trait ?async declarations and bounds, trait ?const declarations and bounds. ?const fn notation without trait bounds. struct async notation and struct ?const notation. We'll be working closely with the Lang Team, Const WG, and Async WG on these proposals, and in some cases (such as trait async) we may even take an advicing role with a WG directly driving the RFC. As usual, these will be going through the RFC-nightly-stabilization cycle. And only once we're fully confident in them will they become available on stable Rust. We're intentionally not yet including effect/.do notation on this roadmap. We expect to only be able to start this work once we have ?async on nightly, which we don't yet have. So for now we'll continue work on designing it within the iniatiative, and hold off on making plans to introduce it quite yet.","breadcrumbs":"✏️ Updates » Progress Report February 2023 » The tentative plan","id":"13","title":"The tentative plan"},"130":{"body":"The const feature is integrated in a lot of the stdlib and ecosystem already, but it's notoriously missing any form of const-traits. Because a lot of Rust's language features make use of traits, this means const contexts have no access to iteration, Drop handlers, closures, and more.","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Feature Status","id":"130","title":"Feature Status"},"131":{"body":"Position Syntax Effect const fn Yield N/A Apply automatic Consume const {}, const X: Ty = {} Reification N/A","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Feature categorization","id":"131","title":"Feature categorization"},"132":{"body":"Position Available Example Manual trait impl ❌ N/A Free functions ✅ const fn meow() {} Inherent functions ✅ impl Cat { const fn meow() {} } Trait methods ⏳ trait Cat { const fn meow() {} } Trait declarations ❌ const trait Cat {} Block scope ✅ fn meow() { const {} } Argument qualifiers ❌ fn meow(cat: impl const Cat) {} Data types ❌ const struct Cat {} Drop ❌ impl const Drop for Cat {} Closures ❌ const ǀǀ {} Iterators ❌ for cat in cats {}","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Positions Available","id":"132","title":"Positions Available"},"133":{"body":"There are currently no refiments to the compile-time execution effect.","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Refinements","id":"133","title":"Refinements"},"134":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Interactions with other effects","id":"134","title":"Interactions with other effects"},"135":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Asynchrony","id":"135","title":"Asynchrony"},"136":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Compile-time Execution","id":"136","title":"Compile-time Execution"},"137":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Fallibility","id":"137","title":"Fallibility"},"138":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Iteration","id":"138","title":"Iteration"},"139":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Unwinding","id":"139","title":"Unwinding"},"14":{"body":"And that concludes the 9-month progress report of the Keyword Generics Initiative. We hope to be able to provide more exact details about things such as desugarings, semantics, and alternatives in the RFCs. We're pretty stoked with the progress we've made in these past few months! Something which I don't think we've mentioned yet, but is probably good to share: we've actually prototyped much of the work in this post already; so we're feeling fairly confident all of this may actually actually work. And that is something we're incredibly excited for!","breadcrumbs":"✏️ Updates » Progress Report February 2023 » Conclusion","id":"14","title":"Conclusion"},"140":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Memory-Safety","id":"140","title":"Memory-Safety"},"141":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Immovability","id":"141","title":"Immovability"},"142":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Object-Safety","id":"142","title":"Object-Safety"},"143":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Ownership","id":"143","title":"Ownership"},"144":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » Thread-Safety","id":"144","title":"Thread-Safety"},"145":{"body":"Keywords II: Const Syntax Const as an auto-trait","breadcrumbs":"📦 Archive » Effects in Rust » Compile-Time Execution » References","id":"145","title":"References"},"146":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Fallibility (Scoped Effect)","id":"146","title":"Fallibility (Scoped Effect)"},"147":{"body":"todo","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Feature Status","id":"147","title":"Feature Status"},"148":{"body":"todo","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Description","id":"148","title":"Description"},"149":{"body":"Modifier Description Option Used to describe optional values Result Used to describe errors or success values ControlFlow Used to represent control-flow loops Poll Used to describe the state of Future state machines While the reification of the fallibility effect in bounds ought to be impl Try, it more commonly is the case that we see concrete types used.","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Refinements","id":"149","title":"Refinements"},"15":{"body":"One of Rust's defining features is the ability to write functions which are generic over their input types. That allows us to write a function once, leaving it up to the compiler to generate the right implementations for us. When we introduce a new keyword for something which used to be a trait, we not only gain new functionality - we also lose the ability to be generic over that keyword. This proposal seeks to change that by introducing keyword generics: the ability to be generic over specific keywords. This proposal is scoped to the const and async keywords only, but is designed to be leveraged by other keywords as well in the future. Keywords are valuable, generics are valuable, users of Rust shouldn't have to choose between the two.","breadcrumbs":"📜 Charter » 📜 keyword generics Charter","id":"15","title":"📜 keyword generics Charter"},"150":{"body":"Position Syntax Effect try Yield throw Apply ? Consume match / fn main() † Reification impl Try † fn main implements effect polymorphism over the fallibility effect by making use of the Termination trait . It stands to reason that if we had a try notation for functions, that it should be possible to write try fn main which desugars to a Result type being returned.","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Feature categorization","id":"150","title":"Feature categorization"},"151":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Interactions with other effects","id":"151","title":"Interactions with other effects"},"152":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Asynchrony","id":"152","title":"Asynchrony"},"153":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Compile-time Execution","id":"153","title":"Compile-time Execution"},"154":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Fallibility","id":"154","title":"Fallibility"},"155":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Iteration","id":"155","title":"Iteration"},"156":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » May Panic","id":"156","title":"May Panic"},"157":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Memory-Unsafety","id":"157","title":"Memory-Unsafety"},"158":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Must-not Move","id":"158","title":"Must-not Move"},"159":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Object-Safety","id":"159","title":"Object-Safety"},"16":{"body":"We're in the process of adding new features to Rust. The Const WG is creating an extension to Rust which enables arbitrary computation at compile time. While the Async WG is in the process of adding capabilities for asynchronous computation. We've noticed that both these efforts have a lot in common, and may in fact require similar solutions. This document describes a framework for thinking about these language features, describes their individual needs, and makes the case that we should be considering a generalized language design for \"keywords\" (aka \"definitely not effects\"), so that we can ensure that the Rust language and standard library remain consistent in the face of extensions.","breadcrumbs":"📜 Charter » Proposal","id":"16","title":"Proposal"},"160":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Ownership","id":"160","title":"Ownership"},"161":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Fallibility » Thread-Safety","id":"161","title":"Thread-Safety"},"162":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Iteration (Scoped Effect)","id":"162","title":"Iteration (Scoped Effect)"},"163":{"body":"The Iterator trait has been stable in Rust since 1.0, but the generator syntax is currently unstable . This document will assume that generators are created with the gen keyword, but that's for illustrative purposes only.","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Feature Status","id":"163","title":"Feature Status"},"164":{"body":"todo","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Description","id":"164","title":"Description"},"165":{"body":"Position Syntax Effect gen Yield yield Apply N/A Consume for..in Reification impl Iterator","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Technical Overview","id":"165","title":"Technical Overview"},"166":{"body":"Modifier Description step Has a notion of successor and predecessor operations. trusted len † Reports an accurate length using size_hint. trusted step Upholds all invariants of Step. double-ended Is able to yield elements from both ends. exact size † Knows its exact length. fused Always continues to yield None when exhausted. † The difference between TrustedLen and ExactSizeIterator is that TrustedLen is marked as unsafe to implement while ExactSizeIterator is marked as safe to implement. This means that if TrustedLen is implemented, you can rely on it for safety purposes, while with ExactSizeIterator you cannot.","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Refinements","id":"166","title":"Refinements"},"167":{"body":"Position Available Example Manual trait impl ✅ impl Iterator for Cat {} Free functions ❌ gen fn meow() {} Inherent functions ❌ impl Cat { gen fn meow() {} } Trait methods ❌ trait Cat { gen fn meow() {} } Trait declarations ❌ gen trait Cat {} Block scope ❌ N/A Argument qualifiers ❌ fn meow(cat: impl gen Cat) {} Drop ❌ impl gen Drop for Cat {} Closures ❌ gen ǀǀ {} Iterators ❌ for cat in cats {}","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Positions Available","id":"167","title":"Positions Available"},"168":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Interactions with other effects","id":"168","title":"Interactions with other effects"},"169":{"body":"Overview Description Composition iterator of futures Description Creates an iterator of futures. The future takes the iterator by &mut self, so only a single future may be executed concurrently Example AsyncIterator Implementable as of Rust 1.70? No, async functions in traits are unstable","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Asynchrony","id":"169","title":"Asynchrony"},"17":{"body":"const fn and async fn are similar language extensions, but the way they extend the language is different: const fn creates a subset of \"base Rust\", enabling functions to be executed during compilation. const functions can be executed in \"base\" contexts, while the other way around isn't possible. async fn creates a superset of \"base Rust\", enabling functions to be executed asynchronously. async types cannot be executed in \"base\" contexts [1] , but \"base\" in async contexts is possible. In order to bridge async and non-async Rust, functionality such as thread::block_on or async fn must be used, which runs a future to completion from a synchronous context. const Rust does not require such a bridge, since the difference in contexts is \"compile time\" and \"run-time\". +---------------------------+ | +-----------------------+ | Compute values: | | +-------------------+ | | - types | | | | | | - numbers | | | const Rust |-------{ - functions | | | | | | - control flow Access to the host: | | +-------------------+ | | - traits (planned) - networking | | | | - containers (planned) - filesystem }--------| \"base\" Rust | | - threads | | | | - system time | +-----------------------+ | | | Control over execution: | async Rust |---{ - ad-hoc concurrency | | - ad-hoc cancellation +---------------------------+ - ad-hoc pausing/resumption In terms of standard library these relationships also mirror each other. \"Base\" Rust will want to do everything during runtime what const rust can do, but in addition to that also things like network and filesystem IO. Async Rust will in turn want to do everything \"base\" Rust can do, but in addition to that will also want to introduce methods for ad-hoc concurrency, cancellation, and execution control. It will also want to do things which are blocking in \"base\" Rust as non-blocking in async Rust. And it doesn't stop with const and async Rust; it's not hard to imagine that other annotations for \"can this panic\", \"can this return an error\", \"can this yield values\" may want to exist as well. All of which would present extensions to the \"base\" Rust language, which would need to be introduced in a way which keeps it feeling like a single language - instead of several disjoint languages in a trenchcoat.","breadcrumbs":"📜 Charter » A broad perspective on language extensions","id":"17","title":"A broad perspective on language extensions"},"170":{"body":"Overview Description Composition iterator of tryables Description Creates an iterator of tryables, typically an iterator of Result Example FallibleIterator Implementable as of Rust 1.70? No, try in traits is not available","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Fallibility","id":"170","title":"Fallibility"},"171":{"body":"Overview Description Composition const iterator Description Creates an iterator which can be iterated over at compile-time Example N/A Implementable as of Rust 1.70? No, const traits are unstable","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Compile-time Execution","id":"171","title":"Compile-time Execution"},"172":{"body":"Overview Description Composition iterator of tryables Description Creates an iterator whose items which can be sent across threads Example where I: Iterator- , T: Send Implementable as of Rust 1.70? Yes, as a bound on use. And by unit-testing the Send auto-trait on decls.","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Thread-Safety","id":"172","title":"Thread-Safety"},"173":{"body":"Overview Description Composition an iterator which takes self: Pin<&mut Self> Description An iterator which itself holds onto self-referential data Example N/A Implementable as of Rust 1.70? Yes","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Immovability","id":"173","title":"Immovability"},"174":{"body":"Overview Description Composition iterator may panic instead of yield Description Creates an iterator which may panic Example Iterator (may panic by default) Implementable as of Rust 1.70? Yes, but cannot opt-out of \"may panic\" semantics","breadcrumbs":"📦 Archive » Effects in Rust » Iteration » Unwinding","id":"174","title":"Unwinding"},"175":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Unwinding (Scoped Effect)","id":"175","title":"Unwinding (Scoped Effect)"},"176":{"body":"todo","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Feature Status","id":"176","title":"Feature Status"},"177":{"body":"todo","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Description","id":"177","title":"Description"},"178":{"body":"Modifier Description The panic effect currently has no refinements.","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Refinements","id":"178","title":"Refinements"},"179":{"body":"Position Syntax Effect N/A Yield panic! Apply foo() / resume_unwind Consume catch_unwind / fn main Reification N/A Panics differ from all other control-flow oriented effects because every function is assumed to potentially panic. This means that the syntax to forward a panic from a function is just a regular function call. Panics are not represented in the type system, instead they exist as a property outside of it.","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Feature categorization","id":"179","title":"Feature categorization"},"18":{"body":"Role Github Owner Yosh Wuyts Owner Oli Scherer Liaison Niko Matsakis?","breadcrumbs":"📜 Charter » Membership","id":"18","title":"Membership"},"180":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Interactions with other effects","id":"180","title":"Interactions with other effects"},"181":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Asynchrony","id":"181","title":"Asynchrony"},"182":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Compile-time Execution","id":"182","title":"Compile-time Execution"},"183":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Fallibility","id":"183","title":"Fallibility"},"184":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Iteration","id":"184","title":"Iteration"},"185":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Unwinding","id":"185","title":"Unwinding"},"186":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Memory-Safety","id":"186","title":"Memory-Safety"},"187":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Immovability","id":"187","title":"Immovability"},"188":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Object-Safety","id":"188","title":"Object-Safety"},"189":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Ownership","id":"189","title":"Ownership"},"19":{"body":"The evaluation surveys the various design approaches that are under consideration. It is not required for all initiatives, only those that begin with a problem statement but without a clear picture of the best solution. Often the evaluation will refer to topics in the design-discussions for more detailed consideration.","breadcrumbs":"🔬 Evaluation » 🔬 Evaluation","id":"19","title":"🔬 Evaluation"},"190":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Unwinding » Thread-Safety","id":"190","title":"Thread-Safety"},"191":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Memory Safety (Scoped Effect)","id":"191","title":"Memory Safety (Scoped Effect)"},"192":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Asynchrony","id":"192","title":"Asynchrony"},"193":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Compile-time Execution","id":"193","title":"Compile-time Execution"},"194":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Fallibility","id":"194","title":"Fallibility"},"195":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Iteration","id":"195","title":"Iteration"},"196":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Unwinding","id":"196","title":"Unwinding"},"197":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Memory-Safety","id":"197","title":"Memory-Safety"},"198":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Immovability","id":"198","title":"Immovability"},"199":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Object-Safety","id":"199","title":"Object-Safety"},"2":{"body":"The following table lists of the stages of an initiative, along with links to the artifacts that will be produced during that stage. Stage State Artifact(s) Proposal 🦀 Proposal issue Charter Tracking issue Experimental 🦀 Evaluation RFC Development 💤 Explainer Feature complete 💤 Stabilization report Stabilized 💤 Key: ✅ -- phase complete 🦀 -- phase in progress 💤 -- phase not started yet","breadcrumbs":"👋 Welcome » Current status","id":"2","title":"Current status"},"20":{"body":"","breadcrumbs":"🔬 Evaluation » Syntax » Syntax","id":"20","title":"Syntax"},"200":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Ownership","id":"200","title":"Ownership"},"201":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » Thread-Safety","id":"201","title":"Thread-Safety"},"202":{"body":"Keywords I: Unsafe Syntax","breadcrumbs":"📦 Archive » Effects in Rust » Memory-Safety » References","id":"202","title":"References"},"203":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Immovability (Data-Type Effect)","id":"203","title":"Immovability (Data-Type Effect)"},"204":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Interactions with other effects","id":"204","title":"Interactions with other effects"},"205":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Asynchrony","id":"205","title":"Asynchrony"},"206":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Compile-time Execution","id":"206","title":"Compile-time Execution"},"207":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Fallibility","id":"207","title":"Fallibility"},"208":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Iteration","id":"208","title":"Iteration"},"209":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Unwinding","id":"209","title":"Unwinding"},"21":{"body":"Name: (fill me in: name-of-design) Proposed by: [@name](link to github profile) Original proposal (optional): (url)","breadcrumbs":"🔬 Evaluation » Syntax » Template » Design","id":"21","title":"Design"},"210":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Memory-Safety","id":"210","title":"Memory-Safety"},"211":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Immovability","id":"211","title":"Immovability"},"212":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Object-Safety","id":"212","title":"Object-Safety"},"213":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Ownership","id":"213","title":"Ownership"},"214":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Immovability » Thread-Safety","id":"214","title":"Thread-Safety"},"215":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Object Safety (Data-Type Effect)","id":"215","title":"Object Safety (Data-Type Effect)"},"216":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Asynchrony","id":"216","title":"Asynchrony"},"217":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Compile-time Execution","id":"217","title":"Compile-time Execution"},"218":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Fallibility","id":"218","title":"Fallibility"},"219":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Iteration","id":"219","title":"Iteration"},"22":{"body":"/// A trimmed-down version of the `std::Iterator` trait.\npub trait Iterator { type Item; fn next(&mut self) -> Option; fn size_hint(&self) -> (usize, Option);\n} /// An adaptation of `Iterator::find` to a free-function\npub fn find(iter: &mut I, predicate: P) -> Option\nwhere I: Iterator
- + Sized, P: FnMut(&T) -> bool;","breadcrumbs":"🔬 Evaluation » Syntax » Template » base (reference)","id":"22","title":"base (reference)"},"220":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Unwinding","id":"220","title":"Unwinding"},"221":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Memory-Safety","id":"221","title":"Memory-Safety"},"222":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Immovability","id":"222","title":"Immovability"},"223":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Object-Safety","id":"223","title":"Object-Safety"},"224":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Ownership","id":"224","title":"Ownership"},"225":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Object-Safety » Thread-Safety","id":"225","title":"Thread-Safety"},"226":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Ownership (Data-Type Effect)","id":"226","title":"Ownership (Data-Type Effect)"},"227":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Description","id":"227","title":"Description"},"228":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Feature Status","id":"228","title":"Feature Status"},"229":{"body":"Position Syntax Effect Yield Apply Consume Reification","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Feature categorization","id":"229","title":"Feature categorization"},"23":{"body":"// fill me in","breadcrumbs":"🔬 Evaluation » Syntax » Template » always async","id":"23","title":"always async"},"230":{"body":"Position Available Example Manual trait impl ✅ impl Future for Cat {} Free functions ✅ async fn meow() {} Inherent functions ✅ impl Cat { async fn meow() {} } Trait methods ⏳ trait Cat { async fn meow() {} } Trait declarations ❌ async trait Cat {} Block scope ✅ fn meow() { async {} } Argument qualifiers ❌ fn meow(cat: impl async Cat) {} Data types † ❌ async struct Cat {} Drop † ❌ impl async Drop for Cat {} Closures ❌ async ǀǀ {} Iterators ❌ for await cat in cats {}","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Positions Available","id":"230","title":"Positions Available"},"231":{"body":"Modifier Description","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Refinements","id":"231","title":"Refinements"},"232":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Interactions with other effects","id":"232","title":"Interactions with other effects"},"233":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Asynchrony","id":"233","title":"Asynchrony"},"234":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Compile-time Execution","id":"234","title":"Compile-time Execution"},"235":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Fallibility","id":"235","title":"Fallibility"},"236":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Iteration","id":"236","title":"Iteration"},"237":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Unwinding","id":"237","title":"Unwinding"},"238":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Memory-Safety","id":"238","title":"Memory-Safety"},"239":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Immovability","id":"239","title":"Immovability"},"24":{"body":"// fill me in","breadcrumbs":"🔬 Evaluation » Syntax » Template » maybe async","id":"24","title":"maybe async"},"240":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Object-Safety","id":"240","title":"Object-Safety"},"241":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Ownership","id":"241","title":"Ownership"},"242":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » Thread-Safety","id":"242","title":"Thread-Safety"},"243":{"body":"Keywords II: Const Syntax","breadcrumbs":"📦 Archive » Effects in Rust » Ownership » References","id":"243","title":"References"},"244":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Thread-Safety (Data-Type Effect)","id":"244","title":"Thread-Safety (Data-Type Effect)"},"245":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Interactions with other effects","id":"245","title":"Interactions with other effects"},"246":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Asynchrony","id":"246","title":"Asynchrony"},"247":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Compile-time Execution","id":"247","title":"Compile-time Execution"},"248":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Fallibility","id":"248","title":"Fallibility"},"249":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Iteration","id":"249","title":"Iteration"},"25":{"body":"// fill me in","breadcrumbs":"🔬 Evaluation » Syntax » Template » generic over all modifier keywords","id":"25","title":"generic over all modifier keywords"},"250":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Unwinding","id":"250","title":"Unwinding"},"251":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Memory-Safety","id":"251","title":"Memory-Safety"},"252":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Immovability","id":"252","title":"Immovability"},"253":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Object-Safety","id":"253","title":"Object-Safety"},"254":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Ownership","id":"254","title":"Ownership"},"255":{"body":"","breadcrumbs":"📦 Archive » Effects in Rust » Thread-Safety » Thread-Safety","id":"255","title":"Thread-Safety"},"256":{"body":"One implication of the subset-superset relationship is that code which is generic over effects will not be able to use all functionality of the superset in the subset case. Though it will need to use the syntax of the superset. Take for examle the following code. It takes two async closures, awaits them, and sums them: // Sum the output of two async functions:\n~async fn sum( lhs: impl ~async FnMut() -> T, rhs: impl ~async FnMut() -> T\n) -> T { let lhs = lhs().await; let rhs = rhs().await; lhs + rhs\n} One of the benefits of async execution is that we gain ad-hoc concurrency , so we might be tempted to perform the comptutation of lhs and rhs concurrently, and summing the output once both have completed. However this should not be possible solely using effect polymorphism since the generated code needs to work in both async and non-async contexts. // Sum the output of two async functions:\n~async fn sum( lhs: impl ~async FnMut() -> T, rhs: impl ~async FnMut() -> T\n) -> T { let (lhs, rhs) = (lhs(), rhs()).join().await; // ^^^^^^^ // error: cannot call an `async fn` from a `~async` context // hint: instead of calling `join` await the items sequentially // or consider writing an overload instead lhs + rhs\n} And this is not unique to async: in maybe-const contexts we cannot call functions from the super-context (\"base Rust\") since those cannot work during const execution. This leads to the following implication: Conditional effect implementations require the syntactic annotations of the super-context, but cannot call functions which exclusively work in the super-context.","breadcrumbs":"📦 Archive » Effect hierarchy » Implications of the effect hierarchy","id":"256","title":"Implications of the effect hierarchy"},"257":{"body":"We expect it to be common that if a function takes generics and has conditional keywords on those, it will want to be conditional over all keywords on those generics. So in order to not have people repeat params over and over, we should provide shorthand syntax. Here is the \"base\" variant we're changing: // without any effects\nfn find( iter: impl Iterator
- , closure: impl FnMut(&I) -> bool,\n) -> Option { ... } We could imagine wanting a fallible variant of this which can short-circuit based on whether an Error is returned or not. We could imagine the \"base\" version using a TryTrait notation, and the \"effect\" version using the throws keyword. Both variants would look something like this: // fallible without effect notation\nfn try_find( iter: impl TryIterator
- , closure: impl TryFnMut<(&I), E> -> bool,\n) -> Result