Make FixedDecimal's round to increment methods experimental

[jedel1043]

No description provided.

[Manishearth]

nit: let's not do this, write a private trunc_to_increment_inner function and then call them from both

[jedel1043]

Would doing something like this also work for you?

pub fn expand(&mut self, position: i16) {
    #[cfg(feature = "experimental")]
    {
        self.expand_to_increment(position, RoundingIncrement::MultiplesOf1)
    }

    #[cfg(not(feature = "experimental"))]
    {
        // Original impl
    }
}

[Manishearth]

Basically I don't want us to duplicate the impl

[jedel1043]

I'll assume that's a yes

[Manishearth]

No, that still duplicates the impl, no?

[jedel1043]

But the reason we're making the methods experimental is to benchmark them, so we need to preserve the original implementation somehow, right?

[Manishearth]

oh, are these impls distinct?

In that case: we should have internal methods for all of the implementations and use cfgs on thin wrappers

basically we should not do a big cfg/cfg-not pairing for this kind of thing, it's really hard to read. The actual meat of the impl should be in its own method

[jedel1043]

That's fair! In that case I'll extract the implementation into an internal method and call that from the public method.

[sffc]

Normally I don't like landing code with #[cfg(not(...))] because it is not tested in CI but it's okay in this case since it's between experimental and non-experimental, and we have a path to removing it soon.

[Manishearth]

ideally we'd have RoundingIncrement be internally available (reexported as public in experimental mode) so that we don't need a separate internal function, but this is fine for now