Writeable LengthHint should be called LengthBound about icu4x HOT 16 OPEN

Alternatively, we could just return an integer with the following invariant, which should cover all of our cases and maybe do it better:

Returns the 95th percentile upper bound of bytes required

This would permit a Writeable to estimate an upper bound while still permitting edge cases to exceed it.

from icu4x.

I think it should stay a hint, and we add that guidance yes.

from icu4x.

I think it should stay a hint, similar to iterator. Giving an incorrect hint will not produce incorrect or undefined behaviour, it's just a bit less efficient.

from icu4x.

I think we should either:

1. Make it a bound with minimum and maximum (as noted in the OP, we already have code that assumes the bounds are correct)
2. Make it a hint and return an integer instead of a min/max

from icu4x.

Which code?

from icu4x.

We have code that assumes it can skip calling write_to if write_len returns an upper bound of 0.

from icu4x.

yes, I am asking to see the code.

I think this discussion is not possible without being able to determine if that code really should be doing that and if that helps.

from icu4x.

Also if it's a zero thing we can still say something of the form that it's approximate but zero means zero

from icu4x.

The code is in the writeable crate itself, but it is demonstrative of the type of assumption that other client code could want to be making

    fn write_to_string(&self) -> Cow<str> {
        let hint = self.writeable_length_hint();
        if hint.is_zero() {
            return Cow::Borrowed("");
        }
        let mut output = String::with_capacity(hint.capacity());
        let _ = self.write_to(&mut output);
        Cow::Owned(output)
    }

from icu4x.

Okay, I think we have two paths:

• We should declare that zero means zero, everything else is approximate, because that gives the most utility to users whilst leaving things flexible for implementors.
• We treat it as a bound and name it as such.

from icu4x.

I feel like my proposal to change the hint to an integer instead of an enum has gotten a bit lost in the shuffle.

from icu4x.

I think that could work, though I think in that case we still would want to be able to signal the difference between "empty" and "hint zero".

from icu4x.

Option<usize> covers that.

from icu4x.

I think it is useful to be able to provide both upper and lower bounds, as this might very well affect the choice of sink that a client uses.

In #370 @sffc proposed an ::Approximate variant as well, but as of now I don't think we have any writeables that would want to return this.

from icu4x.

@robertbastian What are your thoughts on "hint" vs "bound"?

from icu4x.

I think we should follow Iterator::size_hint, the same way we use std's fn len naming instead of fn length

from icu4x.