Given the common pattern of AsRef in the stdlib and InstructionRef already being used in this project, how about renaming OwnedData → Data and Data below → DataRef?
Quite ambiguous doc-comment also regarding the rather lengthy doc-comment on the type itself.
All of these dev commands seem like they'd belong into tests using #[test] instead.
Why do Add, Subtract, Concatenate hold a pub i32 if it's never used?
Could use Option::ok_or with Result::or_else (untested):
Given that you use a module comment at the very start of this file, it seems like these doc-comments would also belong into their respective modules.
Wait, why is Outputs allowed to be consumed for its inner content consumed while Inputs doesn't?
Nit: Regarding formatting, you may want to split the newly added entry to its own line.
Also regarding the enum-based arch: Why the indirection of fn(&Inputs) -> Outputs? Why does Pipeline not hold Box<dyn Element> as well?
Those TODO:s seem like they should belong in an issue, so one can
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.