Nothing in byld can happen because time passed
A view can react to input, and now to a controller reply. It cannot react to
the clock. There is no every, no interval, no after — a grep of
intrinsics.rs finds nothing — so periodic refresh is not expressible at all.
That rules out an entire category of app, and not an exotic one: a forecast
that goes stale, a feed that polls, a session clock, a token that expires, a
toast that dismisses itself. Every one of them is "run this again in N
seconds", and today the only way to get it is to make the user press something.
Why it cannot just be a Tokio task
The obvious shape — spawn a task that sends a message every N seconds — gets
two things wrong that are expensive to discover later.
It outlives its scope. A screen that polls, closed, is still polling.
Nothing about that is visible: the task keeps firing into a view nobody can
see, writing vars nobody is watching, until something eventually notices the
CPU. INV-10 says no leaked subscriptions or timers on unmount, and a timer is
the one construct in the language whose leak has no symptom.
It needs a second delivery path. A tick has to reach the logic thread, run
an action, write a var, and mark it — which is exactly what a controller
reply does. Giving it its own channel would mean a second set of ordering
rules, a second continuation lifetime, and a second waker amendment, all of
which have to be kept in step with the first set forever.
The unit problem
The lexer knows ms (RFC-0010) and s (RFC-0025). A refresh interval is
naturally written in minutes, and every 300000ms is a sentence in which a
mistyped zero is invisible.
What this must not become
every 16ms is not an animation. The animation runtime (RFC-0010, RFC-0025)
evaluates curves per frame and is the thing to use for motion; a timer runs its
action on the logic thread and is for seconds-scale work. The distinction has
to be stated where people will read it, or timers will be used for motion and
motion will get worse.
Scope
RFC-0029 O4 / §5: the every/after grammar, the min suffix, the timer
driver on the Tokio time driver, and delivery through the RFC-0028 apply path.
Persistence (O5) is a separate change.
Nothing in
byldcan happen because time passedA view can react to input, and now to a controller reply. It cannot react to
the clock. There is no
every, nointerval, noafter— a grep ofintrinsics.rsfinds nothing — so periodic refresh is not expressible at all.That rules out an entire category of app, and not an exotic one: a forecast
that goes stale, a feed that polls, a session clock, a token that expires, a
toast that dismisses itself. Every one of them is "run this again in N
seconds", and today the only way to get it is to make the user press something.
Why it cannot just be a Tokio task
The obvious shape — spawn a task that sends a message every N seconds — gets
two things wrong that are expensive to discover later.
It outlives its scope. A screen that polls, closed, is still polling.
Nothing about that is visible: the task keeps firing into a view nobody can
see, writing
vars nobody is watching, until something eventually notices theCPU. INV-10 says no leaked subscriptions or timers on unmount, and a timer is
the one construct in the language whose leak has no symptom.
It needs a second delivery path. A tick has to reach the logic thread, run
an action, write a
var, and mark it — which is exactly what a controllerreply does. Giving it its own channel would mean a second set of ordering
rules, a second continuation lifetime, and a second waker amendment, all of
which have to be kept in step with the first set forever.
The unit problem
The lexer knows
ms(RFC-0010) ands(RFC-0025). A refresh interval isnaturally written in minutes, and
every 300000msis a sentence in which amistyped zero is invisible.
What this must not become
every 16msis not an animation. The animation runtime (RFC-0010, RFC-0025)evaluates curves per frame and is the thing to use for motion; a timer runs its
action on the logic thread and is for seconds-scale work. The distinction has
to be stated where people will read it, or timers will be used for motion and
motion will get worse.
Scope
RFC-0029 O4 / §5: the
every/aftergrammar, theminsuffix, the timerdriver on the Tokio time driver, and delivery through the RFC-0028 apply path.
Persistence (O5) is a separate change.