-
Notifications
You must be signed in to change notification settings - Fork 1
Description
This crate touts that it's good to be able to see what effects your system has just by looking at its return type, but there's an issue there. Many effects are annoying to express in a return type. In these cases, using type inference and returning impl Effect + use<> can help (or, in cases where only one part of the effect is complicated, just using the inference in that spot e.g. -> (ResSet<ClearColor>, Option<impl Effect + use<>>).
However, some of these cases are really more annoying than they need to be. For example, the fact that command_spawn returns a CommandSpawnAnd, which has a function in its generics, would require users to do something like -> CommandSpawnAnd<MyComponent, impl Fn(Entity) -> ()> to avoid using impl Effect. That extra function type argument is obfuscated during the construction of command_spawn, as opposed to command_spawn_and, but it still shows up in the return type. If command_spawn instead returned a new effect CommandSpawn<C>, the irrelevant function type parameter remains irrelevant.
This issue is for doing this everywhere. If a simpler constructor exists, give it a new, simpler effect type. The simpler effect types can convert into the more expressive ones in their Effect implementation, if that's the best way to reduce code.