I have a fairly complex maths library I&#39;m working on, and I have discovered a nasty bug when client code uses auto. Halfway through creating a minimal reproductive case to ask a question about it, I realise I can reproduce something similar using the standard library alone. See this simple test case:

````
#include &lt;vector&gt;
#include &lt;assert.h&gt;

int main()
{
    std::vector&lt;bool&gt; allTheData = {true, false, true};

    auto boolValue = allTheData[1]; // This should be false - we just declared it.
    assert(boolValue == false);
    boolValue = !boolValue;
    assert(boolValue == true);

    assert(allTheData[1] == false); // Huh? But we never changed the source data! Only our local copy.
}
````     
[Live on Godbolt](https://godbolt.org/z/hsKTrTxKd). (Fun fact: Clang actually optimises this to writing &quot;7&quot; - 3 true bits - and a call to __assert_fail.)

(*Yes I know std::vector\&lt;bool\&gt; sucks* - but in this case it&#39;s handy to create a minimum reproducible example that&#39;s only a few lines long) Here&#39;s a [longer example that doesn&#39;t use std::vector\&lt;bool\&gt;](https://godbolt.org/z/YzP57vnbf), and uses a custom container type, with assignment and copy/move deleted, and still shows the problem. 



I understand what is going on under the hood, there&#39;s a proxy class returned by operator[] meant to implement ```allTheData[1] = true``` and related functionality, the client code that is written as if it&#39;s reading the value is actually storing the proxy in boolValue, and then when the client later modifies what it thinks is a bool, the original source data is modified instead. **TLDR: &#39;auto&#39; copied the proxy.**

The code did what the programmer told it to do, not what the programmer meant.

If the programmer wanted boolValue&#39;s changes to update the source data, they would&#39;ve done ```auto&amp; boolValue = ...```, which works with ```operator[]``` implementations returning ```T&amp;```, but not those needing custom proxies which fake reference-like behavior.

All the copy and move constructors and both assignment operators for the proxy are declared private (have also tried ```= delete```), but this bug isn&#39;t caught at compile time. The proxy is copied regardless of whether the copy constructor is deleted.

All the &quot;fixes&quot; I&#39;ve found for this bug focus on the client part of the code. They&#39;re things like: &quot;don&#39;t use auto&quot;, &quot;cast to the underlying type&quot;, &quot;access through a const ref&quot;, etc. These are all substandard fixes, once you discover the bad behavior you can add one of these as a hack fix, but the underlying problem remains to catch the next unsuspecting user. 

I&#39;d rather remove the landmine than keep bypassing it, and putting up a sign saying &quot;don&#39;t use auto&quot;, or &quot;always use const&quot;, just marks the minefield, it doesn&#39;t remove it.

### How can I make my library immune to this gotcha? (Without changing the client code!)
- First preference would be the code works as written - ```assert(allTheData[1] == false)``` passes
    - A way to define the decay type of the proxy when it&#39;s written to auto?. So ```decltype(boolValue)``` is ```bool```? 
    - An implicit conversion operator that takes precedence over copying?
    - Any other way to make this pass without changing the code snippet above?
- Second preference is there a way to make writing a proxy to a variable a compile error?
    - I&#39;m declaring copy and move constructors as delete, and move and copy assignment operators as delete. Still compiles. 
    - Is there anyway to declare a class as unable to become a lvalue?
- Is there anything in proposed c++ future standards that will fix this?

---

Also an issue is code like:
```
std::vector&lt;bool&gt; ReadFlags();
... later ...
auto databaseIsLockedFlag = ReadFlags()[FLAG_DB_LOCKED];
if (databaseIsLockedFlag) &lt;-- Crash here. Proxy has outlived temporary vector.
```

I&#39;m only using vector&lt;bool&gt; here as it&#39;s a really simple example of the problem. This isn&#39;t a bug with vector&lt;bool&gt;, this is a bug with the proxy type pattern, of which vector&lt;bool&gt; is an example to show the problem.

Strangely enough MSVC&#39;s Intellisense engine **sometimes** reports copying a no-move-no-copy proxy type as a compile error, but **then compiles it fine anyway**:

[![enter image description here][1]][1]    
*It&#39;d be really nice if this intellisense compile error was a real compile error. Sigh*

  [1]: https://i.stack.imgur.com/0OzTi.png

All Copy Assignment Solutions on Gang of Coders

Total of 1 Copy Assignment Solutions

How can I make my class immune to the "auto value = copy of proxy" landmine in C++?