Both ops::num and ops::str could very much use the guard condition pattern with let-else instead, so that the actual intended logic of the runner function isn't nested one more.
All of these dev commands seem like they'd belong into tests using #[test] instead.
Also regarding the enum-based arch: Why the indirection of fn(&Inputs) -> Outputs? Why does Pipeline not hold Box<dyn Element> as well?
Wait, why is Outputs allowed to be consumed for its inner content consumed while Inputs doesn't?
Nit: Is there clarity gained in prefixing the variable name with dev_ given it's always taken out of the Dev variant?
Nit: Regarding formatting, you may want to split the newly added entry to its own line.
Why do Add, Subtract, Concatenate hold a pub i32 if it's never used?
Those TODO:s seem like they should belong in an issue, so one can
I already see that this is a newtype around OwnedData, just re-stating it does not add semantical value. Rather, what would this struct be used for?
I've decided I do not want to contribute to iOwO anymore, due to lack of general cooperativity and @schrottkatze not willing to discuss things such as using vulkano that are, apparently, set in…
Since you want to do the first one in a mega-PR, I'll focus on IR handling and source in meantime.
And I'd say that we specify a Streamer as a function that generates output without any input, and add a "sink" as a function that just takes in inputs and is effectively the end of a given…
I want ir::GraphIr to be the single source of truth regarding the IR, and not a programmatic in-between that is kinda-for-human-interaction-but-not-really that breaks type safety.
For…
Actually, if it causes this much confusion, I'll just remove the comment here to make the other one the single source of truth.