------=_Part_550_922311843.1552611568814
Content-Type: multipart/alternative;
 boundary="----=_Part_551_1693591434.1552611568815"

------=_Part_551_1693591434.1552611568815
Content-Type: text/plain; charset="UTF-8"

There are a lot of programming languages that support this feature (D, C#,
Python, etc.). It is also likely that it will be adopted in Rust language
(I mention it because it is the most related to C++ language in my
opinion), see https://github.com/rust-lang/rfcs/issues/997.

This operator does not break backward compatibility: operator[]= will only
be called if it is defined. The open question: should we call `operator[]`
as fallback if no appropriate `operator[]=` can be found but some
`operator[]=` is provided.

Usage example:
#include <map>
#include <utility>

template <typename Key, typename Value>
class another_map : public std::map<Key, Value> {
public:
  using std::map<Key, Value>::map;

  template <typename T>
  // argument order is an open question
  // I think value should be the first because of the proposed
multi-indexed `operator[]`
  // but the evaluation order should be also considered
  Value& operator[]=(T&& value, const Key& key) {
    auto result = insert_or_assign(key, std::forward<T>(value));
    return *result.first;
  }
};

int main() {
  std::map<int, int> m{};
  m[5] = 7; // m.operator[](5) = 7

  another_map<int, int> am{};
  am[5] = 7; // am.operator[]=(7, 5)
  am[5] += 7; // am.operator[](5) += 7
  int x = am[5]; // int x = am.operator[](5)
  // some open-question case
  (am[5]) = 7; // what should we do here?
}

Also it will be good if non-const `operator[]` will be removed from the
proposed `std::flat_map` container adaptor, so we could define
`operator[]=` for it in the future without breaking backward compatibility.
But yeah, of course there will be inconsistency between `std::map` (and
`std::unordered_map`) and `std::flat_map` behavior. I hope we can at least
remove non-const `operator[]` for `std::flat_map` without defining
`operator[]=`, so it would be more safe to use `std::flat_map`.

Possible flaws:

   - Complexity for rarely used feature? (not so rare as chained
   comparisons, but?)
   - Inconsistency with the current `operator[]` design in associative
   containers?
   - `std::map`/`std::unordered_map` `operator[]` can not be fixed for
   compatibility reasons, so it would be still headache for C++ beginners and
   now inconsistency headache because of different behavior between old and
   new associative containers?
   - First odd composite operator?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/39460c2e-f24c-4819-8678-267387948e69%40isocpp.org.

------=_Part_551_1693591434.1552611568815
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>There are a lot of programming languages that support=
 this feature (D, C#, Python, etc.). It is also likely that it will be adop=
ted in Rust language (I mention it because it is the most related to C++ la=
nguage in my opinion), see https://github.com/rust-lang/rfcs/issues/997.</d=
iv><div><br></div><div>This operator does not break backward compatibility:=
 operator[]=3D will only be called if it is defined. The open question: sho=
uld we call `operator[]` as fallback if no appropriate `operator[]=3D` can =
be found but some `operator[]=3D` is provided.<br></div><div><br></div><div=
>Usage example:</div><div><div style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;map&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;utili=
ty&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Key</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> another_map </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">map</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Key</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Value</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">map=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Key</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Value</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">map</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typ=
ename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// argument order =
is an open question</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// I think value should be the first because of the proposed mult=
i-indexed `operator[]`</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// but the evaluation order should be also considered</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Value</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">[]=3D(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> value</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Key</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> key</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> result </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> insert_or_assign</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">key</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">forward</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">value</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">));</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">result</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fi=
rst</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">map</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> m</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 m</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">7</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// m.operator[](5) =3D 7</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br>=C2=A0 another_map</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> am</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 am</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">7</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// am.operator[]=3D(7,=
 5)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 am</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">7</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// am.o=
perator[](5) +=3D 7</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> am</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// int x =3D am.operator[](5)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// some open-question case</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">am</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">])</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">7</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// what should we do here?</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></d=
iv></div><div><br></div><div>Also it will be good if non-const `operator[]`=
 will be removed from the proposed `std::flat_map` container adaptor, so we=
 could define `operator[]=3D` for it in the future without breaking backwar=
d compatibility. But yeah, of course there will be inconsistency between `s=
td::map` (and `std::unordered_map`) and `std::flat_map` behavior. I hope we=
 can at least remove non-const `operator[]` for `std::flat_map` without def=
ining `operator[]=3D`, so it would be more safe to use `std::flat_map`.</di=
v><div><br></div><div>Possible flaws:</div><ul><li>Complexity for rarely us=
ed feature? (not so rare as chained comparisons, but?)</li><li>Inconsistenc=
y with the current `operator[]` design in associative containers?</li><li>`=
std::map`/`std::unordered_map` `operator[]` can not be fixed for compatibil=
ity reasons, so it would be still headache for C++ beginners and now incons=
istency headache because of different behavior between old and new associat=
ive containers?<br></li><li>First odd composite operator?</li></ul></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/39460c2e-f24c-4819-8678-267387948e69%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/39460c2e-f24c-4819-8678-267387948e69=
%40isocpp.org</a>.<br />

------=_Part_551_1693591434.1552611568815--

------=_Part_550_922311843.1552611568814--

.

------=_Part_493_1823122675.1552663999952
Content-Type: multipart/alternative;
 boundary="----=_Part_494_184544910.1552663999952"

------=_Part_494_184544910.1552663999952
Content-Type: text/plain; charset="UTF-8"


>
> I think value should be the first because of the proposed multi-indexed
> `operator[]` but the evaluation order should be also considered
>

Evaluation order for overloaded operators when defined works on the basis
of the appearance of the expressions in code, not on the order of the
parameters to the eventual function call. Assignment operators are ordered
right-to-left, even though you could consider the first parameter of the
member function to be `this` (ie: the left side).

An `operator[]=` is an assignment operator; as such, it should order things
like other assignment operators: right-to-left.

Here's something else that should be considered. This feature exists to
optimize a particular use case of something that is actually more general
in C++: access/assignment paring. That is, the user is conceptually
accessing an object, but they're doing it for the purpose of performing
assignment to the accessed object.

The reason I suggest you consider this is that OutputIterators are
fundamentally based on this. One of the most annoying aspects of writing a
pure OutputIterator is that you have to kind of fudge the way its
`operator*` works. If you cannot manifest an actual `value_type` to assign
to, then you have to return a proxy object that references the meat of the
iterator, which then uses its assignment operator to do the actual
assignment.

Avoiding that kind of thing would help make writing OutputIterators
something that normal C++ programmers can idiomatically understand and
implement.

Your proposal would probably be stronger if it could solve this problem
too, to allow `*it = foo;` and `*it++ = foo;` to magically transform into a
single function call of the form `operator<whatever>(foo)`. And that's not
going to be easy.

Especially since the obvious `operator*=` is already taken ;)

`std::map`/`std::unordered_map` `operator[]` can not be fixed for
> compatibility reasons


I see no reason why this would *have* to be the case. As long as
`some_map[key] = value` has the same behavior, it will be fine. After all,
you still need the regular `operator[]` overload to make values accessible.

Can you come up with a scenario where calling the `operator[]=` overload
will have genuinely breaking behavior? Yes, it will call the copy/move
constructor rather than a default constructor & copy/move assignment. But
the rules of `map` already requires that these must be equivalent
operations, right?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6a65b6a7-5fc2-415f-be8e-fbeaae76e20f%40isocpp.org.

------=_Part_494_184544910.1552663999952
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;">I think value should be the first because of the proposed multi-indexe=
d `operator[]` but the evaluation order should be also considered<br></bloc=
kquote><div><br></div><div>Evaluation order for overloaded operators when d=
efined works on the basis of the appearance of the expressions in code, not=
 on the order of the parameters to the eventual function call. Assignment o=
perators are ordered right-to-left, even though you could consider the firs=
t parameter of the member function to be `this` (ie: the left side).</div><=
div><br></div><div>An `operator[]=3D` is an assignment operator; as such, i=
t should order things like other assignment operators: right-to-left.</div>=
<div><br></div><div>Here&#39;s something else that should be considered. Th=
is feature exists to optimize a particular use case of something that is ac=
tually more general in C++: access/assignment paring. That is, the user is =
conceptually accessing an object, but they&#39;re doing it for the purpose =
of performing assignment to the accessed object.</div><div><br></div><div>T=
he reason I suggest you consider this is that OutputIterators are fundament=
ally based on this. One of the most annoying aspects of writing a pure Outp=
utIterator is that you have to kind of fudge the way its `operator*` works.=
 If you cannot manifest an actual `value_type` to assign to, then you have =
to return a proxy object that references the meat of the iterator, which th=
en uses its assignment operator to do the actual assignment.<br></div><div>=
<br></div><div>Avoiding that kind of thing would help make writing OutputIt=
erators something that normal C++ programmers can idiomatically understand =
and implement.</div><div><br></div><div>Your proposal would probably be str=
onger if it could solve this problem too, to allow `*it =3D foo;` and `*it+=
+ =3D foo;` to magically transform into a single function call of the form =
`operator&lt;whatever&gt;(foo)`. And that&#39;s not going to be easy.</div>=
<div><br></div><div>Especially since the obvious `operator*=3D` is already =
taken ;)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
left: 1ex;">`std::map`/`std::unordered_map` `operator[]` can not be fixed f=
or compatibility reasons</blockquote><div><br></div><div>I see no reason wh=
y this would <i>have</i> to be the case. As long as `some_map[key] =3D valu=
e` has the same behavior, it will be fine. After all, you still need the re=
gular `operator[]` overload to make values accessible.</div><div><br></div>=
<div>Can you come up with a scenario where calling the `operator[]=3D` over=
load will have genuinely breaking behavior? Yes, it will call the copy/move=
 constructor rather than a default constructor &amp; copy/move assignment. =
But the rules of `map` already requires that these must be equivalent opera=
tions, right?<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6a65b6a7-5fc2-415f-be8e-fbeaae76e20f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a65b6a7-5fc2-415f-be8e-fbeaae76e20f=
%40isocpp.org</a>.<br />

------=_Part_494_184544910.1552663999952--

------=_Part_493_1823122675.1552663999952--

.

------=_Part_906_451464444.1552693326017
Content-Type: multipart/alternative;
 boundary="----=_Part_907_23573654.1552693326017"

------=_Part_907_23573654.1552693326017
Content-Type: text/plain; charset="UTF-8"


>
> Evaluation order for overloaded operators when defined works on the basis
> of the appearance of the expressions in code, not on the order of the
> parameters to the eventual function call. Assignment operators are ordered
> right-to-left, even though you could consider the first parameter of the
> member function to be `this` (ie: the left side).
>
> An `operator[]=` is an assignment operator; as such, it should order
> things like other assignment operators: right-to-left.
>

Thanks for clarifying that.

Here's something else that should be considered. This feature exists to
> optimize a particular use case of something that is actually more general
> in C++: access/assignment paring. That is, the user is conceptually
> accessing an object, but they're doing it for the purpose of performing
> assignment to the accessed object.
>
> The reason I suggest you consider this is that OutputIterators are
> fundamentally based on this. One of the most annoying aspects of writing a
> pure OutputIterator is that you have to kind of fudge the way its
> `operator*` works. If you cannot manifest an actual `value_type` to assign
> to, then you have to return a proxy object that references the meat of the
> iterator, which then uses its assignment operator to do the actual
> assignment.
>
> Avoiding that kind of thing would help make writing OutputIterators
> something that normal C++ programmers can idiomatically understand and
> implement.
>
> Your proposal would probably be stronger if it could solve this problem
> too, to allow `*it = foo;` and `*it++ = foo;` to magically transform into a
> single function call of the form `operator<whatever>(foo)`. And that's not
> going to be easy.
>
> Especially since the obvious `operator*=` is already taken ;)
>

Thanks for the nice suggestion! The only good idea about operator syntax
that come to my mind is `operator*operator=` and more generally
`operator$operator@` where $ can be * or [] and @ is one of =, +=, -=, *=,
/=, %=, &=, |=, ^=, <<=, >>=, ++, --. `operator[]operator|=` and similar
would fit good for `std::vector<bool>`/`std::bitset`-like containers and
for their iterators.

`std::map`/`std::unordered_map` `operator[]` can not be fixed for
>> compatibility reasons
>
>
> I see no reason why this would *have* to be the case. As long as
> `some_map[key] = value` has the same behavior, it will be fine. After all,
> you still need the regular `operator[]` overload to make values accessible.
>
> Can you come up with a scenario where calling the `operator[]=` overload
> will have genuinely breaking behavior? Yes, it will call the copy/move
> constructor rather than a default constructor & copy/move assignment. But
> the rules of `map` already requires that these must be equivalent
> operations, right?
>

I was talking primarily about current `operator[]` behavior for
non-existing entries (creating entries with default-constructed values
instead of throwing exceptions). But you are right, adding `operator[]=`
(or `operator[]operator=`) overload for `std::map` should not break the
current behavior.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb376b4b-11ba-4bb3-af7a-378556166ea6%40isocpp.org.

------=_Part_907_23573654.1552693326017
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div>Evaluation order for overloaded operators when defined works =
on the basis of the appearance of the expressions in code, not on the order=
 of the parameters to the eventual function call. Assignment operators are =
ordered right-to-left, even though you could consider the first parameter o=
f the member function to be `this` (ie: the left side).</div><div><br></div=
><div>An `operator[]=3D` is an assignment operator; as such, it should orde=
r things like other assignment operators: right-to-left.</div></div></div><=
/blockquote><div><br></div><div>Thanks for clarifying that.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v>Here&#39;s something else that should be considered. This feature exists =
to optimize a particular use case of something that is actually more genera=
l in C++: access/assignment paring. That is, the user is conceptually acces=
sing an object, but they&#39;re doing it for the purpose of performing assi=
gnment to the accessed object.</div><div><br></div><div>The reason I sugges=
t you consider this is that OutputIterators are fundamentally based on this=
.. One of the most annoying aspects of writing a pure OutputIterator is that=
 you have to kind of fudge the way its `operator*` works. If you cannot man=
