On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote: > --On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara > >First off, let me say I do think this is a compelling use-case. ... > >I missed the beginning of this thread, but I imagine the motivation > >is to avoid having to say > > std::pair<Iter,Iter> p = out_edges(v,g); > > Iter begin = p.first; > > Iter end = p.second; > >each and every single time you call out_edges(). > > IIUC, you are saying that you don't find the use of tie with pairs > very compelling. Fair enough. Of course tie is more generically useful > with arbitrary tuples and multi-value returns. I was just trying to > present a small familiar example of such usage.
Apologies if I was unclear; I _do_ think it's compelling. The syntactic convenience of being able to bind multiple names in one expression is very nice. (Additionally, if you're doing lots of FP stuff (like me), it's a real pain when you have to introduce those nasty _statements_ into your code, when you'd really like to do things all in one big _expression_. :) ) > In general I'm not a fan of implicit conversions or constructors. > However one of my goals is to be able to easily/readably move code > from using raw variables to use PossiblyUnitinitializedVariables > instead. So.. I agree that it would be nice for PossiblyUnitinitializedVariables to be able to be included in existing code with a minimum of fuss. I think, perhaps, that that goal is incompatible with avoiding implicit conversions, though. > ... here I like the + or something like it > begin.reference_to_uninitialized(). That is I don't mind when users > have to be a little more explicit in the dangerous/uncommon case. ~ is Indeed ("make the easy/common things easy, and make the hard/uncommon things possible"). > also interesting, although I think that readability suffers. I'd give > up bool conversion and operator! to avoid the need for ~ if that would > reasonably solve the muddling issues. But perhaps there would be too > many other problems -- I haven't explored this deeply yet. Right; to clarify, I don't think the boolean conversion operator is "interfering" with the implicit conversion to T. Rather I think each is an instance of "implicit conversion", and implicit conversions just don't work well with templates in general, in my experience. I chose '+' and '~' simply because they were the two unary operators that sprang to mind (that aren't named '*'). Personally I have no problem with '*'; C++ has a small finite set of operators, and so you are bound to have to overload the conceptual meanings of some operators if you want to use them for useful syntax sugar. The way I see it, the optional interface using '*' is fine, and I think perhaps what people object to is the conceptual notion of optional being 'pointer-like'. The way I choose to see it, optional is just a special kind of container, which happens to use '*' to get at the value in the container, and the fact that '*' is also used to dereference pointers is a mere coincidence of names. But perhaps other operators (like '+' and '~') or named operations would be more generally acceptable. That's fine. My main point in joining this discussion was to emphasize that I think there ought to be an explicit operation to 'get' the value of an optional (as well as to get the location of raw storage to construct a new value). What those operations are named matters much less than simply their existence. -- -Brian McNamara ([EMAIL PROTECTED]) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost