Boost logo

Boost :

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-12 19:12:30

Fernando Cacciola wrote:
>> I think that a lot of this discussion is boiling down to whether
>> not optional should sport a pointer interface at all.
>I think that the discussion is boiling down to whether or not
>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

>> 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

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
>> 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
>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
>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

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 ;)


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Boost list run by bdawes at, gregod at, cpdaniel at, john at