impl<T> Cell<Option<T>>

[Soni]

Sometimes when dealing with re-entrant code your only option is to use Cell<Option>, and unfortunately those are a pain to work with.

Unfortunately Cell.set is already taken, so it'd have to be something like Cell.put for the Option variant. (At least Cell.take already uses Default and works with Option out of the box, so on that end it's a non-issue.)

Can we have Cell<Option<T>>.put?

Motivation:

#[macro_use]
extern crate hexchat_plugin;

use hexchat_plugin::Plugin as HexchatPlugin;
use hexchat_plugin::PluginHandle as Ph;
use hexchat_plugin::CommandHookHandle;

#[derive(Default)]
struct Cw2Plugin {
    cmd_cw: Cell<Option<CommandHookHandle>>,
}

impl HexchatPlugin for Cw2Plugin {
    fn init(&self, ph: &mut Ph, _arg: Option<&str>) -> bool {
        ph.register("CW2", "1.0.0", "Adds support for rot13-based content warnings.");
        self.cmd_cw.set(Some(ph.hook_command("cw", |ph, arg, arg_eol| {
            todo!()
        }, 0, Some("Sends a content warning. Usage: "))));
        true
    }
}

hexchat_plugin!(Cw2Plugin);

[Nokel81]

What exactly are you asking for? Including at least the signature of the function you are asking about is the bare minimum to help in the discussion.

Is this basically .set but requiring T and not Option<T>?

[Soni]

impl<T> Cell<Option<T>> {
  fn put(&self, t: T) {
    self.set(Some(t));
  }
}

Some could say Cell<Option<T>> is DropFlagsThatCanBePutInAStruct<T>

[jhpratt]

What's wrong with cell.set(Some(t))?

[Soni]

too much )))) mostly.

it really doesn't look nice in context.

[CAD97]

If you're using Cell<Option<T>> a lot, it makes sense to make it a new type, and at that point you can put whatever methods on it you want.

[jhpratt]

It's two right parens. There are situations where there are far more than that and nobody blinks. I agree with @CAD97 — create a newtype if it's that important to you.

Keep in mind that this would only solve one situations; what would happen if someone then wanted Cell<Result<T, E>>? Add a new method for that? What about Either<T>? The requests would never end.

[Soni]

None of those are relevant in re-entrant initializers, tho.