Something the app is telling the user, unprompted.
Two concepts, not one with a placement. They differ in more than where they
sit: a toast is transient, stacked and self-dismissing, and a banner is
persistent, in flow, one per region, and dismissed by fixing the condition
it reports. Folding them into one member with a placement parameter would
make lifetime, stacking and dismissal all placement-dependent, which is the
description leaking renderer policy.
All three apps have banners: info_banner and warning_banner in
audiofiles, five of them in goingson (sync, sync-result, vacation-day,
timer-active, past-review), .update-banner in Balanced Breakfast. The two
webview apps also have toasts. So neither member is speculative, and no app
gains a concept it lacks except audiofiles, whose renderer may legitimately
decline to draw a toast at all.
Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.
A toast floats above the page rather than resting on it, which is
Fill::Overlay’s whole reason to exist. A banner is a card in the
flow. Both are raised, and they are raised off different things.