What problem does this solve?
Keywords are expensive. Every keyword is a reserved word that users can't use as an identifier. The entropy benchmark shows 31 keywords used out of 38 slots (Go uses 25), leaving 7 slots of headroom. Worth asking whether detached needs to be one of them.
detached
detached could be a stdlib function: detach(async f()) instead of detached async f(). Same semantics, one fewer keyword.
Counter-argument: the async RFC intentionally made detached a keyword to signal "explicit opt-out of structured concurrency." Moving it to stdlib weakens that signal.
blocking
blocking overlaps with resolve semantics.
Actually, these serve different purposes:
blocking f() calls a suspendable function and returns T directlyresolve task! consumes a Task[T] handle
They're not interchangeable. blocking probably stays.
Proposed action
Evaluate whether detached alone can move to stdlib. blocking likely needs to remain a keyword since it changes call semantics at the call site.
Area
Language syntax
What problem does this solve?
Keywords are expensive. Every keyword is a reserved word that users can't use as an identifier. The entropy benchmark shows 31 keywords used out of 38 slots (Go uses 25), leaving 7 slots of headroom. Worth asking whether
detachedneeds to be one of them.detached
detachedcould be a stdlib function:detach(async f())instead ofdetached async f(). Same semantics, one fewer keyword.Counter-argument: the async RFC intentionally made
detacheda keyword to signal "explicit opt-out of structured concurrency." Moving it to stdlib weakens that signal.blocking
blockingoverlaps withresolvesemantics.Actually, these serve different purposes:
blocking f()calls a suspendable function and returnsTdirectlyresolve task!consumes aTask[T]handleThey're not interchangeable.
blockingprobably stays.Proposed action
Evaluate whether
detachedalone can move to stdlib.blockinglikely needs to remain a keyword since it changes call semantics at the call site.Area
Language syntax