Re: [boost] [convert] no-throw and fallback feature

Subject: Re: [boost] [convert] no-throw and fallback feature
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-11 15:07:13

Gordon Woodhull wrote:
> On May 11, 2011, at 7:08 AM, Stewart, Robert wrote:
>
> > Also, assignment within a conditional is error prone, so
> > often rejected.  An idiom that relies on it, even though not
> > a normal assignment, will likely also be rejected.
>
> I'm very sorry to hear that.  I hope not!
>
> I guess we should consider what opt_tie(i) ==
> convert_cast<..>(...) would mean.  Obviously it would fail in
> the simple impl I posted.  If it did work, it wouldn't buy you
> anything above constructing an ordinary optional<T>.

Equality should not be supported.

> On May 11, 2011, at 7:46 AM, Stewart, Robert wrote:
> > Gordon Woodhull wrote:
> >> On May 10, 2011, at 3:55 PM, Vicente BOTET wrote:
> >>
> >> I think opt_tie should behave as if it's optional<T>&.  I am
> >> not sure why one would want to chain assignments in this
> >> case but it should be possible.
> >
> > If you can't explain why it is needed, I consider that a
> > reason to reject it.

I don't think chained assignments is useful -- you may find a good use case -- but returning bool, to support your try_convert_to()-avoiding usage, would work.

> > Since tie() doesn't work that way, it would be surprising.
>
> >From the user's point of view, tie() does work the same.  It
> >returns pair<&,&> which is chain-assignable.

Ah, I see what you mean.

> >I would expect an assignment operator to return something
> >convertable to T, whether that is T& (best), T or T const&
> >(okay).

To support chaining, the assignment operator must return something non-const.  Normally, it must be T & in order that the assignment can be to the object first assigned to.  In this case, returning a new object that actually assigns through a reference to the same underlying object is not unreasonable, if unusual.

> > However, it would permit Vicente's use case:
> >
> > int i(fallback);
> > if (!(opt_tie(i) = convert_to<optional<int>>(s))
>
> This is the way I would like to deal with fallbacks when I need
> to know whether it succeeded.  It's succinct and I think very
> clear.  It might take a little bit of investigation to
> understand why it works, but I think it's immediately clear
> what is supposed to happen.

That looks like so much line noise to me, particularly by comparison to try_convert_to().

> I am not as happy with try_convert_to (I don't like out-
> parameters if they can be avoided), but I understand that
> everyone has their own preferences, which might include
> avoiding assignment within a conditional.

Indeed.

> >> template<typename T>
> >> class opt_tie_type {
> >>  T &x_;
> >> public:
> >>  opt_tie_type(T &x) : x_(x) {}
> >>  const optional<T> operator=(optional<T> const& y) {
> >
> > The return type should be optional<T> const & if not void.
>
> Good point on the reference.  Certainly not void, that would
> defeat the purpose.

void would not default "the" purpose.  It would defeat your purpose desire for chaining.  The assignment operator assigns through the reference given to the constructor, so the reason opt_tie() was conceived is satisfied.

As noted above, returning bool still would permit your syntax:

if (!(opt_tie(i) = convert_cast<optional<int>>(s)))

> > I don't think anything more optimal is possible after
> > addressing the return type of the assignment operator.
> > However, a robust implementation will need a PTS for
> > reference types to address the reference-to-reference
> > problem (or use remove_reference).
>
> Good point.  Thanks.  But wait a sec, given that opt_tie_type
> is a detail of opt_tie(), how is it possible that T is a
> reference type?

You snipped your opt_tie() implementation, but this should be the same:

template <class T>
opt_tie_type<T>
opt_tie(T & _value)
{
   return opt_tie_type<T>(_value);
}

T will be deduced as a non-reference type, so you're right, the PTS is not needed.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.