My 2 cents on the "backwards compatibility" discussion. First: backwards compatibility must be broken if the old implementation is wrong. This seems obvious, but I have had discussions about that in the past when I corrected another conversion routine in fpc. Wether or not the current implenetation is wrong, is open for discussion.
Breaking backwards compatibility for consistency with similar RTL behaviour is IMO not a bad thing. We have done so in th epast for Lazarus as well. As said before: given the expected number of users of this function, I weould consider doing it. For consistency we should also have a TryRomanToInt(S: String; out Value: Integer): Boolean; function. As stated before: Delphi compatibility does not seem to be apply here. My 2 cents on the "strictness" of the parsing. Since there are various, more or less accepted, "rules", a "strictness" parameter could be added as an optional parameter to the function. It does not break consistency with other conversion functions, since they are hardly open for interpretation, and so they don't need such a thing. Strictness modes could be: - Strict: most strict set of rules (it does not accept numbers > 3999, nor more than 3 repeats of the same numeral) - Relaxed: allows unlimited number of starting "M", and allows up to 4 repeats of C, X and I. - DontCare: like current behaviour. Bart _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