ifest an actual `value_type` to assign to, then you have to return a proxy =
object that references the meat of the iterator, which then uses its assign=
ment operator to do the actual assignment.<br></div><div><br></div><div>Avo=
iding that kind of thing would help make writing OutputIterators something =
that normal C++ programmers can idiomatically understand and implement.</di=
v><div><br></div><div>Your proposal would probably be stronger if it could =
solve this problem too, to allow `*it =3D foo;` and `*it++ =3D foo;` to mag=
ically transform into a single function call of the form `operator&lt;whate=
ver&gt;(foo)`. And that&#39;s not going to be easy.</div><div><br></div><di=
v>Especially since the obvious `operator*=3D` is already taken ;)</div></di=
v></div></blockquote><div><br></div><div>Thanks for the nice suggestion! Th=
e only good idea about operator syntax that come to my mind is `operator*op=
erator=3D` and more generally `operator$operator@` where $ can be * or [] a=
nd @ is one of =3D, +=3D, -=3D, *=3D, /=3D, %=3D, &amp;=3D, |=3D, ^=3D, &lt=
;&lt;=3D, &gt;&gt;=3D, ++, --. `operator[]operator|=3D` and similar would f=
it good for `std::vector&lt;bool&gt;`/`std::bitset`-like containers and for=
 their iterators.</div><div></div><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">`std::map`/`std::unordered_<wbr>map` `operator[]` can not be fixed for=
 compatibility reasons</blockquote><div><br></div><div>I see no reason why =
this would <i>have</i> to be the case. As long as `some_map[key] =3D value`=
 has the same behavior, it will be fine. After all, you still need the regu=
lar `operator[]` overload to make values accessible.</div><div><br></div><d=
iv>Can you come up with a scenario where calling the `operator[]=3D` overlo=
ad will have genuinely breaking behavior? Yes, it will call the copy/move c=
onstructor rather than a default constructor &amp; copy/move assignment. Bu=
t the rules of `map` already requires that these must be equivalent operati=
ons, right?<br></div></div></div></blockquote><div><br></div><div>I was tal=
king primarily about current `operator[]` behavior for non-existing entries=
 (creating entries with default-constructed values instead of throwing exce=
ptions). But you are right, adding `operator[]=3D` (or `operator[]operator=
=3D`) overload for `std::map` should not break the current behavior.<br></d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb376b4b-11ba-4bb3-af7a-378556166ea6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb376b4b-11ba-4bb3-af7a-378556166ea6=
%40isocpp.org</a>.<br />

------=_Part_907_23573654.1552693326017--

------=_Part_906_451464444.1552693326017--

.

------=_Part_1156_517165323.1552722530220
Content-Type: multipart/alternative;
 boundary="----=_Part_1157_542400978.1552722530221"

------=_Part_1157_542400978.1552722530221
Content-Type: text/plain; charset="UTF-8"


>
> and `*it++ = foo;`
>

I totally missed it. It is really hard to find a general solution with this
three-operator case...

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6d4f1689-a221-4c38-9101-6776d1fad328%40isocpp.org.

------=_Part_1157_542400978.1552722530221
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div>and `*it++ =3D foo;`</div></div></div></blockquote><div><br><=
/div><div>I totally missed it. It is really hard to find a general solution=
 with this three-operator case... <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6d4f1689-a221-4c38-9101-6776d1fad328%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6d4f1689-a221-4c38-9101-6776d1fad328=
%40isocpp.org</a>.<br />

------=_Part_1157_542400978.1552722530221--

------=_Part_1156_517165323.1552722530220--

.

------=_Part_1131_193757183.1552743452893
Content-Type: multipart/alternative;
 boundary="----=_Part_1132_2048056395.1552743452893"

------=_Part_1132_2048056395.1552743452893
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 16, 2019 at 3:48:50 AM UTC-4, wpmgpro...@gmail.com wrote:
>
> and `*it++ = foo;`
>>
>
> I totally missed it. It is really hard to find a general solution with
> this three-operator case...
>

It's still a 2 operator case. The ++ is evaluated before the `*` and the
`=`. It's no different from `*some_func() = foo;`, or `some_func()[10] =
foo;`. It's all about recognizing the sequence of evaluating a left-hand
`*` or `[]` followed by an `=` evaluation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b351559b-5a53-4ade-a8ff-14a80c60fc27%40isocpp.org.

------=_Part_1132_2048056395.1552743452893
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 16, 2019 at 3:48:50 AM UTC-4, wpmgpro..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>and=
 `*it++ =3D foo;`</div></div></div></blockquote><div><br></div><div>I total=
ly missed it. It is really hard to find a general solution with this three-=
operator case... <br></div></div></blockquote><div><br></div><div>It&#39;s =
still a 2 operator case. The ++ is evaluated before the `*` and the `=3D`. =
It&#39;s no different from `*some_func() =3D foo;`, or `some_func()[10] =3D=
 foo;`. It&#39;s all about recognizing the sequence of evaluating a left-ha=
nd `*` or `[]` followed by an `=3D` evaluation.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b351559b-5a53-4ade-a8ff-14a80c60fc27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b351559b-5a53-4ade-a8ff-14a80c60fc27=
%40isocpp.org</a>.<br />

------=_Part_1132_2048056395.1552743452893--

------=_Part_1131_193757183.1552743452893--

.

------=_Part_64_1766639733.1552751528982
Content-Type: multipart/alternative;
 boundary="----=_Part_65_1656000288.1552751528982"

------=_Part_65_1656000288.1552751528982
Content-Type: text/plain; charset="UTF-8"

This looks like a use-case for operator dot ( or delegate base) proposal.

operator dot:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf

delegate base:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0352r0.pdf

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1d04ad84-e474-413e-b4ab-93e947e7c0ce%40isocpp.org.

------=_Part_65_1656000288.1552751528982
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This looks like a use-case for operator dot ( or dele=
gate base) proposal.</div><div><br></div><div>operator dot: <a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf" rel=3D"noref=
errer noopener"><div class=3D"TbwUpd"><cite class=3D"iUh30">www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf</cite></div></a><span><br></spa=
n></div><div>delegate base: <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2016/p0352r0.pdf" rel=3D"noreferrer noopener"><div class=3D"=
TbwUpd"><cite class=3D"iUh30">www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
016/p0352r0.pdf</cite></div></a><span></span><br><span></span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1d04ad84-e474-413e-b4ab-93e947e7c0ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d04ad84-e474-413e-b4ab-93e947e7c0ce=
%40isocpp.org</a>.<br />

------=_Part_65_1656000288.1552751528982--

------=_Part_64_1766639733.1552751528982--

.

------=_Part_1136_593923870.1552752130382
Content-Type: multipart/alternative;
 boundary="----=_Part_1137_1589693292.1552752130382"

------=_Part_1137_1589693292.1552752130382
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 16, 2019 at 11:52:09 AM UTC-4, floria...@gmail.com wrote:
>
> This looks like a use-case for operator dot ( or delegate base) proposal.
>

I fail to see how those proposals matter relative to this one. Operator-Dot
proposals just make it easier to write proxies. The point of this idea is
to not have proxies to begin with, to combine two operations into a single
function call.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/778971a4-8253-4885-aeaa-0fd403257bb9%40isocpp.org.

------=_Part_1137_1589693292.1552752130382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 16, 2019 at 11:52:09 AM UTC-4, floria..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>This looks like a use-case for operator dot ( or delegate base) p=
roposal.</div></div></blockquote><div><br></div><div>I fail to see how thos=
e proposals matter relative to this one. Operator-Dot proposals just make i=
t easier to write proxies. The point of this idea is to not have proxies to=
 begin with, to combine two operations into a single function call.</div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/778971a4-8253-4885-aeaa-0fd403257bb9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/778971a4-8253-4885-aeaa-0fd403257bb9=
%40isocpp.org</a>.<br />

------=_Part_1137_1589693292.1552752130382--

------=_Part_1136_593923870.1552752130382--

.

------=_Part_1126_2074421185.1552758722993
Content-Type: multipart/alternative;
 boundary="----=_Part_1127_399547832.1552758722994"

------=_Part_1127_399547832.1552758722994
Content-Type: text/plain; charset="UTF-8"


On Saturday, March 16, 2019 at 5:02:10 PM UTC+1, Nicol Bolas wrote:
>
> On Saturday, March 16, 2019 at 11:52:09 AM UTC-4, floria...@gmail.com
> wrote:
>>
>> This looks like a use-case for operator dot ( or delegate base) proposal.
>>
>
> I fail to see how those proposals matter relative to this one.
> Operator-Dot proposals just make it easier to write proxies. The point of
> this idea is to not have proxies to begin with, to combine two operations
> into a single function call.
>

If we had proxies, then would be able to implement all those. But they also
would be used for extra use cases.

This proposal use-case would be completely covered by operator dot
proposals, but not the other way around, so they do matter in the
discussion.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84cbcd7f-7ae5-4d9b-a57d-f99468d37698%40isocpp.org.

------=_Part_1127_399547832.1552758722994
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, March 16, 2019 at 5:02:10 PM UTC+1, Nicol=
 Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Saturday, March 16, 2019 at 11:52:09 AM UTC-4, <a>floria...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This =
looks like a use-case for operator dot ( or delegate base) proposal.</div><=
/div></blockquote><div><br></div><div>I fail to see how those proposals mat=
ter relative to this one. Operator-Dot proposals just make it easier to wri=
te proxies. The point of this idea is to not have proxies to begin with, to=
 combine two operations into a single function call.</div></div></blockquot=
e><div><br></div><div>If we had proxies, then would be able to implement al=
l those. But they also would be used for extra use cases.</div><div><br></d=
iv><div>This proposal use-case would be completely covered by operator dot =
proposals, but not the other way around, so they do matter in the discussio=
n.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/84cbcd7f-7ae5-4d9b-a57d-f99468d37698%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/84cbcd7f-7ae5-4d9b-a57d-f99468d37698=
%40isocpp.org</a>.<br />

------=_Part_1127_399547832.1552758722994--

------=_Part_1126_2074421185.1552758722993--

.

------=_Part_1194_359104751.1552814144631
Content-Type: multipart/alternative;
 boundary="----=_Part_1195_1999644034.1552814144631"

------=_Part_1195_1999644034.1552814144631
Content-Type: text/plain; charset="UTF-8"

Apparently, Google groups refuses to post Nicol's reply, so I paste it
completely here:
My reply will follow into another post


> Nicol Bolas wrote:
> "Completely covered" is a highly dubious phrase. But let's assume that
> this is true and actually have this discussion.
>
> The first thing to realize is that OperatorDot is just a mechanism that
> makes it easier to generate proxy objects. It provides no real
> functionality which you could not emulate yourself right now just by
> writing a huge bunch of code. Indeed, if metaclasses ever becomes a thing,
> then C++ won't need OperatorDot at all.
>
> So the comparison here is really between the hypothetical
> `map::operator[]=` and a version of `map::operator[]` that returns a proxy.
>
> Now, remember the foundational example of this proposal: we want
> `some_map[key] = value;` to copy-construct the value inside of the map
> rather than performing default construction+copy-assignment. `operator[]=`
> accomplishes this directly.
>
> To do this with a proxy `operator[]`, it must return a prvalue object that
> acts like a `Value`. If you try to convert it into a `Value`, then it will
> default-construct the value. However, if you try to assign to it from a
> `Value`, then it will invoke copy/move construction on the uninitialized
> value.
>
> This means that, until the proxy object either is assigned to or invoked,
> the value at that key is not initialized. So... what happens here:
>
> auto &&obj = some_map[key];
> some_map[key] = some_value;
>
> In the current `map` type, this works just fine. `obj` is a reference to
> an initialized value of the map's `Value` type. The subsequent assignment
> assigns to the object that `obj` references. So later accesses to `obj`
> will see this value.
>
> A proxy-based version must emulate this. So... how do you do that? The
> proxy cannot just store a reference to the node. It has to know whether the
> `Value` in that node has been initialized or not, so that when someone
> accesses the proxy, it can know whether to perform initialization if
> needed. Such information cannot be local to the proxy itself, since code
> outside of that proxy can effect it. The data therefore must be part of the
> node itself.
>
> So you just gave the node type an additional byte of overhead (at least).
> Not to mention the additional cost of every piece of code that now needs to
> test whether the node has a value or not.
>
> But this also means that, between those two statements above, the state of
> `some_map` is... odd. There is an entry in the map which is unfinished.
> That is not a good state to leave the `map` in.
>
> Not only that, it now has to be implemented using some... legally dubious
> things, in terms of code. Now yes, implementing `std::map` already requires
> weirdness on the implementer's part, thanks to the ability to extract nodes
> from the `map`, modify their supposedly-`const` keys, and then reinsert
> them. But this is even more dubious. The node cannot store an actual
> `std::pair<Key, Value>`, since some nodes don't have valid values all the
> time.
>
> That's going to be pretty interesting to implement. And by "interesting",
> I mean "exceedingly obtuse expert-level coding".
>
> By contrast, `operator[]=` has no such problems. The node type doesn't
> need this extra "is the value initialized" information. The `map` is always
> in a perfectly legitimate state. And most importantly of all, implementing
> it correctly is way easier for the user. You don't have to write a proxy
> type. You don't have to add extra info to the node. You don't have to find
> a way to write a `pair<Key, Value>` that sometimes doesn't initialize the
> `Value`.
>
> You just add one function, and your code gets better.
>
> At the end of the day, OperatorDot is an *expert-level* feature. What is
> being discussed here is something *anyone* can do.
>
> Also, there is no way to back-port a proxy-based `operator[]` into `map`.
> Something as simple as:
>
> auto &val = some_map[key];
>
> Can't work in a proxy world (that's why I used `auto&&` above). And there
> are *plenty* of people who have written precisely that.
>
> By contrast, the only time an `operator[]=` would have different behavior
> is if default-construction+copy/move assignment is not functionally
> equivalent to copy/move construction for a given type. And at that point...
> I would say that your code *deserves to be broken*.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/694325b7-2f41-42a7-8228-1e57db2c3859%40isocpp.org.

------=_Part_1195_1999644034.1552814144631
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Apparently, Google groups refuses to post Nicol&#39;s=
 reply, so I paste it completely here:</div><div>My reply will follow into =
another post<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;"><div>Nicol Bolas wrote:</div><div><div>&quot;Complete=
ly covered&quot; is a highly dubious phrase. But let&#39;s assume that this=
 is true and actually have this discussion.<br></div><div><br></div><div>Th=
e
 first thing to realize is that OperatorDot is just a mechanism that=20
makes it easier to generate proxy objects. It provides no real=20
functionality which you could=20
not emulate yourself right now just by writing a huge bunch of code.=20
Indeed, if metaclasses ever becomes a thing, then C++ won&#39;t need=20
OperatorDot at all.</div><div><br></div><div>So the comparison here is real=
ly between=20
the hypothetical `map::operator[]=3D` and a version of `map::operator[]`=20
that returns a proxy.</div><div><br></div><div>Now, remember the=20
foundational example of this proposal: we want `some_map[key] =3D value;`=
=20
to copy-construct the value inside of the map rather than performing=20
default construction+copy-assignment. `operator[]=3D` accomplishes this=20
directly.<br></div><div><br></div><div>To do this with a proxy=20
`operator[]`, it must return a prvalue object=20
that acts like a `Value`. If you try to convert it into a `Value`, then=20
it will default-construct the value. However, if you try to assign to it
 from a `Value`, then it will invoke copy/move construction on the=20
uninitialized value.</div><div><br></div><div>This means that, until the
 proxy object either is assigned to or invoked, the value at that key is
 not initialized. So... what happens here:</div><div><br></div><div>auto &a=
mp;&amp;obj =3D some_map[key];</div><div>some_map[key] =3D some_value;</div=
><div><br></div><div>In
 the current `map` type, this works just fine. `obj` is a reference to=20
an initialized value of the map&#39;s `Value` type. The subsequent=20
assignment assigns to the object that `obj` references. So later=20
accesses to `obj` will see this value.</div><div><br></div>A proxy-based ve=
rsion must emulate=20
this. So... how do you do that? The proxy cannot=20
just store a reference to the node. It has to know whether the `Value`=20
in that node has been initialized or not, so that when someone accesses=20
the proxy, it can know whether to perform initialization if needed. Such in=
formation=20
cannot be local to the proxy itself, since code outside of that proxy can e=
ffect it. The data therefore must be part of the=20
node itself.</div><div><br></div>So you just gave the node type an=20
additional byte of overhead (at least). Not to mention the additional=20
cost of every piece of code that now needs to test whether the node has a
 value or not.<br><div><br></div><div>But
 this also means that, between those two statements above, the state of=20
`some_map` is... odd. There is an entry in the map which is unfinished.=20
That is not a good state to leave the `map` in.</div><div><br></div><div>No=
t
 only that, it now has to be implemented using some... legally dubious=20
things, in terms of code. Now yes, implementing `std::map` already=20
requires weirdness on the implementer&#39;s part, thanks to the ability to=
=20
extract nodes from the `map`, modify their supposedly-`const` keys, and=20
then reinsert them. But this is even more dubious. The node cannot store
 an actual `std::pair&lt;Key, Value&gt;`, since some nodes don&#39;t have=
=20
valid values all the time.</div><div><br></div><div>That&#39;s going to be =
pretty interesting to implement. And by &quot;interesting&quot;, I mean &qu=
ot;exceedingly obtuse expert-level coding&quot;.</div><div><br></div><div>B=
y
 contrast, `operator[]=3D` has no such problems. The node type doesn&#39;t=
=20
need this extra &quot;is the value initialized&quot; information. The `map`=
 is=20
always in a perfectly legitimate state. And=20
most importantly of all, implementing it correctly is way easier for the
 user. You don&#39;t have to write a proxy type. You don&#39;t have to add =
extra
 info to the node. You don&#39;t have to find a way to write a `pair&lt;Key=
