Re: [boost] [conversion] ADL and templates

Subject: Re: [boost] [conversion] ADL and templates
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-06-01 13:51:38

Vicente Botet wrote:
> Stewart, Robert wrote:
> > Vicente Botet wrote:
> >> Stewart, Robert wrote:
> >> >
> >> > Note that I'm suggesting
> >> > boost::conversion::converter<Target,Source,Enable>
> >> > as the name and I'm suggesting s/apply/operator ()/ to
> >> > make it a function object.  These alterations mean that
> >> > there is now a function object interface for effecting
> >> > conversions from Source to Target which is the sole point
> >> > of customization for all such conversions in the library.
> >>
> >> Yes, this could be a valid possibility. I will need to fix
> >> names for the other function objects associated to assign_to
> >> (assigner?), try_convert_to (try_converter), ... Or
> >> shouldn't the library provide CP for all the operations?
> >
> > There should be one place to effect customization for all of
> > the APIs supported by the library.  The converter interface
> > above would need to throw an exception to indicate a failure,
> > so perhaps instead it should be:
> >
> >    bool
> >    operator ()(Target &, Source const &) const;
> >
> > That would support the try API directly while those that
> > throw an exception would do so if the conversion returns
> > false.  Obviously, that avoids the need for Target to be
> > Copyable, if not using a wrapper function that requires it,
> > but it does mean that Target must be DefaultConstructible or
> > that there be a CP for providing a default value (as we've
> > discussed before).
>
> Each operation can be applied to types with different
> restrictions. It is clear that convert_to can only be used for
> types that are CopyConstructible. The specific implementation
> could have other requirements. In particular the default one
> requires the expression Target(source) to be valid.

OK, but you should minimize the variations, I imagine.

> The preceding interface corresponds to the try_assign_to
> function

Yes.

> and the interface doesn't have any requirements on the target
> type, except if the target should not be modified when the
> conversion fails.

That's not a requirement on Target, which is what I was referring to.

> > Perhaps it would be better if the function object interface
> > and the customization point were split:
> >
> > template
> > <
> >    class Target
> >    , class Source
> >    , class Enable = void
> > >
> > struct converter
> > {
> >    Target
> >    operator ()(Source const & _source) const
> >    {
> >       Target result;
> >       if (custom_converter<Target,Source>::
> >          apply(result, _source))
> >       {
> >          return result;
> >       }
> >       throw exception;
> >    }
> > };
> >
> > template <class Target, class Source>
> > struct custom_converter
> > {
> >    static bool
> >    apply(Target &, Source const &);
> > };
> >
>
> I don't think the default implementation of converter should
> use a function that needs to use a try-catch block to hide the
> possible exception thrown during the conversion.

This version was supposed to throw nothing.  Doing so would mean that the try API could use it directly rather than having to absorb exceptions.

> > A PTS of converter that tests Enable, however you intended
> > that to work, would be provided by the library, too.  Both
> > specializations would defer to
> > custom_converter<Target,Source>::apply() to do the
> > conversion.  That means the CP isn't concerned with the
> > Enable template parameter or with throwing exceptions.
>
> Sorry, I don't understand what do you want to do with Enable.

If Enable is void, then converter<Target,Source,void>::operator () calls custom_converter<Target,Source>::apply().  However, if Enable is not void, then converter<Target,Source,Enable> must determine whether to permit the conversion.  If so, operator () calls custom_converter<Target,Source>::apply().  If not, I suppose it's supposed to be a compilation error to support SFINAE?

> > Obviously, the try API could be written to catch exceptions
> > and return false while the CP could be this instead:
> >
> >    static Target
> >    apply(Source const &);
> >
> > That permits those customizing a particular conversion to
> > throw whatever exceptions they like.
>
> This correspond to the current implementation of
> try_convert_to.

Didn't you say you didn't like that, above?

> > I'm not sure which I prefer.  The flexibility of throwing
> > custom exceptions is nice, but absorbing exceptions in order
> > to return false from the try API seems heavy handed.
>
> I think we can resume that having a single customization point
> for all the operations would not be enough open, and that we
> need CP for all the operations.

Based upon what I know presently, I don't agree.  It would be much nicer for those using the library to have a single place to implement their conversion logic and for the library to use that, appropriately, to implement all of the supported APIs.

There could well be something I've lost track of or never knew that requires multiple CPs, but I'd hate to think that some of the APIs could be customized for some new UDT, while others would be left unimplemented until some user happens to use one of the APIs not customized.

> The question now is what is the default behavior for each one
> of the operations.
>
> On the current implementation all the operations use directly
> or indirectly the convert CP.

If that's so, why do you say that each must have its own CP?

> I will add on the documentation the requirements for each
> one of the implementations. I will use the Enable parameter
> each time the requirements can be expresed using a trait
> meta-function.

That would mean that, for a given UDT, SFINAE would remove various APIs from consideration, possibly leaving none.  A more meaningful error message would be possible using BCCL to assert that the Target satisfies the required concept(s).

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