This question is related to [this previous one](https://stackoverflow.com/q/21724760/819272) where it was noticed that init-capturing `mutable` lambdas are incompatible with Boost's range and iterator `transform` for some rather obscure and deeply nested `typedef` failures that may or may not be easy to resolve through hacking the Boost.Range sources. 

The accepted answer suggested storing the lambda in a `std::function` object. To avoid potential `virtual` function call overhead, I wrote two function objects that could serve as potential work-arounds. They are called `MutableLambda1` and `MutableLambda2` in the code below

```
#include <iostream>
#include <iterator>
#include <vector>
#include <boost/range/adaptors.hpp>
#include <boost/range/algorithm.hpp>

// this version is conforming to the Standard
// but is not compatible with boost::transformed
struct MutableLambda1
{
    int delta;     
    template<class T> auto operator()(T elem) { return elem * delta++; }
};

// Instead, this version works with boost::transformed
// but is not conforming to the Standard
struct MutableLambda2
{
    mutable int delta;
    template<class T> auto operator()(T elem) const { return elem * delta++; }
};

// simple example of an algorithm that takes a range and laziy transformes that
// using a function object that stores and modifies internal state
template<class R, class F>
auto scale(R r, F f) 
{
    return r | boost::adaptors::transformed(f);
}

int main()
{
    // real capturing mutable lambda, will not work with boost::transformed
    auto lam = [delta = 1](auto elem) mutable { return elem * delta++; };        
    auto rng = std::vector<int>{ 1, 2, 3, 4 };

    //boost::copy(scale(rng, lam), std::ostream_iterator<int>(std::cout, ","));                 /* ERROR */
    //boost::copy(scale(rng, MutableLambda1{1}), std::ostream_iterator<int>(std::cout, ","));   /* ERROR */
    boost::copy(scale(rng, MutableLambda2{1}), std::ostream_iterator<int>(std::cout, ","));     /* OK!   */
}

```

[**Live Example**](http://coliru.stacked-crooked.com/a/a56fcb849a9b1e90) that won't compile the lines with `lam` and `MutableLambda1`, and correctly prints `1, 4, 9, 16` for the line with `MutableLambda2`.

However, the [**draft Standard**](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf) mentions

**5.1.2 Lambda expressions [expr.prim.lambda]**

> 
> 5 [...] This function call operator or operator template is declared const
>  (9.3.1) if and only if the lambda-expression’s
>  parameter-declaration-clause is not followed by `mutable`. [...]
> 
> 
> 11 For every init-capture a non-static data member named by the
>  identiﬁer of the init-capture is declared in the closure type. This
>  member is not a bit-ﬁeld and not `mutable`. [...]
> 
> 
> 

This means that `MutableLambda2` is not a conforming handwritten replacement for an init-capturing `mutable` lambda expression.

Questions
---------

* why is the implementation of init-capturing `mutable` lambdas the way it is (i.e. non-const function call operator)?
* why is the seemingly equivalent alternative of `mutable` data members with a `const` function call operator forbidden?
* (**bonus**) why does the Boost range and iterator `transform` rely on the fact that a function objects `operator()` is `const`?