Expose remaining environment API

[ghost]

Many of the calls for get_raw, set_raw, and cmd_raw aren't modeled properly. Effort should be focused on getting them exposed in an idiomatic way so that more of the unsafe API surface is reduced. This doesn't need to be as restrictive as #2 for the moment, but laying the groundwork for it would be nice.

[InquisitiveCoder]

Should we bother implementing the experimental commands? Since they could change or be removed at any time, any safe Rust interface we implement would be unstable and could become unsafe.

[ghost]

Should we bother implementing the experimental commands? Since they could change or be removed at any time, any safe Rust interface we implement would be unstable and could become unsafe.

I'd be okay with putting these behind a feature flag, with the advisory that these are unstable and subject to change. Those that are willing to take the plunge do so at their own risk, and we would officially not consider it public API from a semver perspective. Perhaps experimental?

[InquisitiveCoder]

Makes sense. I'll implement those last, then.

[ghost]

I've thought about this more, and the idea that this crate could be used to create potentially invalid cores I think means we should hold off implementing environment calls until they are stabilized. The *_raw functions still exist if someone wants to do something exotic, but I don't want to officially support them (By adding our own APIs) until they're stable.

[InquisitiveCoder]

After thinking about it some more, I don't think the experimental options are actually changed in practice. From looking at the environment commands in libretro.h, what seems to happen instead is that the constant for the command is removed, the frontends stop supporting it (i.e. they return false) and a new version is introduced. For instance, RETRO_ENVIRONMENT_GET_VARIABLE and SET_VARIABLES used to be keys 4 and 5, but those two keys have since been removed and updated versions were assigned to 15 and 16. I think by "change" they really mean "replace".

A properly written core ought to check whether the frontend supports any environment command (stable or otherwise) so there shouldn't be any trouble when an experimental command is deprecated/replaced. I think we could support them with a feature flag to opt into it like you originally suggested.

[ghost]

Well, that's a nasty bit of API design on their end. I suppose if that's how business is done in this domain, having them behind an unstable feature flag should suffice.