In article <uis92u4hg.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
"Erik Wien" <wien@start.no> writes:
"Miro Jurisic" <macdev@meeroh.org> wrote in message news:macdev-
I am not sure I buy this. I think that if you want to have unchecked Unicode data, you should use a vector<char*_t>. Unicode strings have well-defined invariants with respect to canonicalization and well-formedness, and I think that the a Unicode string abstraction should enforce those invariants.
Having intermediate states that are invalid and a final state that is valid is not a feature, it's a bug. It's a silent failure that I want to know about.
Amen. ;)
How is this different from the situation with filesystem::path, where eager checking has turned out to be painful for a broad spectrum of users?
I am not familiar with the problem in boost::fs so I can't comment on that specifically, but I can comment in a more general sense. I think we can safely agree that: 1. There is an invariant that is valuable in some problem domains 2. There may be some problem domains in which it is valuable to sidestep that invariant boost::fs, as far as I understand it, ran into the problem that it was impossible to sidestep the invariant. My position is not that we should prohibit people from manipulating Unicode strings in a manner that does not maintain well-formedness. My position is that we should permit use of Unicode strings that guarantees well-formedness. I haven't taken the time to figure out how to do that (if I had the time, I would not be discussing how Erik could do this, I'd be writing a proposal myself :-) ). I come from a problem domain in which an abstraction which guarantees well-formedness has more value, but I am not looking for an answer that satisfies me and nobody else. meeroh