-
-
Notifications
You must be signed in to change notification settings - Fork 1
In-place-dropping setters for UnmanagedSignalCell #10
Copy link
Copy link
Open
Labels
breakingIntroduces or requests a breaking change.Introduces or requests a breaking change.domain: RustInvolves Rust code.Involves Rust code.effort: 2Relative effort required. There's no specific unit of measurement.Relative effort required. There's no specific unit of measurement.good first issueGood for newcomersGood for newcomersstate: questionFurther information is requestedFurther information is requestedtype: featureBrand new functionality, features, pages, workflows, endpoints, etc.Brand new functionality, features, pages, workflows, endpoints, etc.work: clearA known solution is (to be) implemented.A known solution is (to be) implemented.
Milestone
Description
Activity
Metadata
Metadata
Assignees
Labels
breakingIntroduces or requests a breaking change.Introduces or requests a breaking change.domain: RustInvolves Rust code.Involves Rust code.effort: 2Relative effort required. There's no specific unit of measurement.Relative effort required. There's no specific unit of measurement.good first issueGood for newcomersGood for newcomersstate: questionFurther information is requestedFurther information is requestedtype: featureBrand new functionality, features, pages, workflows, endpoints, etc.Brand new functionality, features, pages, workflows, endpoints, etc.work: clearA known solution is (to be) implemented.A known solution is (to be) implemented.
Projects
- StatusShow more project fieldsNo status
Is your feature request related to a problem? Please describe.
I'd like to have additional setters that are guaranteed to drop the previous value in place, both unconditional variants (like
replace) and ones that usePartialEq(likechange). Returning the previous value makes unconditional…_eagerFutures larger than they'd otherwise need to be.Describe the solution you'd like
The implementation can be just about the same as that of the
replaceandchangemethods, but without returning the value.(The current implementation of the deferred versions of these accessors in fact already does that, but doesn't guarantee it.)
Describe alternatives you've considered
-
Additional context
I forgot this somewhere along the way 😬
Most likely when I decided that I didn't want an accessor called
setfor cells, as I want to encourage use ofchangeinstead.Since this is a breaking change, it should be developed against the
flourish-nextbranch.