,
 Value&gt;` that sometimes doesn&#39;t initialize the `Value`.</div><div><b=
r></div><div>You just add one function, and your code gets better.</div><di=
v><br></div><div>At the end of the day, OperatorDot is an <i>expert-level</=
i> feature. What is being discussed here is something <i>anyone</i> can do.=
</div><div><br></div><div>Also, there is no way to back-port a proxy-based =
`operator[]` into `map`. Something as simple as:</div><div><br></div><div>a=
uto &amp;val =3D some_map[key];</div><div><br></div><div>Can&#39;t work in =
a proxy world (that&#39;s why I used `auto&amp;&amp;` above). And there are=
 <i>plenty</i> of people who have written precisely that.<br></div><div><br=
></div>By
 contrast, the only time an `operator[]=3D` would have different behavior=
=20
is if default-construction+copy/move assignment is not functionally=20
equivalent to copy/move construction for a given type. And at that=20
point... I would say that your code <i>deserves to be broken</i>.</blockquo=
te></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/694325b7-2f41-42a7-8228-1e57db2c3859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/694325b7-2f41-42a7-8228-1e57db2c3859=
%40isocpp.org</a>.<br />

------=_Part_1195_1999644034.1552814144631--

------=_Part_1194_359104751.1552814144631--

.

------=_Part_1198_1191212372.1552815747163
Content-Type: text/plain; charset="UTF-8"

Even more general could be to overload a complex expression which  is currently only possible via expression templates and lazy evaluation technics. One might try to use operator overloading in a matrix caculation library:

matrix a,b,c,d;
//...
a=b+c*d;// can I overload this too?

regards,
FM

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a9b23159-7c6e-40f9-ba5a-bf209421d71b%40isocpp.org.

------=_Part_1198_1191212372.1552815747163--

.

------=_Part_1256_1991541341.1552817092775
Content-Type: multipart/alternative;
 boundary="----=_Part_1257_918948895.1552817092777"

------=_Part_1257_918948895.1552817092777
Content-Type: text/plain; charset="UTF-8"

First, I will show a possible implementation using "Smart reference through
delegation because that's the one I know best.

template <class Key, class Value>
struct MyMap : public std::map<Key, Value> {
  struct Proxy : public using Value {
    MyMap& map_ref;
    Key const& key;

    Proxy() = delete;
    Proxy(Proxy const&) = delete;
    Proxy& operator=(Proxy const& other) {
      return *this = static_cast<Value&>(other);
    }

    // Standard proxy
    operator Value&() const {
      auto it = map_ref.find(key);
      if (it == map_ref.end()) {
        it = map_ref.emplace_hint(it, key, Value());
      }
      return it->value;
    }

    // Override operator=
    Proxy& operator=(Value val) {
      auto it = map_ref.find(key);
      if (it == map_ref.end()) {
        it = map_ref.emplace_hint(it, key, std::move(val));
        return *this;
      }
      it->value() = std::move(val);
      return *this;
    }
  };

  Proxy operator[](Key const& key) {
    return {*this, key};
  }
};


Also, please remember I never said that operator[]= was useless if we had
operator dot (or similar), but only that operator[]= features are already
covered by operator dot.
But I completely agree that it is *easier* to write operator[]= than a
proxy.


> "Completely covered" is a highly dubious phrase. But let's assume that
> this is true and actually have this discussion.
>
> The first thing to realize is that OperatorDot is just a mechanism that
> makes it easier to generate proxy objects. It provides no real
> functionality which you could not emulate yourself right now just by
> writing a huge bunch of code. Indeed, if metaclasses ever becomes a thing,
> then C++ won't need OperatorDot at all.
>

It does not only makes easier to generate proxy objects, it does enable the
generation of proxy objects within generic codes. It is currently not
possible to do it if you don't know the type you have to proxyfy.


>
> So the comparison here is really between the hypothetical
> `map::operator[]=` and a version of `map::operator[]` that returns a proxy.
>

Agreed.


>
> Now, remember the foundational example of this proposal: we want
> `some_map[key] = value;` to copy-construct the value inside of the map
> rather than performing default construction+copy-assignment. `operator[]=`
> accomplishes this directly.
>

Agreed. Please take a look at the example I provided at the beginning of
this post on how to implement it with proxies.


>
> To do this with a proxy `operator[]`, it must return a prvalue object that
> acts like a `Value`. If you try to convert it into a `Value`, then it will
> default-construct the value. However, if you try to assign to it from a
> `Value`, then it will invoke copy/move construction on the uninitialized
> value.
>

No, you can "override" an operator from the proxy to change the behavior of
the operator (or a method): see my example.


>
> This means that, until the proxy object either is assigned to or invoked,
> the value at that key is not initialized.
>

Agreed.


> So... what happens here:
>
> auto &&obj = some_map[key];
> some_map[key] = some_value;
>

Simple: obj is a proxy, so does not generate the value at key, but when some_map[key]
= is evaluated, it generates the node at the key with some_value in-place
(no default + copy).
In fact, it works better than operator[]= in that case.
And later use of obj will find the right node because operator Value& is
called on the fly whenever you need it.


>
> In the current `map` type, this works just fine. `obj` is a reference to
> an initialized value of the map's `Value` type. The subsequent assignment
> assigns to the object that `obj` references. So later accesses to `obj`
> will see this value.
>

No problem here, as I just explained, it will behave the same.


>
> A proxy-based version must emulate this. So... how do you do that? The
> proxy cannot just store a reference to the node. It has to know whether the
> `Value` in that node has been initialized or not, so that when someone
> accesses the proxy, it can know whether to perform initialization if
> needed. Such information cannot be local to the proxy itself, since code
> outside of that proxy can effect it. The data therefore must be part of the
> node itself.
>

You don't need extra information in the node, I just explained how to do
that with a proxy.


>
> So you just gave the node type an additional byte of overhead (at least).
> Not to mention the additional cost of every piece of code that now needs to
> test whether the node has a value or not.
>

No. see above.


>
> But this also means that, between those two statements above, the state of
> `some_map` is... odd. There is an entry in the map which is unfinished.
> That is not a good state to leave the `map` in.
>

No, there is no "odd" state of the map. The node is either non-existent, or
completely built.
In your code, it is just that after auto&& obj = some_map[key]; the node is
not yet created, so if you try to find it, you will get no node at all.


>
> Not only that, it now has to be implemented using some... legally dubious
> things, in terms of code. Now yes, implementing `std::map` already requires
> weirdness on the implementer's part, thanks to the ability to extract nodes
> from the `map`, modify their supposedly-`const` keys, and then reinsert
> them. But this is even more dubious. The node cannot store an actual
> `std::pair<Key, Value>`, since some nodes don't have valid values all the
> time.
>

See above: no change of the inner structure of the map.


>
> That's going to be pretty interesting to implement. And by "interesting",
> I mean "exceedingly obtuse expert-level coding".
>

You're overdoing it here.


>
> By contrast, `operator[]=` has no such problems. The node type doesn't
> need this extra "is the value initialized" information. The `map` is always
> in a perfectly legitimate state.
>

No, see above


> And most importantly of all, implementing it correctly is way easier for
> the user. You don't have to write a proxy type.
>

Agreed.


> You don't have to add extra info to the node. You don't have to find a way
> to write a `pair<Key, Value>` that sometimes doesn't initialize the `Value`.
>

This is not needed, see above.


>
> You just add one function, and your code gets better.
>
> At the end of the day, OperatorDot is an *expert-level* feature. What is
> being discussed here is something *anyone* can do.
>

Agreed. And I always agreed on that.
But you cannot talk about operator []= without talking about operator dot,
as one can be used to implement the same stuff as the other.


>
> Also, there is no way to back-port a proxy-based `operator[]` into `map`.
> Something as simple as:
>
> auto &val = some_map[key];
>
> Can't work in a proxy world (that's why I used `auto&&` above). And there
> are *plenty* of people who have written precisely that.
>

using auto = Value; might help (don't remember the proposal).
But this is not a problem operator[]= vs operator dot, but a problem of operator
dot by itself, which has to be solved anyway.


>
> By contrast, the only time an `operator[]=` would have different behavior
> is if default-construction+copy/move assignment is not functionally
> equivalent to copy/move construction for a given type. And at that point...
> I would say that your code *deserves to be broken*.


Agreed.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b50d3b27-78b9-430e-bd65-c6e9103006cb%40isocpp.org.

------=_Part_1257_918948895.1552817092777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>First, I will show a possible implementation using &q=
uot;Smart reference through delegation because that&#39;s the one I know be=
st.</div><div><br></div><div><div style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Key</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Value</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">MyMa=
p</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">map</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Key</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Value</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Proxy</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">public</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Value</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">MyMap</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> map_ref</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Key</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> key</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Proxy</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">delete</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Proxy</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Prox=
y</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&amp;)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">delete</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Proxy</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
operator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Proxy<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> other</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">this</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Value</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;&gt;(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">other</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// Standard proxy</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Value</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&amp;()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> it </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> map_ref</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">find</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">key</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">it </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> map_ref</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">end</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">())</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 it </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ma=
p_ref</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">emplace_hint</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">it</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> key</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Value</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">());</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> it</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">value</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// Override operator=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Proxy</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D(</span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Value</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> va=
l</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> it </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> map_ref</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">find</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">key</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">it </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> map_ref</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 it </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> map_ref</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">emplace_hint</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">it</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> key</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">move</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">val</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 it</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">move</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">val</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Proxy<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Key</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> key</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{*</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> key</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div></div><div><br></div><div><br></div><div>Al=
so, please remember I never said that <span style=3D"font-family: courier n=
ew, monospace;">operator[]=3D</span> was useless if we had operator dot (or=
 similar), but only that <span style=3D"font-family: courier new, monospace=
;">operator[]=3D</span> features are already covered by operator dot.</div>=
<div>But I completely agree that it is <b>easier</b> to write <span style=
=3D"font-family: courier new, monospace;">operator[]=3D</span> than a proxy=
..<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-l=
eft: 1ex;"><div><div>&quot;Completely covered&quot; is a highly dubious phr=
ase. But let&#39;s assume that this is true and actually have this discussi=
on.<br></div><div><br></div><div>The
 first thing to realize is that OperatorDot is just a mechanism that=20
makes it easier to generate proxy objects. It provides no real=20
functionality which you could=20
not emulate yourself right now just by writing a huge bunch of code.=20
Indeed, if metaclasses ever becomes a thing, then C++ won&#39;t need=20
OperatorDot at all.</div></div></blockquote><div><br></div><div>It does not=
 only makes easier to generate proxy objects, it does enable the generation=
 of proxy objects within generic codes. It is currently not possible to do =
it if you don&#39;t know the type you have to proxyfy.<br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div><=
br></div><div>So the comparison here is really between=20
the hypothetical `map::operator[]=3D` and a version of `map::operator[]`=20
that returns a proxy.</div></div></blockquote><div><br></div><div>Agreed.<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;"><div><div><br></div><div>Now, remember the=20
foundational example of this proposal: we want `some_map[key] =3D value;`=
=20
to copy-construct the value inside of the map rather than performing=20
default construction+copy-assignment. `operator[]=3D` accomplishes this=20
directly.<br></div></div></blockquote><div><br></div><div>Agreed. Please ta=
ke a look at the example I provided at the beginning of this post on how to=
 implement it with proxies.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb=
(204, 204, 204); padding-left: 1ex;"><div><div></div><div><br></div><div>To=
 do this with a proxy=20
`operator[]`, it must return a prvalue object=20
that acts like a `Value`. If you try to convert it into a `Value`, then=20
it will default-construct the value. However, if you try to assign to it
 from a `Value`, then it will invoke copy/move construction on the=20
uninitialized value.</div></div></blockquote><div><br></div><div>No, you ca=
n &quot;override&quot; an operator from the proxy to change the behavior of=
 the operator (or a method): see my example.<br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div><br></div><=
div>This means that, until the
 proxy object either is assigned to or invoked, the value at that key is
 not initialized.</div></div></blockquote><div><br></div><div>Agreed.<br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;"><div><div>So... what happens here:</div><div><br></div><div>auto &amp;&=
amp;obj =3D some_map[key];</div><div>some_map[key] =3D some_value;</div></d=
iv></blockquote><div><br></div><div>Simple: <span style=3D"font-family: cou=
rier new, monospace;">obj</span> is a proxy, so does not generate the value=
 at key, but when <span style=3D"font-family: courier new, monospace;">some=
_map[key] =3D</span> is evaluated, it generates the node at the <span style=
=3D"font-family: courier new, monospace;">key</span> with some_value in-pla=
ce (no default + copy).</div><div>In fact, it works better than <span style=
=3D"font-family: courier new, monospace;">operator[]=3D</span> in that case=
..</div><div>And later use of <span style=3D"font-family: courier new, monos=
pace;">obj</span> will find the right node because <span style=3D"font-fami=
ly: courier new, monospace;">operator Value&amp;</span> is called on the fl=
y whenever you need it.<br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;"><div><div><br></div><div>In
 the current `map` type, this works just fine. `obj` is a reference to=20
an initialized value of the map&#39;s `Value` type. The subsequent=20
assignment assigns to the object that `obj` references. So later=20
accesses to `obj` will see this value.</div></div></blockquote><div><br></d=
iv><div>No problem here, as I just explained, it will behave the same.<br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;"><div><div><br></div>A proxy-based version must emulate=20
this. So... how do you do that? The proxy cannot=20
just store a reference to the node. It has to know whether the `Value`=20
in that node has been initialized or not, so that when someone accesses=20
the proxy, it can know whether to perform initialization if needed. Such in=
formation=20
cannot be local to the proxy itself, since code outside of that proxy can e=
ffect it. The data therefore must be part of the=20
node itself.</div></blockquote><div><br></div><div>You don&#39;t need extra=
 information in the node, I just explained how to do that with a proxy.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;"><div><br></div>So you just gave the node type an=20
additional byte of overhead (at least). Not to mention the additional=20
cost of every piece of code that now needs to test whether the node has a
 value or not.<br></blockquote><div><br></div><div>No. see above.<br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<div><br></div><div>But
 this also means that, between those two statements above, the state of=20
`some_map` is... odd. There is an entry in the map which is unfinished.=20
That is not a good state to leave the `map` in.</div></blockquote><div><br>=
</div><div>No, there is no &quot;odd&quot; state of the map. The node is ei=
ther non-existent, or completely built.</div><div>In your code, it is just =
that after <span style=3D"font-family: courier new, monospace;">auto&amp;&a=
mp; obj =3D some_map[key];</span> the node is not yet created, so if you tr=
y to <span style=3D"font-family: courier new, monospace;">find</span> it, y=
ou will get no node at all.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;"><div><br></div><div>Not
 only that, it now has to be implemented using some... legally dubious=20
things, in terms of code. Now yes, implementing `std::map` already=20
requires weirdness on the implementer&#39;s part, thanks to the ability to=
=20
extract nodes from the `map`, modify their supposedly-`const` keys, and=20
then reinsert them. But this is even more dubious. The node cannot store
 an actual `std::pair&lt;Key, Value&gt;`, since some nodes don&#39;t have=
=20
valid values all the time.</div></blockquote><div><br></div><div>See above:=
 no change of the inner structure of the map.<br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br></div><div>=
That&#39;s going to be pretty interesting to implement. And by &quot;intere=
sting&quot;, I mean &quot;exceedingly obtuse expert-level coding&quot;.</di=
v></blockquote><div><br></div><div>You&#39;re overdoing it here.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><=
div><br></div><div>By
 contrast, `operator[]=3D` has no such problems. The node type doesn&#39;t=
=20
need this extra &quot;is the value initialized&quot; information. The `map`=
 is=20
always in a perfectly legitimate state.</div></blockquote><div><br></div><d=
iv>No, see above<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;"><div>And=20
most importantly of all, implementing it correctly is way easier for the
 user. You don&#39;t have to write a proxy type.</div></blockquote><div><br=
></div><div>Agreed.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;"><div>You don&#39;t have to add extra
 info to the node. You don&#39;t have to find a way to write a `pair&lt;Key=
