[boost] Re: Any interest in adding unicode support to boost?

From: Miro Jurisic (macdev_at_[hidden])
Date: 2004-10-22 12:10:27

In article <uis92u4hg.fsf_at_[hidden]>,
 David Abrahams <dave_at_[hidden]> wrote:

> "Erik Wien" <wien_at_[hidden]> writes:
> 
> > "Miro Jurisic" <macdev_at_[hidden]> 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