You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide traits / types that can be collected into a workflow task graph.
Whether or not to track operation support through an enum.
If an operation is not supported, should we track it via an enum, and require implementors to choose a variant? Maybe not -- it adds complexity to the API that may not be necessary in the common case.
If we had one, it may look like the following snippet:
#[derive(Debug)]pubenumOpOutputMaybe{/// This operation is not supported.NotSupported{/// Message to display when this operation is run.////// This may be a link to an issue to explain why this is not supported.suggestion:Option<String>,},/// Nothing needs to be done for this to work.Unnecessary,/// This logic has not been written yet.ImplPending{/// Message to display when this operation is run.////// This may be a link to an issue to implement this operation.suggestion:Option<String>,},}
The text was updated successfully, but these errors were encountered:
DataInit trait should not be a constraint on the data types, otherwise consumers cannot use third party data types without wrapping them in newtypes then implementing DataInit on the newtypes.
Data derive should reference peace::data::.. because it's inconvenient to import about 5 other types to get them in scope. For peace_* crates, adding a #[peace_internal] attribute or similar will change the module reference to peace_data::...
Perhaps add another layer around R<'_, T> + a trait, so that ROption<'_, T> will pass Option<R<'_, T>> to the operation, but RExpect<'_, T> will pass R<'_, T>, but err if T was not in Resources. Or perhaps always return R<'_, T> like we do now, and we require initialization earlier -- Err if any types in borrows/borrow_muts are not initialized.
Provide traits / types that can be collected into a workflow task graph.
Whether or not to track operation support through an enum.
If an operation is not supported, should we track it via an enum, and require implementors to choose a variant? Maybe not -- it adds complexity to the API that may not be necessary in the common case.
If we had one, it may look like the following snippet:
The text was updated successfully, but these errors were encountered: