We could use a pattern similar to @BurntSushi's InferContext::report_lint where the inital function returns an Option<Builder> and the builder allows you to perform the typing import.

pub(crate) fn typing_importer(&self, version_added_to_typing: PythonVersion) -> Option<TypingImporte> {
	let source_module = if self.target_version() >= version_added_to_typing {            "typing"
	} else if self.settings.disable_typing_extensions {
  	return None;
	} else {
		"typing_extensions"
	};
	
	Some(TypingImporter { checker: self, source_module })
}

pub struct TypingImporter<'a> {
	checker: &'a Checker,
	source_module: &'static src
}

impl TypingImporter<'_> {
	pub fn import(member: &str, position: TextSize) -> Result<(Edit, String), ResolutionError> {
		... 
	}
}

I'm a bit undecided if member should be passed to typing_importer to avoid accidential reuse.

A simpler alternative would be to return Option<Result<...>, but that's a bit less common but could be fine too.

Oh, I like that idea, I'll give it a try!

I vaguely remember trying Option<Result> and not liking it for some reason, but maybe that was when I thought try_set_optional_fix was still going to work.

I feel like we do want member passed to typing_importer because it's the piece that needs to be tied most closely to the PythonVersion. I don't remember seeing any places where intentional reuse would be very helpful, so avoiding the accidental cases makes sense to me.

Do we need to update the rule's fix availability documentation (same for other rules) to explain that the fix isn't available if typing extensions isn't available?

Yes, very good point, thanks!

bikeshedding: The disable prefix is uncommon in our existing settings and simply typing_extensions would be more idiomatic or allow_typing_extensions.

Ah, I always like options that default to false so that I can use bool::default 😆 but either of those names is fine with me

Is it okay that we treat "typing-extensions" not being available the same as the import failing (will this suppress the diagnostic or only fail to generate the fix?)

I believe all of the calls in this file are okay because they use PythonVersion::lowest. I think we could even expect or unwrap instead of the first ?, if we wanted, because we should always get a TypingImporter for any supported Python version.