Fernando Cacciola wrote: >> I think that a lot of this discussion is boiling down to whether or >> not optional should sport a pointer interface at all. > >I think that the discussion is boiling down to whether or not optional >should support relational operators, and then how should these be >defined. We haven't really discussed whether to drop or keep the >pointer interface.
To me, it is the same issue--deciding one implies a decision on the other. >> To me, the only really important benefit of pointer syntax is for >> usage in generic code. >> >This is one of the reasons, but the other really important >reason is that it looks familiar. >When you see: > >if ( opt ) > foo(*opt) > >you know what it is about. This is convenience. It is why I like the pointer interface. It is not, however, important IMO. >> While it is a convenient shorthand in regular >> code, it is no more laborious, really, to type out some function >> calls instead of operator* and operator&. >> >But those function calls will not be familiar. >The pointer interface brings a familiar idiom to deal with optional >values. Therein lies the danger. I want us to define a new concept to disambiguate "looks like a pointer." Otherwise, I don't *want* it to be familiar, because that same familiarity will lead to assumptions will lead to errors. If the function calls are named in a reasonable manner (/me ducks), then somebody reading code using it will understand just fine. For somebody who is going to write code using optional, I think there is no difference in learning curve. I really think this is a red herring. >> So, if we set generic code >> aside for a moment, I think that it is clear that a pointer interface >> is dangerously misleading and should definitely be stricken. >> >It is only dangerosuly misleading if it is abused. >I seems that we all agree that operator*(), operator-> and operator >safe_bool() >are pretty safe. >The controversial part are relational operators. I don't think we're arguing anything here :) If relational operators are present, they cannot behave like pointer relational operators. Ergo, if you include both, you have a mismatched interface. If they are not included, then a programmer cannot accidently misuse them by assuming they work like pointers'. I argue against a mismatched interface, so I put it this way: Is the convenience of operator== more important than the convenience of operator*, etc? What I'm saying is that the consideration of generic code changes my answer to that question. Some people may argue for both. So long as it is possible to safely write generic code, then I will not worry so much about our hypothetical assumption-and-error-making programmer. >I wouldn't go so far as to make sure optional<> isn't used in place of >a generic pointer because optional is intended to serve a specific >purpose, that of conveing optionality, and not all pointers are used >for that, so it shouldn't be expected that an optional is used >for something for which it is not designed. >Anyway, I agree with you on the usefulness of new concepts. Ok, the possibilities here may be nonobvious, so let me enumerate them: A) We drop pointer interface, and optional behaves like a container. This is all a non issue. B) We define new concepts, and optional does NOT have operator==. This is a non issue, because code that depends on this behavior of pointers will not compile when given optional. C) We define new concepts, and also define operator== for the convenience of code that works with optionals explicitly. However, now code that assumes different semantics for operator== will compile. I think this should be prevented. Again, consider generic code. Sure, you won't directly try and pass an optional to a function that can't use one, but by the time you get through 20 layers of template indirection, it could be difficult to sort out what's going on even *with* a compiler error. If this is a silent run time inconsistency, it could take a very long time to track down what's going on, assuming it ever comes up during testing. This, then, is my argument against having operator== at all. The convenience of optional having operator== is not worth making the rest of your code safe against its misuse. If people understand this point and still feel OK ignoring it, then that's fine. >Why operator& instead of operator-> ? >AFAICT, both * and & are never present on the same concept. >Anyway, with -> instead of &, I agree with this definition of the >OptionalValue concept. Sorry, yes, that's what I meant. I have enough trouble checking my spelling ;) Cheers- Augustus __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
