Re: [boost] [yap] Review part 1: documentation

Subject: Re: [boost] [yap] Review part 1: documentation
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-02-13 19:10:22

On Tue, Feb 13, 2018 at 1:30 PM, Steven Watanabe via Boost <
boost_at_[hidden]> wrote:

> AMDG
>
> On 02/13/2018 09:44 AM, Zach Laine wrote:
> > On Mon, Feb 12, 2018 at 10:13 PM, Steven Watanabe via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> On 02/12/2018 06:09 PM, Zach Laine wrote:
> >>> On Mon, Feb 12, 2018 at 12:08 PM, Steven Watanabe via Boost <
> >>> boost_at_[hidden]> wrote:
> >>>
>
>
[snip]

>   I think you're forgetting that the terminal transform is
> applied before calling operator()(xxx_tag, ...).
> Thus, the result is actually:
>
> make_expression<expr_kind::call>(checked_add{},
>   transform(transform(1_p, *this), *this),
>   transform(transform(2_p, *this), *this)).
>
>   Since the extra transform tacks on another call expr,
> we end up up coming right back around to operator()(call_tag).
>

I was forgetting that!  Thanks.

>   The bottom line is, any transform which is not idempotent
> for terminals is badly broken if you unwrap terminals
> automatically.
>
>   If you don't apply the terminal transform, but still
> unwrap terminals, then it's *still* broken, because
> then the terminal transform gets skipped entirely.
>
>   Actually, the code I posted fails to compile (even after
> fixing the obvious typos) because the recursion makes
> it impossible for auto to deduce the return type.

Right, and although this saves the user from runtime infinite recursion, it
is a very obscure failure mode.  This more than outweighs the convenience
of the current interface.  I'm convinced the auto-evaluating, and in fact
all terminal unwrapping in tag-transforms, should be removed.

Zach