You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just finished reading Yoshua's Article on Totality, which got my thinking more about this proposal and its potentially massive implications for future versions of Rust. Is the desire for this proposal to allow for a future edition of Rust where a function could be marked as total (or perhaps even instead be marked as not total)?
There's some pretty serious consequences to Rust in a world where evaluation context is a generic. I know this proposal refers to async and const as effects, but I feel that the term context makes more sense for what it describes. Regardless, I could imagine a hypothetical alloc context, which provides access to an allocator. Without access to the alloc context, a function cannot evaluate expressions which require access to the allocator.
For Leptos, the view! macro needs to be passed an explicit Scope parameter. Perhaps in a world where a leptos effect could be defined, that Scope parameter could be made implicit as a part of the calling of leptos functions.
I really like the idea of trying to pair back functions in Rust down to the level of totality, and then opting back into contexts as they're required.
The text was updated successfully, but these errors were encountered:
Is the desire for this proposal to allow for a future edition of Rust where a function could be marked as total (or perhaps even instead be marked as not total)?
Not necessarily. I view "totality" more of a useful tool to model effects through, rather than something which we must necessarily be able to express directly. This is probably the key part from the post:
Perhaps one day we will want to enable expressing "total" functions in Rust. But for now the effects initiative isn't working to add support for that, even if some members (me) think it could perhaps be a useful addition one day.
Regarding terminology: we're going to have to figure out what we want to call things in the final proposal. "effects" is a well-established academic term for what we're doing here. But sure yeah, maybe "contexts" could work as well. There can be reasons why we don't want to match existing terminology.
I just finished reading Yoshua's Article on Totality, which got my thinking more about this proposal and its potentially massive implications for future versions of Rust. Is the desire for this proposal to allow for a future edition of Rust where a function could be marked as total (or perhaps even instead be marked as not total)?
There's some pretty serious consequences to Rust in a world where evaluation context is a generic. I know this proposal refers to
async
andconst
aseffect
s, but I feel that the termcontext
makes more sense for what it describes. Regardless, I could imagine a hypotheticalalloc
context, which provides access to an allocator. Without access to thealloc
context, a function cannot evaluate expressions which require access to the allocator.For Leptos, the
view!
macro needs to be passed an explicitScope
parameter. Perhaps in a world where aleptos
effect could be defined, thatScope
parameter could be made implicit as a part of the calling ofleptos
functions.I really like the idea of trying to pair back functions in Rust down to the level of totality, and then opting back into contexts as they're required.
The text was updated successfully, but these errors were encountered: