Proposal: Make sure C++ getters are const and C getters take a const object pointer

Affects: ICU4C 3.0

Background:  The following C++ methods on DecimalFormat are all marked 
@stable ICU 2.0.  These methods are all getters, that is, they retrieve 
data from an object without changing the object.

getRoundingMode
getRoundingIncrement
getFormatWidth
getPadPosition
getPadCharacterString
getMinimumExponentDigits

Problem:  These are non-const methods.  As such, they cannot be called on 
const objects.  Example:
    const DecimalFormat& fmt;
    int32_t width = fmt.getFormatWidth(); // compiler error!
The methods should be const.

Proposal:  I would like to change the signature of these methods by 
marking them const.

For example, this API:
    /**
     * Get the width to which the output of format() is padded.
     * @stable ICU 2.0
     */
    virtual int32_t getFormatWidth(void);

would change to:
    /**
     * Get the width to which the output of format() is padded.
     * @stable ICU 2.0
     */
    virtual int32_t getFormatWidth(void) const;

I realize this violates the *letter* of the ICU API migration policy--but 
not the spirit, in my opinion.  I think this is desirable because:
- The change will not break any client code.  Going from const to 
non-const is a breaking change, but non-const to const is okay.  A 
recompile is required, but nothing else.
- The change will fix the API by making it possible to call getters on 
const objects (as was intended).

I think this is strongly preferable to adding a parallel set of const 
methods that do the same thing, and deprecating the existing methods.  I 
don't see any benefit to doing that.

I would like to retain the label of @stable ICU 2.0.  We could mark these 
@draft ICU 3.0 but I don't think it's necessary.

If people agree to this, I'd like to further propose that if we find other 
C++ getters that are accidentally declared non-const, we fix them in the 
same non-breaking way.

The same issue applies to C API; getter functions should take a const 
pointer as their initial parameter, e.g., unum_getAttribute(const 
UNumberFormat* fmt, ...), *not* unum_getAttribute(UNumberFormat* fmt, 
...).  These can be fixed in a similar non-breaking way if any are found.

>> In other words, please consider this to be a general proposal, not 
necessarily limited to DecimalFormat. <<

Please reply with feedback to this list by March 31, 2004.

[Alan S Liu/San Jose/IBM@IBMUS; [email protected];; IBM Globalization; 
5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155]