,
 Value&gt;` that sometimes doesn&#39;t initialize the `Value`.</div></block=
quote><div><br></div><div>This is not needed, see above.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br=
></div><div>You just add one function, and your code gets better.</div><div=
><br></div><div>At the end of the day, OperatorDot is an <i>expert-level</i=
> feature. What is being discussed here is something <i>anyone</i> can do.<=
/div></blockquote><div><br></div><div>Agreed. And I always agreed on that.<=
/div><div>But you cannot talk about <span style=3D"font-family: courier new=
, monospace;">operator []=3D</span> without talking about operator dot, as =
one can be used to implement the same stuff as the other.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br=
></div><div>Also, there is no way to back-port a proxy-based `operator[]` i=
nto `map`. Something as simple as:</div><div><br></div><div>auto &amp;val =
=3D some_map[key];</div><div><br></div><div>Can&#39;t work in a proxy world=
 (that&#39;s why I used `auto&amp;&amp;` above). And there are <i>plenty</i=
> of people who have written precisely that.<br></div></blockquote><div><br=
></div><div><span style=3D"font-family: courier new, monospace;">using auto=
 =3D Value;</span> might help (don&#39;t remember the proposal).</div><div>=
But this is not a problem <span style=3D"font-family: courier new, monospac=
e;">operator[]=3D</span> vs <span style=3D"font-family: courier new, monosp=
ace;">operator dot</span>, but a problem of <span style=3D"font-family: cou=
rier new, monospace;">operator dot</span> by itself, which has to be solved=
 anyway.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"><div></div><div><br></div>By
 contrast, the only time an `operator[]=3D` would have different behavior=
=20
is if default-construction+copy/move assignment is not functionally=20
equivalent to copy/move construction for a given type. And at that=20
point... I would say that your code <i>deserves to be broken</i>.</blockquo=
te><div><br></div><div>Agreed. <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b50d3b27-78b9-430e-bd65-c6e9103006cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b50d3b27-78b9-430e-bd65-c6e9103006cb=
%40isocpp.org</a>.<br />

------=_Part_1257_918948895.1552817092777--

------=_Part_1256_1991541341.1552817092775--

.

------=_Part_1158_735973007.1552829223915
Content-Type: multipart/alternative;
 boundary="----=_Part_1159_952346900.1552829223915"

------=_Part_1159_952346900.1552829223915
Content-Type: text/plain; charset="UTF-8"


On Friday, March 15, 2019 at 8:33:20 AM UTC-7, Nicol Bolas wrote:
>
> Especially since the obvious `operator*=` is already taken ;)
>

A straightforward solution is to introduce a std tag type:


    T& operator*=(std::op_assign_equal, ...);

Regards
Vinnie

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0ab12cb5-2b8e-47f2-b123-c3a54c832696%40isocpp.org.

------=_Part_1159_952346900.1552829223915
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, March 15, 2019 at 8:33:20 AM UTC-7, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div>Especially since the obvious `operator*=3D` is already taken ;)</di=
v></div></div></blockquote><div><br></div><div>A straightforward solution i=
s to introduce a std tag type:</div><div><br></div><div><br></div><div>=C2=
=A0 =C2=A0 T&amp; operator*=3D(std::op_assign_equal, ...);<br><br>Regards<b=
r>Vinnie<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0ab12cb5-2b8e-47f2-b123-c3a54c832696%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ab12cb5-2b8e-47f2-b123-c3a54c832696=
%40isocpp.org</a>.<br />

------=_Part_1159_952346900.1552829223915--

------=_Part_1158_735973007.1552829223915--

.

------=_Part_1303_922616890.1552838632460
Content-Type: multipart/alternative;
 boundary="----=_Part_1304_1293495368.1552838632461"

------=_Part_1304_1293495368.1552838632461
Content-Type: text/plain; charset="UTF-8"


Oh, and here's another problem with proxies. Consider the following code:

map<string, int> some_map;
some_map["foo"s];

By the rules of `map::operator[]`, it must default-construct that entry.
But in the proxy-based version, the proxy is never accessed. So the only
way to default-construct that entry is to do it in the proxy's destructor.

Here's the thing though. `operator[]=` would have the same semantics as
`insert_or_assign`. Namely, that `Value` does not need to be default
constructible. Your `proxy::operator=` can provide similar behavior. But
your `proxy::~proxy` *cannot*.

See, if `Value` is not default constructible, then in an `map::operator[]=`
world, calling `map::operator[]` is a compile error. But with a proxy
solution... what happens? You can't make calling `proxy::~proxy` a compile
error for this case, because you cannot know *at compile time* if the user
assigned to the proxy. It can be a runtime error, but throwing from a
destructor is bad.

So with the proxy based solution, if the `Value` is not default
constructible, the best you can do is simply... not insert the element in
the destructor. Even though that's what `operator[]` is *supposed to do*.

Using indirect methods to simulate a direct action (proxies to simulate
combined operations) is almost always faulty.

On Sunday, March 17, 2019 at 6:04:52 AM UTC-4, floria...@gmail.com wrote:

> A proxy-based version must emulate this. So... how do you do that? The
>> proxy cannot just store a reference to the node. It has to know whether the
>> `Value` in that node has been initialized or not, so that when someone
>> accesses the proxy, it can know whether to perform initialization if
>> needed. Such information cannot be local to the proxy itself, since code
>> outside of that proxy can effect it. The data therefore must be part of the
>> node itself.
>>
>
> You don't need extra information in the node, I just explained how to do
> that with a proxy.
>

And your implementation of this is buggy. For example:

auto &&obj = some_map[func()];

If `func()` returns a prvalue, that means the key will be destroyed at the
end of this expression. Also, if `func()` returns a type implicitly
convertible to `Key`, then the system will have to create a temporary...
which will be destroyed at the end of the expression. So storing a
reference to the `Key` is not going to work.

Either you do it based on the node as I suggested, or your proxy must store
a *copy* of the key. Neither option is a good one. The node one has all of
the problems I suggested.

The storing of a key in the proxy has the following problems:

1. The proxy is now potentially much bigger and heavier weight. Keys
sometimes allocate memory, so copying it is going to lead to a lot of extra
memory allocations. Just consider a `map<string, int>`; the value is cheap,
but the key is not. Yes, copying a proxy is not something that's likely to
happen, since if you wanted a reference to the value, you would use a
reference, not a value. But you still have to create the initial copy.

2. Every access to the value through the proxy is an O(log(n)) operation.
That is not acceptable. Oh sure, you could put a `Value*` in there which
you initialize if the key comes back as being initialized. But now you're
having to test that internal pointer, then test the return of `find`.
That's a lot of conditional branching in something that ought to be trivial.

There's no version of the proxy-based solution that's actually good; there
are only varying degrees of bad.

So you just gave the node type an additional byte of overhead (at least).
>> Not to mention the additional cost of every piece of code that now needs to
>> test whether the node has a value or not.
>>
>
>
No. see above.
>

FYI: you don't have to respond to every single sentence or paragraph in my
post. If you've already said something that makes a later point of mine
moot, you can just ignore it.

You just add one function, and your code gets better.
>>
>> At the end of the day, OperatorDot is an *expert-level* feature. What is
>> being discussed here is something *anyone* can do.
>>
>
> Agreed. And I always agreed on that.
> But you cannot talk about operator []= without talking about operator
> dot, as one can be used to implement the same stuff as the other.
>

My problem is this. The proxy-based solution is harder to use, harder to
implement correctly, harder to implement with equivalent performance in
important cases, and cannot be dropped into existing data structures
without creating backwards-incompatible changes.

Bringing up an alternative solution that is so obviously broken on so many
levels feels like erecting a strawman: you're creating a fake adversary for
the sole purpose of looking good by defeating it. Proxies are a sub-optimal
solution; everyone knows its a sub-optimal solution, so why are we talking
about them?

Also, there's the little problem that OperatorDot is *dead*. It's probably
Uniform-Call-Syntax-levels of dead. Stroustrup was a major proponent of the
idea, and it's not even on *his* list of priorities for C++ now, let alone
the direction group's priorities. It's hard to say that an alternative
exists when the alternative will likely never actually *exist*.

Also, there is no way to back-port a proxy-based `operator[]` into `map`.
>> Something as simple as:
>>
>> auto &val = some_map[key];
>>
>> Can't work in a proxy world (that's why I used `auto&&` above). And there
>> are *plenty* of people who have written precisely that.
>>
>
> using auto = Value; might help (don't remember the proposal).
> But this is not a problem operator[]= vs operator dot, but a problem of operator
> dot by itself, which has to be solved anyway.
>

But that's why I say that OperatorDot is *irrelevant*. All of the problems
with the OperatorDot approach you outlined are problems that are
fundamental to *any proxy-based solution*. It's like, there are 20 problems
with using proxies for this in C++ as it currently stands; OperatorDot only
solves *one* of those problems.

I don't see how it's a genuine alternative if it still has the other 19
problems.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b92f9628-acb1-4065-982b-7be1b99c6f07%40isocpp.org.

------=_Part_1304_1293495368.1552838632461
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div></div><div>Oh, and here&#39;s another problem wi=
th proxies. Consider the following code:</div><div><br></div><div>map&lt;st=
ring, int&gt; some_map;</div><div>some_map[&quot;foo&quot;s];</div><br><div=
>By
 the rules of `map::operator[]`, it must default-construct that entry.=20
But in the proxy-based version, the proxy is never accessed. So the only
 way to default-construct that entry is to do it in the proxy&#39;s=20
destructor.</div><div><br></div><div>Here&#39;s the thing though.=20
`operator[]=3D` would have the same semantics as `insert_or_assign`.=20
Namely, that `Value` does not need to be default constructible. Your=20
`proxy::operator=3D` can provide similar behavior. But your=20
`proxy::~proxy` <i>cannot</i>.</div><div><br></div><div>See, if `Value`=20
is not default constructible, then in an `map::operator[]=3D` world,=20
calling `map::operator[]` is a compile error. But with a proxy=20
solution... what happens? You can&#39;t make calling `proxy::~proxy` a=20
compile error for this case, because you cannot know <i>at compile time</i>=
 if the user assigned to the proxy. It can be a runtime error, but throwing=
 from a destructor is bad.</div><div><br></div><div>So
 with the proxy based solution, if the `Value` is not default=20
constructible, the best you can do is simply... not insert the element=20
in the destructor. Even though that&#39;s what `operator[]` is <i>supposed =
to do</i>.</div><div><br></div>Using indirect methods to simulate a direct =
action (proxies to simulate combined operations) is almost always faulty.<b=
r></div><div><br></div><div>On Sunday, March 17, 2019 at 6:04:52 AM UTC-4, =
floria...@gmail.com wrote:</div><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div><div></div>A proxy-based version must emulate=20
this. So... how do you do that? The proxy cannot=20
just store a reference to the node. It has to know whether the `Value`=20
in that node has been initialized or not, so that when someone accesses=20
the proxy, it can know whether to perform initialization if needed. Such in=
formation=20
cannot be local to the proxy itself, since code outside of that proxy can e=
ffect it. The data therefore must be part of the=20
node itself.</div></blockquote><div><br></div><div>You don&#39;t need extra=
 information in the node, I just explained how to do that with a proxy.<br>=
</div></div></blockquote><div><br></div><div>And your implementation of thi=
s is buggy. For example:<br></div><div><br></div><div>auto &amp;&amp;obj =
=3D some_map[func()];</div><div><br></div><div>If `func()` returns a prvalu=
e, that means the key will be destroyed at the end of this expression. Also=
, if `func()` returns a type implicitly convertible to `Key`, then the syst=
em will have to create a temporary... which will be destroyed at the end of=
 the expression. So storing a reference to the `Key` is not going to work.<=
br></div><div><br></div><div>Either you do it based on the node as I sugges=
ted, or your proxy must store a <i>copy</i> of the key. Neither option is a=
 good one. The node one has all of the problems I suggested.</div><div><br>=
</div><div>The storing of a key in the proxy has the following problems:</d=
iv><div><br></div><div>1. The proxy is now potentially much bigger and heav=
ier weight. Keys sometimes allocate memory, so copying it is going to lead =
to a lot of extra memory allocations. Just consider a `map&lt;string, int&g=
t;`; the value is cheap, but the key is not. Yes, copying a proxy is not so=
mething that&#39;s likely to happen, since if you wanted a reference to the=
 value, you would use a reference, not a value. But you still have to creat=
e the initial copy.<br></div><div><br></div><div>2. Every access to the val=
ue through the proxy is an O(log(n)) operation. That is not acceptable. Oh =
sure, you could put a `Value*` in there which you initialize if the key com=
es back as being initialized. But now you&#39;re having to test that intern=
al pointer, then test the return of `find`. That&#39;s a lot of conditional=
 branching in something that ought to be trivial.</div><div><br></div><div>=
There&#39;s no version of the proxy-based solution that&#39;s actually good=
; there are only varying degrees of bad.</div><div><br></div><div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div>So you j=
ust gave the node type an=20
additional byte of overhead (at least). Not to mention the additional=20
cost of every piece of code that now needs to test whether the node has a
 value or not.<br></blockquote><div>=C2=A0</div></div></blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>No. see above.<b=
r></div></div></blockquote><div><br></div><div>FYI: you don&#39;t have to r=
espond to every single sentence or paragraph in my post. If you&#39;ve alre=
ady said something that makes a later point of mine moot, you can just igno=
re it.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div></div><div>You just add one function, and your code gets better.</div>=
<div><br></div><div>At the end of the day, OperatorDot is an <i>expert-leve=
l</i> feature. What is being discussed here is something <i>anyone</i> can =
do.</div></blockquote><div><br></div><div>Agreed. And I always agreed on th=
at.</div><div>But you cannot talk about <span style=3D"font-family:courier =
new,monospace">operator []=3D</span> without talking about operator dot, as=
 one can be used to implement the same stuff as the other.<br></div></div><=
/blockquote><div><br></div><div>My problem is this. The proxy-based solutio=
n is harder to use, harder to implement correctly, harder to implement with=
 equivalent performance in important cases, and cannot be dropped into exis=
ting data structures without creating backwards-incompatible changes.<br></=
div><div><br></div><div>Bringing up an alternative solution that is so obvi=
ously broken on so many levels feels like erecting a strawman: you&#39;re c=
reating a fake adversary for the sole purpose of looking good by defeating =
it. Proxies are a sub-optimal solution; everyone knows its a sub-optimal so=
lution, so why are we talking about them?<br></div><div><br></div><div>Also=
, there&#39;s the little problem that OperatorDot is <i>dead</i>. It&#39;s =
probably Uniform-Call-Syntax-levels of dead. Stroustrup was a major propone=
nt of the idea, and it&#39;s not even on <i>his</i> list of priorities for =
C++ now, let alone the direction group&#39;s priorities. It&#39;s hard to s=
ay that an alternative exists when the alternative will likely never actual=
ly <i>exist</i>.<br></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div></div><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div></div><div>Also, there is no way to back-port=
 a proxy-based `operator[]` into `map`. Something as simple as:</div><div><=
br></div><div>auto &amp;val =3D some_map[key];</div><div><br></div><div>Can=
&#39;t work in a proxy world (that&#39;s why I used `auto&amp;&amp;` above)=
.. And there are <i>plenty</i> of people who have written precisely that.<br=
></div></blockquote><div><br></div><div><span style=3D"font-family:courier =
new,monospace">using auto =3D Value;</span> might help (don&#39;t remember =
the proposal).</div><div>But this is not a problem <span style=3D"font-fami=
ly:courier new,monospace">operator[]=3D</span> vs <span style=3D"font-famil=
y:courier new,monospace">operator dot</span>, but a problem of <span style=
=3D"font-family:courier new,monospace">operator dot</span> by itself, which=
 has to be solved anyway.<br></div></div></blockquote><div><br></div><div>B=
ut that&#39;s why I say that OperatorDot is <i>irrelevant</i>. All of the p=
roblems with the OperatorDot approach you outlined are problems that are fu=
ndamental to <i>any proxy-based solution</i>. It&#39;s like, there are 20 p=
roblems with using proxies for this in C++ as it currently stands; Operator=
Dot only solves <i>one</i> of those problems.<br></div><div><br></div><div>=
I don&#39;t see how it&#39;s a genuine alternative if it still has the othe=
r 19 problems.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b92f9628-acb1-4065-982b-7be1b99c6f07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b92f9628-acb1-4065-982b-7be1b99c6f07=
%40isocpp.org</a>.<br />

------=_Part_1304_1293495368.1552838632461--

------=_Part_1303_922616890.1552838632460--

.

------=_Part_1238_625824639.1552840838829
Content-Type: multipart/alternative;
 boundary="----=_Part_1239_1921644983.1552840838830"

------=_Part_1239_1921644983.1552840838830
Content-Type: text/plain; charset="UTF-8"

I *never* said operator dot was *better*.

But to consider a proposal, you *must* consider alternatives, and operator
dot *is* an alternative.
So I mentionned operator dot in order to compare the operator[]= proposal
to alternatives and see what is better on each sides.

On Sunday, March 17, 2019 at 5:03:52 PM UTC+1, Nicol Bolas wrote:
>
> Oh, and here's another problem with proxies. Consider the following code:
>
> map<string, int> some_map;
> some_map["foo"s];
>
> By the rules of `map::operator[]`, it must default-construct that entry.
> But in the proxy-based version, the proxy is never accessed. So the only
> way to default-construct that entry is to do it in the proxy's destructor.
>
> Here's the thing though. `operator[]=` would have the same semantics as
> `insert_or_assign`. Namely, that `Value` does not need to be default
> constructible. Your `proxy::operator=` can provide similar behavior. But
> your `proxy::~proxy` *cannot*.
>

This (and the rest of your post) is actually a real problem of operator dot
compared to operator[]=.


>
> See, if `Value` is not default constructible, then in an
> `map::operator[]=` world, calling `map::operator[]` is a compile error. But
> with a proxy solution... what happens? You can't make calling
> `proxy::~proxy` a compile error for this case, because you cannot know *at
> compile time* if the user assigned to the proxy. It can be a runtime
> error, but throwing from a destructor is bad.
>
> So with the proxy based solution, if the `Value` is not default
> constructible, the best you can do is simply... not insert the element in
> the destructor. Even though that's what `operator[]` is *supposed to do*.
>
> Using indirect methods to simulate a direct action (proxies to simulate
> combined operations) is almost always faulty.
>
> On Sunday, March 17, 2019 at 6:04:52 AM UTC-4, floria...@gmail.com wrote:
>
>> A proxy-based version must emulate this. So... how do you do that? The
>>> proxy cannot just store a reference to the node. It has to know whether the
>>> `Value` in that node has been initialized or not, so that when someone
>>> accesses the proxy, it can know whether to perform initialization if
>>> needed. Such information cannot be local to the proxy itself, since code
>>> outside of that proxy can effect it. The data therefore must be part of the
>>> node itself.
>>>
>>
>> You don't need extra information in the node, I just explained how to do
>> that with a proxy.
>>
>
> And your implementation of this is buggy. For example:
>
> auto &&obj = some_map[func()];
>

There is a proposal to fix those kind of lifetime issues (unrelated to
proxies), but I'm unable to find it.


>
> If `func()` returns a prvalue, that means the key will be destroyed at the
> end of this expression. Also, if `func()` returns a type implicitly
> convertible to `Key`, then the system will have to create a temporary...
> which will be destroyed at the end of the expression. So storing a
> reference to the `Key` is not going to work.
>
> Either you do it based on the node as I suggested, or your proxy must
> store a *copy* of the key. Neither option is a good one. The node one has
> all of the problems I suggested.
>
> The storing of a key in the proxy has the following problems:
>
> 1. The proxy is now potentially much bigger and heavier weight. Keys
> sometimes allocate memory, so copying it is going to lead to a lot of extra
> memory allocations. Just consider a `map<string, int>`; the value is cheap,
> but the key is not. Yes, copying a proxy is not something that's likely to
> happen, since if you wanted a reference to the value, you would use a
> reference, not a value. But you still have to create the initial copy.
>
> 2. Every access to the value through the proxy is an O(log(n)) operation.
> That is not acceptable. Oh sure, you could put a `Value*` in there which
> you initialize if the key comes back as being initialized. But now you're
> having to test that internal pointer, then test the return of `find`.
> That's a lot of conditional branching in something that ought to be trivial.
>
> There's no version of the proxy-based solution that's actually good; there
> are only varying degrees of bad.
>
> So you just gave the node type an additional byte of overhead (at least).
>>> Not to mention the additional cost of every piece of code that now needs to
>>> test whether the node has a value or not.
>>>
>>
>>
> No. see above.
>>
>
> FYI: you don't have to respond to every single sentence or paragraph in my
> post. If you've already said something that makes a later point of mine
> moot, you can just ignore it.
>
> You just add one function, and your code gets better.
>>>
>>> At the end of the day, OperatorDot is an *expert-level* feature. What
>>> is being discussed here is something *anyone* can do.
>>>
>>
>> Agreed. And I always agreed on that.
>> But you cannot talk about operator []= without talking about operator
>> dot, as one can be used to implement the same stuff as the other.
>>
>
> My problem is this. The proxy-based solution is harder to use, harder to
> implement correctly, harder to implement with equivalent performance in
> important cases, and cannot be dropped into existing data structures
> without creating backwards-incompatible changes.
>

Agreed.


>
> Bringing up an alternative solution that is so obviously broken on so many
> levels feels like erecting a strawman: you're creating a fake adversary for
> the sole purpose of looking good by defeating it. Proxies are a sub-optimal
> solution; everyone knows its a sub-optimal solution, so why are we talking
> about them?
>

Because it is a more generic solution (it is not only about operator[]), so
if at some point operator dot is part of the language (with most of the
issues you pointed out that can be solved, solved), would it still make
sense to integrate operator[]= ?
You showed some good reasons why it should, fair enough.

Please keep in mind that operator dot is a sub-optimal solution only in its
current state, but most issues are actually solvable.


>
> Also, there's the little problem that OperatorDot is *dead*. It's
> probably Uniform-Call-Syntax-levels of dead. Stroustrup was a major
> proponent of the idea, and it's not even on *his* list of priorities for
> C++ now, let alone the direction group's priorities. It's hard to say that
> an alternative exists when the alternative will likely never actually
> *exist*.
>

In the past few months, I encountered a couple of case where I actually
needed good proxies. I cannot think that I'm the only one in the world in
that case.
It has lost interest, that's for sure.
But if proxies are implemented with metaclasses, that would still be an
alternative to operator[]=. So the alternative to operator[]= is not really
operator dot, but anything that can actually implement generic proxies.


>
> Also, there is no way to back-port a proxy-based `operator[]` into `map`.
>>> Something as simple as:
>>>
>>> auto &val = some_map[key];
>>>
>>> Can't work in a proxy world (that's why I used `auto&&` above). And
>>> there are *plenty* of people who have written precisely that.
>>>
>>
>> using auto = Value; might help (don't remember the proposal).
>> But this is not a problem operator[]= vs operator dot, but a problem of operator
>> dot by itself, which has to be solved anyway.
>>
>
> But that's why I say that OperatorDot is *irrelevant*. All of the
> problems with the OperatorDot approach you outlined are problems that are
> fundamental to *any proxy-based solution*. It's like, there are 20
> problems with using proxies for this in C++ as it currently stands;
> OperatorDot only solves *one* of those problems.
>
> I don't see how it's a genuine alternative if it still has the other 19
> problems.
>

Because most of these problems will eventually find a solution (or C++ will
be forever a broken language).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc44f5bf-770e-41f8-8abb-18ec45bf17a9%40isocpp.org.

------=_Part_1239_1921644983.1552840838830
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I <b>never</b> said operator dot was <i>better</i>.</=
div><div><br></div><div>But to consider a proposal, you <b>must</b> conside=
r alternatives, and operator dot <b>is</b> an alternative.</div><div>So I m=
entionned operator dot in order to compare the operator[]=3D proposal to al=
ternatives and see what is better on each sides.<br></div><br>On Sunday, Ma=
rch 17, 2019 at 5:03:52 PM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div></div><div>Oh, and here&#3=
9;s another problem with proxies. Consider the following code:</div><div><b=
r></div><div>map&lt;string, int&gt; some_map;</div><div>some_map[&quot;foo&=
quot;s];</div><br><div>By
 the rules of `map::operator[]`, it must default-construct that entry.=20
But in the proxy-based version, the proxy is never accessed. So the only
 way to default-construct that entry is to do it in the proxy&#39;s=20
destructor.</div><div><br></div><div>Here&#39;s the thing though.=20
`operator[]=3D` would have the same semantics as `insert_or_assign`.=20
Namely, that `Value` does not need to be default constructible. Your=20
`proxy::operator=3D` can provide similar behavior. But your=20
`proxy::~proxy` <i>cannot</i>.</div></div></div></blockquote><div><br></div=
><div>This (and the rest of your post) is actually a real problem of operat=
or dot compared to operator[]=3D.<br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><br></div><div>See=
, if `Value`=20
is not default constructible, then in an `map::operator[]=3D` world,=20
calling `map::operator[]` is a compile error. But with a proxy=20
solution... what happens? You can&#39;t make calling `proxy::~proxy` a=20
compile error for this case, because you cannot know <i>at compile time</i>=
 if the user assigned to the proxy. It can be a runtime error, but throwing=
 from a destructor is bad.</div><div><br></div><div>So
 with the proxy based solution, if the `Value` is not default=20
constructible, the best you can do is simply... not insert the element=20
in the destructor. Even though that&#39;s what `operator[]` is <i>supposed =
to do</i>.</div><div><br></div>Using indirect methods to simulate a direct =
action (proxies to simulate combined operations) is almost always faulty.<b=
r></div><div><br></div><div>On Sunday, March 17, 2019 at 6:04:52 AM UTC-4, =
<a>floria...@gmail.com</a> wrote:</div><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div><div></div>A proxy-based version must emulate=20
this. So... how do you do that? The proxy cannot=20
just store a reference to the node. It has to know whether the `Value`=20
in that node has been initialized or not, so that when someone accesses=20
the proxy, it can know whether to perform initialization if needed. Such in=
formation=20
cannot be local to the proxy itself, since code outside of that proxy can e=
ffect it. The data therefore must be part of the=20
node itself.</div></blockquote><div><br></div><div>You don&#39;t need extra=
 information in the node, I just explained how to do that with a proxy.<br>=
</div></div></blockquote><div><br></div><div>And your implementation of thi=
s is buggy. For example:<br></div><div><br></div><div>auto &amp;&amp;obj =
=3D some_map[func()];</div></div></blockquote><div><br></div><div>There is =
a proposal to fix those kind of lifetime issues (unrelated to proxies), but=
 I&#39;m unable to find it.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>If `func()` re=
turns a prvalue, that means the key will be destroyed at the end of this ex=
pression. Also, if `func()` returns a type implicitly convertible to `Key`,=
 then the system will have to create a temporary... which will be destroyed=
 at the end of the expression. So storing a reference to the `Key` is not g=
oing to work.<br></div><div><br></div><div>Either you do it based on the no=
de as I suggested, or your proxy must store a <i>copy</i> of the key. Neith=
er option is a good one. The node one has all of the problems I suggested.<=
/div><div><br></div><div>The storing of a key in the proxy has the followin=
g problems:</div><div><br></div><div>1. The proxy is now potentially much b=
igger and heavier weight. Keys sometimes allocate memory, so copying it is =
going to lead to a lot of extra memory allocations. Just consider a `map&lt=
;string, int&gt;`; the value is cheap, but the key is not. Yes, copying a p=
roxy is not something that&#39;s likely to happen, since if you wanted a re=
ference to the value, you would use a reference, not a value. But you still=
 have to create the initial copy.<br></div><div><br></div><div>2. Every acc=
ess to the value through the proxy is an O(log(n)) operation. That is not a=
cceptable. Oh sure, you could put a `Value*` in there which you initialize =
if the key comes back as being initialized. But now you&#39;re having to te=
st that internal pointer, then test the return of `find`. That&#39;s a lot =
of conditional branching in something that ought to be trivial.</div><div><=
br></div><div>There&#39;s no version of the proxy-based solution that&#39;s=
 actually good; there are only varying degrees of bad.</div><div><br></div>=
<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></=
div><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div=
>So you just gave the node type an=20
additional byte of overhead (at least). Not to mention the additional=20
cost of every piece of code that now needs to test whether the node has a
 value or not.<br></blockquote><div>=C2=A0</div></div></blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>No. see above.<br></d=
iv></div></blockquote><div><br></div><div>FYI: you don&#39;t have to respon=
d to every single sentence or paragraph in my post. If you&#39;ve already s=
aid something that makes a later point of mine moot, you can just ignore it=
..</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div=
><div>You just add one function, and your code gets better.</div><div><br><=
/div><div>At the end of the day, OperatorDot is an <i>expert-level</i> feat=
ure. What is being discussed here is something <i>anyone</i> can do.</div><=
/blockquote><div><br></div><div>Agreed. And I always agreed on that.</div><=
div>But you cannot talk about <span style=3D"font-family:courier new,monosp=
ace">operator []=3D</span> without talking about operator dot, as one can b=
e used to implement the same stuff as the other.<br></div></div></blockquot=
e><div><br></div><div>My problem is this. The proxy-based solution is harde=
r to use, harder to implement correctly, harder to implement with equivalen=
t performance in important cases, and cannot be dropped into existing data =
structures without creating backwards-incompatible changes.<br></div></div>=
</blockquote><div><br></div><div>Agreed.<br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br><=
/div><div>Bringing up an alternative solution that is so obviously broken o=
n so many levels feels like erecting a strawman: you&#39;re creating a fake=
 adversary for the sole purpose of looking good by defeating it. Proxies ar=
e a sub-optimal solution; everyone knows its a sub-optimal solution, so why=
 are we talking about them?<br></div></div></blockquote><div><br></div><div=
>Because it is a more generic solution (it is not only about operator[]), s=
o if at some point operator dot is part of the language (with most of the i=
ssues you pointed out that can be solved, solved), would it still make sens=
e to integrate operator[]=3D ?<br></div><div>You showed some good reasons w=
hy it should, fair enough.</div><div><br></div><div>Please keep in mind tha=
t operator dot is a sub-optimal solution only in its current state, but mos=
t issues are actually solvable.<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><div=
>Also, there&#39;s the little problem that OperatorDot is <i>dead</i>. It&#=
39;s probably Uniform-Call-Syntax-levels of dead. Stroustrup was a major pr=
oponent of the idea, and it&#39;s not even on <i>his</i> list of priorities=
 for C++ now, let alone the direction group&#39;s priorities. It&#39;s hard=
 to say that an alternative exists when the alternative will likely never a=
ctually <i>exist</i>.<br></div></div></blockquote><div><br></div><div>In th=
e past few months, I encountered a couple of case where I actually needed g=
ood proxies. I cannot think that I&#39;m the only one in the world in that =
case.</div><div>It has lost interest, that&#39;s for sure.</div><div>But if=
 proxies are implemented with metaclasses, that would still be an alternati=
ve to operator[]=3D. So the alternative to operator[]=3D is not really oper=
ator dot, but anything that can actually implement generic proxies.<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div></div><div>Also, there is no way to back-port a proxy-based=
 `operator[]` into `map`. Something as simple as:</div><div><br></div><div>=
auto &amp;val =3D some_map[key];</div><div><br></div><div>Can&#39;t work in=
 a proxy world (that&#39;s why I used `auto&amp;&amp;` above). And there ar=
e <i>plenty</i> of people who have written precisely that.<br></div></block=
quote><div><br></div><div><span style=3D"font-family:courier new,monospace"=
>using auto =3D Value;</span> might help (don&#39;t remember the proposal).=
</div><div>But this is not a problem <span style=3D"font-family:courier new=
,monospace">operator[]=3D</span> vs <span style=3D"font-family:courier new,=
monospace">operator dot</span>, but a problem of <span style=3D"font-family=
:courier new,monospace">operator dot</span> by itself, which has to be solv=
ed anyway.<br></div></div></blockquote><div><br></div><div>But that&#39;s w=
hy I say that OperatorDot is <i>irrelevant</i>. All of the problems with th=
e OperatorDot approach you outlined are problems that are fundamental to <i=
>any proxy-based solution</i>. It&#39;s like, there are 20 problems with us=
ing proxies for this in C++ as it currently stands; OperatorDot only solves=
 <i>one</i> of those problems.<br></div><div><br></div><div>I don&#39;t see=
 how it&#39;s a genuine alternative if it still has the other 19 problems.<=
br></div></div></blockquote><div><br></div><div>Because most of these probl=
ems will eventually find a solution (or C++ will be forever a broken langua=
ge). <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cc44f5bf-770e-41f8-8abb-18ec45bf17a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc44f5bf-770e-41f8-8abb-18ec45bf17a9=
%40isocpp.org</a>.<br />

------=_Part_1239_1921644983.1552840838830--

------=_Part_1238_625824639.1552840838829--

.

------=_Part_1270_2047099319.1552849214526
Content-Type: multipart/alternative;
 boundary="----=_Part_1271_1103837066.1552849214527"

------=_Part_1271_1103837066.1552849214527
Content-Type: text/plain; charset="UTF-8"

A few thoughts on proxies, in a modern light:

   - We should probably have "proxy invalidation" rules. It seems tricky to
   implement something like looking up an existing value into a proxy, then
   allowing an interleaving deletion of that element, and then still letting
   that proxy do something useful.
   - That said, the proxy could have a two-fold nature: if the key was
   found, it stores only the relevant iterator. If the key was not found, it
   stores a special kind of *node-handle* where the mapped-element isn't
   constructed yet, along with relevant hint information (a lower-bound
   iterator for ordered maps, and a precomputed hash for unordered maps).
   Having the *node-handle* solves the problem of retaining the key for
   later use without making copies or having dangling references. Upon
   assignment, the mapped-element is constructed in-place and the node handle
   is inserted.



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/566197ea-a415-4d2d-9adc-b2a2ff26bdf9%40isocpp.org.

------=_Part_1271_1103837066.1552849214527
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A few thoughts on proxies, in a modern light:<div><ul><li>=
We should probably have &quot;proxy invalidation&quot; rules. It seems tric=
ky to implement something like looking up an existing value into a proxy, t=
hen allowing an interleaving deletion of that element, and then still letti=
ng that proxy do something useful.</li><li>That said, the proxy could have =
a two-fold nature: if the key was found, it stores only the relevant iterat=
or. If the key was not found, it stores a special kind of=C2=A0<i>node-hand=
le</i> where the mapped-element isn&#39;t constructed yet, along with relev=
ant hint information (a lower-bound iterator for ordered maps, and a precom=
puted hash for unordered maps). Having the <i>node-handle</i> solves the pr=
oblem of retaining the key for later use without making copies or having da=
ngling references. Upon assignment, the mapped-element is constructed in-pl=
ace and the node handle is inserted.<br><br></li></ul></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/566197ea-a415-4d2d-9adc-b2a2ff26bdf9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/566197ea-a415-4d2d-9adc-b2a2ff26bdf9=
%40isocpp.org</a>.<br />

------=_Part_1271_1103837066.1552849214527--

------=_Part_1270_2047099319.1552849214526--

.

------=_Part_1280_1662110632.1552864108608
Content-Type: multipart/alternative;
 boundary="----=_Part_1281_1670503988.1552864108608"

------=_Part_1281_1670503988.1552864108608
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

T24gU2F0dXJkYXksIDE2LjAzLjIwMTkg0LMuLCAxNjozNzozMyBVVEMrMyBOaWNvbCBCb2xhcyB3
cm90ZToNCj4NCj4gT24gU2F0dXJkYXksIE1hcmNoIDE2LCAyMDE5IGF0IDM6NDg6NTAgQU0gVVRD
LTQsIHdwbWdwcm8uLi5AZ21haWwuY29tIA0KPiB3cm90ZToNCj4+DQo+PiBhbmQgYCppdCsrID0g
Zm9vO2ANCj4+Pg0KPj4NCj4+IEkgdG90YWxseSBtaXNzZWQgaXQuIEl0IGlzIHJlYWxseSBoYXJk
IHRvIGZpbmQgYSBnZW5lcmFsIHNvbHV0aW9uIHdpdGggDQo+PiB0aGlzIHRocmVlLW9wZXJhdG9y
IGNhc2UuLi4gDQo+Pg0KPg0KPiBJdCdzIHN0aWxsIGEgMiBvcGVyYXRvciBjYXNlLiBUaGUgKysg
aXMgZXZhbHVhdGVkIGJlZm9yZSB0aGUgYCpgIGFuZCB0aGUgDQo+IGA9YC4gSXQncyBubyBkaWZm
ZXJlbnQgZnJvbSBgKnNvbWVfZnVuYygpID0gZm9vO2AsIG9yIGBzb21lX2Z1bmMoKVsxMF0gPSAN
Cj4gZm9vO2AuIEl0J3MgYWxsIGFib3V0IHJlY29nbml6aW5nIHRoZSBzZXF1ZW5jZSBvZiBldmFs
dWF0aW5nIGEgbGVmdC1oYW5kIA0KPiBgKmAgb3IgYFtdYCBmb2xsb3dlZCBieSBhbiBgPWAgZXZh
bHVhdGlvbi4NCj4NCg0KU29ycnksIEkgbWlzdW5kZXJzdG9vZCB5b3UuIEkgdGhvdWdodCB0aGVy
ZSBpcyBhIG5lZWQgaW4gb3ZlcnJpZGluZyANCmJlaGF2aW9yIGZvciBgKml0KysgPSBmb287YCAo
dHVybmluZyB0aHJlZSBvcHMgaW50byBhIHNpbmdsZSBmdW5jdGlvbiBjYWxsKSANCmNhc2UgdG9v
Lg0KDQpBzLZizLZvzLZ1zLZ0zLYgzLZzzLZ5zLZuzLZ0zLZhzLZ4zLYszLYgzLZhzLZuzLZvzLZ0
zLZozLZlzLZyzLYgzLZpzLZkzLZlzLZhzLYgzLZjzLZvzLZtzLZlzLYgzLZ0zLZvzLYgzLZtzLZ5
zLYgDQrMtm3MtmnMtm7MtmTMtjrMtiDMtnfMtmXMtiDMtmPMtmHMtm7MtiDMtmnMtm7MtnTMtnLM
tm/MtmTMtnXMtmPMtmXMtiDMtm7MtmXMtnfMtiANCsy2Y8y2b8y2bsy2dMy2Zcy2eMy2dMy2Lcy2
c8y2Zcy2bsy2c8y2acy2dMy2acy2dsy2Zcy2IMy2a8y2Zcy2ecy2d8y2b8y2csy2ZMy2IMy2YMy2
Ycy2Y8y2Y8y2Zcy2c8y2c8y2YMy2IA0KzLYozLZvzLZyzLYgzLZtzLZhzLZ5zLZizLZlzLYgzLZg
zLZhzLZjzLZjzLZlzLZzzLZzzLZvzLZwzLZgzLYszLYgzLZgzLZhzLZjzLZjzLZlzLZzzLZzzLZv
zLZwzLZlzLZyzLZgzLYszLYgDQrMtmDMtmHMtmPMtmPMtmXMtnPMtnPMtl/Mtm/MtnDMtmXMtnLM
tmHMtnTMtm/MtnLMtmDMtinMtizMtiDMtnPMtm/MtiDMtmnMtm7MtnPMtnTMtmXMtmHMtmTMtiDM
tm/MtmbMtiANCsy2YMy2b8y2cMy2Zcy2csy2Ycy2dMy2b8y2csy2W8y2Xcy2IMy2b8y2cMy2Zcy2
csy2Ycy2dMy2b8y2csy2Pcy2YMy2IMy2acy2dMy2IMy2d8y2acy2bMy2bMy2IMy2Ysy2Zcy2IA0K
zLZgzLZvzLZwzLZlzLZyzLZhzLZ0zLZvzLZyzLY9zLYgzLZhzLZjzLZjzLZlzLZzzLZzzLZbzLZd
zLZgzLYuzLYgzLZIzLZtzLYszLYgzLZvzLZyzLYgzLZ0zLZozLZlzLYgDQrMtmvMtmXMtnnMtnfM
tm/MtnLMtmTMtiDMtmPMtmHMtm7MtiDMtmLMtmXMtiDMtmDMtmHMtnPMtnPMtmnMtmfMtm7Mtm3M
tmXMtm7MtnTMtmDMtiDMtmHMtm7MtmTMtiDMtnTMtmjMtmXMtiANCsy2bsy2Ycy2bcy2Zcy2IMy2
b8y2Zsy2IMy2b8y2cMy2Zcy2csy2Ycy2dMy2b8y2csy2IMy2d8y2acy2bMy2bMy2IMy2Ysy2Zcy2
IMy2YMy2b8y2cMy2Zcy2csy2Ycy2dMy2b8y2csy2W8y2Xcy2IA0KzLZhzLZzzLZzzLZpzLZnzLZu
zLZtzLZlzLZuzLZ0zLY9zLZgzLYuzLYgzLZPzLZyzLYgzLZtzLZhzLZ5zLZizLZlzLYgzLZlzLZ2
zLZlzLZuzLYgzLZgzLZvzLZwzLZlzLZyzLZhzLZ0zLZvzLZyzLYgDQrMtmHMtmPMtmPMtmXMtnPM
tnPMtl/Mtm/MtnDMtmXMtnLMtmHMtnTMtm/MtnLMtlvMtl3MtiANCsy2Ycy2c8y2c8y2acy2Z8y2
bsy2bcy2Zcy2bsy2dMy2X8y2b8y2cMy2Zcy2csy2Ycy2dMy2b8y2csy2Pcy2YMy2IMy2KMy2aMy2
b8y2d8y2Zcy2dsy2Zcy2csy2IMy2K8y2K8y2IMy2Ycy2bsy2ZMy2IA0KzLYtzLYtzLYgzLZkzLZv
zLZuzLYnzLZ0zLYgzLZmzLZpzLZ0zLYgzLZnzLZvzLZvzLZkzLYgzLZ3zLZpzLZ0zLZozLYgDQrM
tmDMtmHMtnPMtnPMtmnMtmfMtm7Mtm3MtmXMtm7MtnTMtl/Mtm/MtnDMtmXMtnLMtmHMtnTMtm/M
tnLMtmDMtiDMtnDMtmjMtnLMtmHMtnPMtmXMtinMti7Mtg0KDQpPbiBTdW5kYXksIDE3LjAzLjIw
MTkg0LMuLCAxNjoyNzowNCBVVEMrMyBWaW5uaWUgRmFsY28gd3JvdGU6DQo+DQo+DQo+IE9uIEZy
aWRheSwgTWFyY2ggMTUsIDIwMTkgYXQgODozMzoyMCBBTSBVVEMtNywgTmljb2wgQm9sYXMgd3Jv
dGU6DQo+Pg0KPj4gRXNwZWNpYWxseSBzaW5jZSB0aGUgb2J2aW91cyBgb3BlcmF0b3IqPWAgaXMg
YWxyZWFkeSB0YWtlbiA7KQ0KPj4NCj4NCj4gQSBzdHJhaWdodGZvcndhcmQgc29sdXRpb24gaXMg
dG8gaW50cm9kdWNlIGEgc3RkIHRhZyB0eXBlOg0KPg0KPg0KPiAgICAgVCYgb3BlcmF0b3IqPShz
dGQ6Om9wX2Fzc2lnbl9lcXVhbCwgLi4uKTsNCj4NCj4gUmVnYXJkcw0KPiBWaW5uaWUNCj4NCg0K
VGhhdCBpcyBhIG5pY2UgaWRlYS4gVGhvdWdoIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHVzZWQgYW5v
dGhlciB3YXksIHNvIG5vIA0KYW55IG5ldyBzeW50YXggbGlrZSBgb3BlcmF0b3JbXT1gIGlzIGlu
dHJvZHVjZWQ6DQovLyAqYSA9IHg7DQpUJiBvcGVyYXRvciooc3RkOjpvcF9zaW1wbGVfYXNzaWdu
bWVudF90LCAuLi4pIHsgLyogLi4uICovIH0NCg0KLy8gYVtrXSA9IHY7DQpUJiBvcGVyYXRvcltd
KHN0ZDo6b3Bfc2ltcGxlX2Fzc2lnbm1lbnRfdCwgLi4uKSB7IC8qIC4uLiAqLyB9DQoNCi8vIGFb
aV0rKzsNClQgb3BlcmF0b3JbXShzdGQ6Om9wX3Bvc3RfaW5jcmVtZW50X3QsIC4uLikgeyAvKiAu
Li4gKi8gfQ0KDQovLyBhW2ldIHw9IHg7DQpUJiBvcGVyYXRvcltdKHN0ZDo6b3BfYml0d2lzZV9v
cl9hc3NpZ25tZW50X3QsIC4uLikgeyAvKiAuLi4gKi8gfQ0KDQpPbiBTdW5kYXksIDE3LjAzLjIw
MTkg0LMuLCAxMjo0MjoyNyBVVEMrMyBGYXJpZCBNZWhyYWJpIHdyb3RlOg0KPg0KPiBFdmVuIG1v
cmUgZ2VuZXJhbCBjb3VsZCBiZSB0byBvdmVybG9hZCBhIGNvbXBsZXggZXhwcmVzc2lvbiB3aGlj
aCAgaXMgDQo+IGN1cnJlbnRseSBvbmx5IHBvc3NpYmxlIHZpYSBleHByZXNzaW9uIHRlbXBsYXRl
cyBhbmQgbGF6eSBldmFsdWF0aW9uIA0KPiB0ZWNobmljcy4gT25lIG1pZ2h0IHRyeSB0byB1c2Ug
b3BlcmF0b3Igb3ZlcmxvYWRpbmcgaW4gYSBtYXRyaXggY2FjdWxhdGlvbiANCj4gbGlicmFyeToN
Cj4NCj4gbWF0cml4IGEsYixjLGQ7DQo+IC8vLi4uDQo+IGE9YitjKmQ7Ly8gY2FuIEkgb3Zlcmxv
YWQgdGhpcyB0b28/DQo+DQo+IHJlZ2FyZHMsDQo+IEZNDQo+DQoNCkkgdGhpbmsgaXQgaXMgbm90
IGZvciB0aGlzIHByb3Bvc2FsLiBUaGlzIHByb3Bvc2FsIHNob3VsZCBjb3ZlciBvbmx5IHNpbXBs
ZSANCmFjY2Vzcy1hbmQtbW9kaWZ5IG9wZXJhdGlvbnMgZm9yIGNvbnRhaW5lcnMgYW5kIGl0ZXJh
dG9ycyBhcyBmb3IgbWUuIEkgd2FudCANCnRvIGxlYXZlIHRoZSBwcm9wb3NlZCBpZGVhIGFzIHNp
bXBsZSBhcyBpdCBjYW4gYmUsIGJ1dCBvZiBjb3Vyc2Ugd2l0aG91dCANCmJyZWFraW5nIGZvcndh
cmQgY29tcGF0aWJpbGl0eSBmb3IgdGhlIHBvc3NpYmxlIG1vcmUgY29tcGxleCBjb21wb3NpdGUg
DQpvcGVyYXRvcnMgcHJvcG9zYWwgaW4gdGhlIGZ1dHVyZS4NCg0KDQoNCkFsc28gSSByZWFsaXpl
ZCB0aGF0IHRoZSBwcm9wb3NlZCBmZWF0dXJlIGRvZXNuJ3QgY292ZXIgdGhlIGZ1bGwgDQpmdW5j
dGlvbmFsaXR5IG9mIGBzdGQ6OmJpdHNldGAvYHN0ZDo6dmVjdG9yPGJvb2w+YCByZWZlcmVuY2Ug
cHJveGllcy4gVGhlcmUgDQppcyBgZmxpcGAgbWVtYmVyIGZ1bmN0aW9uIGluIGJvb2wgKGJpdCkg
cmVmZXJlbmNlIHByb3hpZXMsIGluc3RlYWQgd2UgY2FuIA0KZG8gYGJpdHNbaV0gXj0gdHJ1ZTtg
LCBidXQgYGJpdHNbaV0uZmxpcCgpO2AgbG9va3MgbW9yZSByZWFkYWJsZS4gVGhvdWdoIA0KYGJp
dHNbaV0gPSAhYml0c1tpXTtgIGxvb2tzIHJlYWRhYmxlIHRvbyBob3dldmVyIGl0IGRvZXNuJ3Qg
bG9vayBEUlkuDQoNCi0tIApZb3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGJlY2F1c2UgeW91IGFy
ZSBzdWJzY3JpYmVkIHRvIHRoZSBHb29nbGUgR3JvdXBzICJJU08gQysrIFN0YW5kYXJkIC0gRnV0
dXJlIFByb3Bvc2FscyIgZ3JvdXAuClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBncm91cCBhbmQg
c3RvcCByZWNlaXZpbmcgZW1haWxzIGZyb20gaXQsIHNlbmQgYW4gZW1haWwgdG8gc3RkLXByb3Bv
c2Fscyt1bnN1YnNjcmliZUBpc29jcHAub3JnLgpUbyBwb3N0IHRvIHRoaXMgZ3JvdXAsIHNlbmQg
ZW1haWwgdG8gc3RkLXByb3Bvc2Fsc0Bpc29jcHAub3JnLgpUbyB2aWV3IHRoaXMgZGlzY3Vzc2lv
biBvbiB0aGUgd2ViIHZpc2l0IGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3Jn
L2QvbXNnaWQvc3RkLXByb3Bvc2Fscy83N2NhNmM5MS1lMWQ2LTQ0MTAtODk4ZC1iODgwYjVhZjI3
ZDclNDBpc29jcHAub3JnLgo=
------=_Part_1281_1670503988.1552864108608
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, 16.03.2019 =D0=B3., 16:37:33 UTC+3 Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sa=
turday, March 16, 2019 at 3:48:50 AM UTC-4, <a>wpmgpro...@gmail.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><div>and `*it++ =3D foo;`</d=
iv></div></div></blockquote><div><br></div><div>I totally missed it. It is =
really hard to find a general solution with this three-operator case... <br=
></div></div></blockquote><div><br></div><div>It&#39;s
 still a 2 operator case. The ++ is evaluated before the `*` and the=20
`=3D`. It&#39;s no different from `*some_func() =3D foo;`, or `some_func()[=
10] =3D
 foo;`. It&#39;s all about recognizing the sequence of evaluating a=20
left-hand `*` or `[]` followed by an `=3D` evaluation.<br></div></div></blo=
ckquote><div><br></div><div><div>Sorry, I misunderstood you. I thought ther=
e is a need in overriding
 behavior for `*it++ =3D foo;` (turning three ops into a single function=20
call) case too.</div><div><br></div><div>A=CC=B6b=CC=B6o=CC=B6u=CC=B6t=CC=
=B6 =CC=B6s=CC=B6y=CC=B6n=CC=B6t=CC=B6a=CC=B6x=CC=B6,=CC=B6=20
=CC=B6a=CC=B6n=CC=B6o=CC=B6t=CC=B6h=CC=B6e=CC=B6r=CC=B6 =CC=B6i=CC=B6d=CC=
=B6e=CC=B6a=CC=B6 =CC=B6c=CC=B6o=CC=B6m=CC=B6e=CC=B6 =CC=B6t=CC=B6o=CC=B6 =
=CC=B6m=CC=B6y=CC=B6 =CC=B6m=CC=B6i=CC=B6n=CC=B6d=CC=B6:=CC=B6 =CC=B6w=CC=
=B6e=CC=B6=20
=CC=B6c=CC=B6a=CC=B6n=CC=B6 =CC=B6i=CC=B6n=CC=B6t=CC=B6r=CC=B6o=CC=B6d=CC=
=B6u=CC=B6c=CC=B6e=CC=B6 =CC=B6n=CC=B6e=CC=B6w=CC=B6 =CC=B6c=CC=B6o=CC=B6n=
=CC=B6t=CC=B6e=CC=B6x=CC=B6t=CC=B6-=CC=B6s=CC=B6e=CC=B6n=CC=B6s=CC=B6i=CC=
=B6t=CC=B6i=CC=B6v=CC=B6e=CC=B6=20
=CC=B6k=CC=B6e=CC=B6y=CC=B6w=CC=B6o=CC=B6r=CC=B6d=CC=B6 =CC=B6`=CC=B6a=CC=
=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=CC=B6`=CC=B6 =CC=B6(=CC=B6o=CC=B6r=CC=B6 =
=CC=B6m=CC=B6a=CC=B6y=CC=B6b=CC=B6e=CC=B6=20
=CC=B6`=CC=B6a=CC=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=CC=B6o=CC=B6p=CC=B6`=CC=
=B6,=CC=B6 =CC=B6`=CC=B6a=CC=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=CC=B6o=CC=B6p=
=CC=B6e=CC=B6r=CC=B6`=CC=B6,=CC=B6=20
=CC=B6`=CC=B6a=CC=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=CC=B6_=CC=B6o=CC=B6p=CC=
=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6`=CC=B6)=CC=B6,=CC=B6 =CC=B6s=
=CC=B6o=CC=B6 =CC=B6i=CC=B6n=CC=B6s=CC=B6t=CC=B6e=CC=B6a=CC=B6d=CC=B6 =CC=
=B6o=CC=B6f=CC=B6=20
=CC=B6`=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6[=CC=
=B6]=CC=B6 =CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6=
=3D=CC=B6`=CC=B6 =CC=B6i=CC=B6t=CC=B6 =CC=B6w=CC=B6i=CC=B6l=CC=B6l=CC=B6 =
=CC=B6b=CC=B6e=CC=B6=20
=CC=B6`=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6=3D=CC=
=B6 =CC=B6a=CC=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=CC=B6[=CC=B6]=CC=B6`=CC=B6.=
=CC=B6 =CC=B6H=CC=B6m=CC=B6,=CC=B6 =CC=B6o=CC=B6r=CC=B6 =CC=B6t=CC=B6h=CC=
=B6e=CC=B6=20
=CC=B6k=CC=B6e=CC=B6y=CC=B6w=CC=B6o=CC=B6r=CC=B6d=CC=B6 =CC=B6c=CC=B6a=CC=
=B6n=CC=B6 =CC=B6b=CC=B6e=CC=B6 =CC=B6`=CC=B6a=CC=B6s=CC=B6s=CC=B6i=CC=B6g=
=CC=B6n=CC=B6m=CC=B6e=CC=B6n=CC=B6t=CC=B6`=CC=B6 =CC=B6a=CC=B6n=CC=B6d=CC=
=B6 =CC=B6t=CC=B6h=CC=B6e=CC=B6=20
=CC=B6n=CC=B6a=CC=B6m=CC=B6e=CC=B6 =CC=B6o=CC=B6f=CC=B6 =CC=B6o=CC=B6p=CC=
=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6 =CC=B6w=CC=B6i=CC=B6l=CC=B6l=
=CC=B6 =CC=B6b=CC=B6e=CC=B6=20
=CC=B6`=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6[=CC=
=B6]=CC=B6 =CC=B6a=CC=B6s=CC=B6s=CC=B6i=CC=B6g=CC=B6n=CC=B6m=CC=B6e=CC=B6n=
=CC=B6t=CC=B6=3D=CC=B6`=CC=B6.=CC=B6 =CC=B6O=CC=B6r=CC=B6 =CC=B6m=CC=B6a=CC=
=B6y=CC=B6b=CC=B6e=CC=B6=20
=CC=B6e=CC=B6v=CC=B6e=CC=B6n=CC=B6 =CC=B6`=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=
=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6 =CC=B6a=CC=B6c=CC=B6c=CC=B6e=CC=B6s=CC=B6s=
=CC=B6_=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6[=CC=
=B6]=CC=B6=20
=CC=B6a=CC=B6s=CC=B6s=CC=B6i=CC=B6g=CC=B6n=CC=B6m=CC=B6e=CC=B6n=CC=B6t=CC=
=B6_=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6=3D=CC=B6=
`=CC=B6 =CC=B6(=CC=B6h=CC=B6o=CC=B6w=CC=B6e=CC=B6v=CC=B6e=CC=B6r=CC=B6 =CC=
=B6+=CC=B6+=CC=B6=20
=CC=B6a=CC=B6n=CC=B6d=CC=B6 =CC=B6-=CC=B6-=CC=B6 =CC=B6d=CC=B6o=CC=B6n=CC=
=B6&#39;=CC=B6t=CC=B6 =CC=B6f=CC=B6i=CC=B6t=CC=B6 =CC=B6g=CC=B6o=CC=B6o=CC=
=B6d=CC=B6 =CC=B6w=CC=B6i=CC=B6t=CC=B6h=CC=B6=20
=CC=B6`=CC=B6a=CC=B6s=CC=B6s=CC=B6i=CC=B6g=CC=B6n=CC=B6m=CC=B6e=CC=B6n=CC=
=B6t=CC=B6_=CC=B6o=CC=B6p=CC=B6e=CC=B6r=CC=B6a=CC=B6t=CC=B6o=CC=B6r=CC=B6`=
=CC=B6 =CC=B6p=CC=B6h=CC=B6r=CC=B6a=CC=B6s=CC=B6e=CC=B6)=CC=B6.=CC=B6</div>=
<div><br></div></div>On Sunday, 17.03.2019 =D0=B3., 16:27:04 UTC+3 Vinnie F=
alco wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
r>On Friday, March 15, 2019 at 8:33:20 AM UTC-7, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Especially since=
 the obvious `operator*=3D` is already taken ;)</div></div></div></blockquo=
te><div><br></div><div>A straightforward solution is to introduce a std tag=
 type:</div><div><br></div><div><br></div><div>=C2=A0 =C2=A0 T&amp; operato=
r*=3D(std::op_assign_<wbr>equal, ...);<br><br>Regards<br>Vinnie<br></div></=
div></blockquote><div><br></div><div>That is a nice idea. Though I think it=
 should be used another way, so no any new syntax like `operator[]=3D` is i=
ntroduced:</div><div style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow=
-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// *a =3D x;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">op_simple_assignment_t</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">...)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">/* ... */</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// a[k] =3D v;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">op_simple_assignment_t</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">/* ... */</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// a[i]++;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>T </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[](</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">op_post_increment_t</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// a[i] |=3D x;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">operator</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">[](</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">op_bitwise_or_assig=
nment_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span></div></code></div><div><div><br></div>On Sunday, 17.03.=
2019 =D0=B3., 12:42:27 UTC+3 Farid Mehrabi wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">Even
 more general could be to overload a complex expression which =C2=A0is=20
currently only possible via expression templates and lazy evaluation=20
technics. One might try to use operator overloading in a matrix=20
caculation library:<p>matrix a,b,c,d;<br>//...<br>a=3Db+c*d;// can I overlo=
ad this too?</p><p>regards,<br>FM<br></p></blockquote><div><br></div><div>I
 think it is not for this proposal. This proposal should cover only=20
simple access-and-modify operations for containers and iterators as for=20
me. I want to leave the proposed idea as simple as it can be, but of=20
course without breaking forward compatibility for the possible more complex=
 composite operators proposal in the future.<br></div><div><div><br></div><=
div><br></div><div><br></div>Also I realized that the proposed feature does=
n&#39;t cover the full functionality of `std::bitset`/`std::vector&lt;bool&=
gt;`
 reference proxies. There is `flip` member function in bool (bit)=20
reference proxies, instead we can do `bits[i] ^=3D true;`, but=20
`bits[i].flip();` looks more readable. Though `bits[i] =3D !bits[i];`=20
looks readable too however it doesn&#39;t look DRY.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/77ca6c91-e1d6-4410-898d-b880b5af27d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77ca6c91-e1d6-4410-898d-b880b5af27d7=
%40isocpp.org</a>.<br />

------=_Part_1281_1670503988.1552864108608--

------=_Part_1280_1662110632.1552864108608--

.

------=_Part_963_156250339.1553295306461
Content-Type: multipart/alternative;
 boundary="----=_Part_964_292684238.1553295306462"

------=_Part_964_292684238.1553295306462
Content-Type: text/plain; charset="UTF-8"

We might also want to have `operator[](std::op_sizeof_t, ...)` for the
`std::bitset`/`std::vector<bool>` case to prohibit using
`sizeof(operator[expr])`. Just like we cannot use `sizeof` on bit-fields.
The same for `operator*` in `std::bitset`/`std::vector<bool>` iterators
case.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6bcff143-b821-4086-a8e1-5fa340925ea2%40isocpp.org.

------=_Part_964_292684238.1553295306462
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We might also want to have `operator[](std::op_sizeof_t, .=
...)` for the `std::bitset`/`std::vector&lt;bool&gt;`
 case to prohibit using `sizeof(operator[expr])`. Just like we cannot=20
use `sizeof` on bit-fields. The same for `operator*` in=20
`std::bitset`/`std::vector&lt;bool&gt;` iterators case.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6bcff143-b821-4086-a8e1-5fa340925ea2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bcff143-b821-4086-a8e1-5fa340925ea2=
%40isocpp.org</a>.<br />

------=_Part_964_292684238.1553295306462--

------=_Part_963_156250339.1553295306461--

.