Don't break semver compatibility when enabling a feature

[Hofer-Julian]

Looking at the code, configparser changes the function signature depending on whether the indexmap feature is introduced.

configparser-rs/src/ini.rs

Lines 3 to 6 in 671c19c

	#[cfg(feature = "indexmap")]
	use indexmap::IndexMap as Map;
	#[cfg(not(feature = "indexmap"))]
	use std::collections::HashMap as Map;

This shouldn't happen, according to the Cargo book: https://doc.rust-lang.org/cargo/reference/features.html#semver-compatibility

I think the proper way is to expose additional functions when the feature indexmap is enabled.

[Hofer-Julian]

For a bit of context: we encountered this issue since we had configparser twice in our dependency tree. Once with and once without indexmap enabled. This leads to Cargo compiling a single version with indexmap enabled. The crate that depended on configparser without indexmap therefore refused to compile since the function signature changed.

[QEDK]

For a bit of context: we encountered this issue since we had configparser twice in our dependency tree. Once with and once without indexmap enabled. This leads to Cargo compiling a single version with indexmap enabled. The crate that depended on configparser without indexmap therefore refused to compile since the function signature changed.

That's interesting but Rust does not give a good way for us to tackle this yet. This was the best idea when implemented because the user-facing API remains consistent. Having additional functions is not frictionless because the underlying structure needs to change regardless. Maybe a good idea is an enum-based attribute but this needs more thought imo. I will wait for more community input.

[Hofer-Julian]

Yeah, I don't think there's a way to fix this without a breaking change.

If you want to avoid duplicating functions at the API level, and probably neither internally, you could make a trait with all Map methods you use and make everything generic over that trait.