------=_Part_14525_1452914873.1526702573704
Content-Type: text/plain; charset="UTF-8"

Hi

The container's view on which the range based for loop is iterating should be marked as const within the body of the loop, This is to avoid concurrent updation of the container which can lead to undefined behaviour.

E.g.

 for(const auto current: container)
 {
    container.emplace_back(10); // Or Any opration which can invalidate iterator
 }

This can be captured at compile time if container is treated as const within for loop's body.

Other languages like java and c# raises exception when container is updated within body of a loop and this kind of checking might be expensive.

So proposal here is to treat container as const within body of range based for to avoid updating container within for loop.

Comments and suggestions welcome.

Thanks
Husen Jiruwala

--
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/5c468d1a-c3d1-4aee-909b-3d72cd821611%40isocpp.org.

------=_Part_14525_1452914873.1526702573704--

.

--00000000000031bb9c056c8af35e
Content-Type: text/plain; charset="UTF-8"

The problem I have with this is that there is no way to opt out. What if my
container has a updateAll function that increments every value of the
container? This wouldn't invalidate any iterator, but would still mutate
the container and thus updateAll cannot be const. With your change, I
wouldn't be able to call that function.

Also, the type of an object doesn't change. If it's not const when it was
declared, then it isn't. Nothing's ever going to make it const. C++ is type
safe, it shouldn't be possible to change types of objects, even if that
means just adding a single top-level const. With your change you are
proposing that this would be possible (there is no "view" of the container,
there is only the object which is always the same, inside and outside of
the loop).

I think the best way to avoid this type of errors is to use a static
analyzer.

On Sat, May 19, 2018 at 6:02 AM husain jiruwala <husain.255@gmail.com>
wrote:

> Hi
>
> The container's view on which the range based for loop is iterating should
> be marked as const within the body of the loop, This is to avoid concurrent
> updation of the container which can lead to undefined behaviour.
>
> E.g.
>
>  for(const auto current: container)
>  {
>     container.emplace_back(10); // Or Any opration which can invalidate
> iterator
>  }
>
> This can be captured at compile time if container is treated as const
> within for loop's body.
>
> Other languages like java and c# raises exception when container is
> updated within body of a loop and this kind of checking might be expensive.
>
> So proposal here is to treat container as const within body of range based
> for to avoid updating container within for loop.
>
> Comments and suggestions welcome.
>
> Thanks
> Husen Jiruwala
>
> --
> 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/5c468d1a-c3d1-4aee-909b-3d72cd821611%40isocpp.org
> .
>

--
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/CALmDwq0tzAHYQW7K5P%2BB3om9s0bcqMJfMTJYO21dsJVh3hUeNQ%40mail.gmail.com.

--00000000000031bb9c056c8af35e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The problem I have with this is that there is no way to op=
t out. What if my container has a updateAll function that increments every =
value of the container? This wouldn&#39;t invalidate any iterator, but woul=
d still mutate the container and thus updateAll cannot be const. With your =
change, I wouldn&#39;t be able to call that function.<div><br></div><div>Al=
so, the type of an object doesn&#39;t change. If it&#39;s not const when it=
 was declared, then it isn&#39;t. Nothing&#39;s ever going to make it const=
.. C++ is type safe, it shouldn&#39;t be possible to change types of objects=
, even if that means just adding a single top-level const. With your change=
 you are proposing that this would be possible (there is no &quot;view&quot=
; of the container, there is only the object which is always the same, insi=
de and outside of the loop).</div><div><br></div><div>I think the best way =
to avoid this type of errors is to use a static analyzer.</div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Sat, May 19, 2018 at 6:02 AM h=
usain jiruwala &lt;<a href=3D"mailto:husain.255@gmail.com">husain.255@gmail=
..com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
The container&#39;s view on which the range based for loop is iterating sho=
uld be marked as const within the body of the loop, This is to avoid concur=
rent updation of the container which can lead to undefined behaviour.<br>
<br>
E.g.<br>
<br>
=C2=A0for(const auto current: container)<br>
=C2=A0{<br>
=C2=A0 =C2=A0 container.emplace_back(10); // Or Any opration which can inva=
lidate iterator<br>
=C2=A0}<br>
<br>
This can be captured at compile time if container is treated as const withi=
n for loop&#39;s body. <br>
<br>
Other languages like java and c# raises exception when container is updated=
 within body of a loop and this kind of checking might be expensive. <br>
<br>
So proposal here is to treat container as const within body of range based =
for to avoid updating container within for loop. <br>
<br>
Comments and suggestions welcome. <br>
<br>
Thanks<br>
Husen Jiruwala<br>
<br>
-- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/5c468d1a-c3d1-4aee-909b-3d72cd821611%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/5c468d1a-c3d1-4aee-909b-3d72cd821611%4=
0isocpp.org</a>.<br>
</blockquote></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/CALmDwq0tzAHYQW7K5P%2BB3om9s0bcqMJfMT=
JYO21dsJVh3hUeNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0tzAHYQW=
7K5P%2BB3om9s0bcqMJfMTJYO21dsJVh3hUeNQ%40mail.gmail.com</a>.<br />

--00000000000031bb9c056c8af35e--

.

------=_Part_15706_1877265778.1526719936068
Content-Type: text/plain; charset="UTF-8"

Hi

I dont think updateAll can't be const, its not changing the logical state of the container. Data within the container can of course  change  but not the internal observable state of the container within the loop.

Also about your second concern the range based for loop is just an abstraction it anyway get expanded to normal loop within compiler.

And in that expansion you can always use const view of that  container.

E.g.

vector<int> v;

const auto ctv=v;

Now ctv is constant view of v.

Thanks
Husen Jiruwala

--
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/95ea4962-759d-40ba-a3ce-2d6c3eec7792%40isocpp.org.

------=_Part_15706_1877265778.1526719936068--

.

--000000000000369801056c8b4ba8
Content-Type: text/plain; charset="UTF-8"

On Sat, May 19, 2018 at 10:52 AM husain jiruwala <husain.255@gmail.com>
wrote:

> Hi
>
> I dont think updateAll can't be const, its not changing the logical state
> of the container. Data within the container can of course  change  but not
> the internal observable state of the container within the loop.
>
Ooh, that's true. That was a bad example, sorry. What about:

for  (auto &elem : container) {
    container[0] = 1; // nope, container is const
    elem = 1; // nope, container is const
}

I can't modify any element of the container, because the (new) container is
const.


>
> Also about your second concern the range based for loop is just an
> abstraction it anyway get expanded to normal loop within compiler.
>
> And in that expansion you can always use const view of that  container.
>
> E.g.
>
> vector<int> v;
>
> const auto ctv=v;
>
> Now ctv is constant view of v.
>
Well yes, but then you have to give it another name. Or you'll need to
shadow it, which might be confusing I guess and it conflicts as said above.

>
> Thanks
> Husen Jiruwala
>

--
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/CALmDwq3y3HrQuckrN9VuW%2BzaRCGUN82csyUYuXQeptJy2Fxs1w%40mail.gmail.com.

--000000000000369801056c8b4ba8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, May 19=
, 2018 at 10:52 AM husain jiruwala &lt;<a href=3D"mailto:husain.255@gmail.c=
om">husain.255@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">Hi<br>
<br>
I dont think updateAll can&#39;t be const, its not changing the logical sta=
te of the container. Data within the container can of course=C2=A0 change=
=C2=A0 but not the internal observable state of the container within the lo=
op.<br></blockquote><div>Ooh, that&#39;s true. That was a bad example, sorr=
y. What about:</div><div><br></div><div>for=C2=A0 (auto &amp;elem : contain=
er) {</div><div>=C2=A0 =C2=A0 container[0] =3D 1; // nope, container is con=
st</div><div>=C2=A0 =C2=A0 elem =3D 1; // nope, container is const</div><di=
v>}</div><div><br></div><div>I can&#39;t modify any element of the containe=
r, because the (new) container is const.</div><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<br>
Also about your second concern the range based for loop is just an abstract=
ion it anyway get expanded to normal loop within compiler. <br>
<br>
And in that expansion you can always use const view of that=C2=A0 container=
.. <br>
<br>
E.g.<br>
<br>
vector&lt;int&gt; v;<br>
<br>
const auto ctv=3Dv;<br>
<br>
Now ctv is constant view of v. <br></blockquote><div>Well yes, but then you=
 have to give it another name. Or you&#39;ll need to shadow it, which might=
 be confusing I guess and it conflicts as said above.=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
<br>
Thanks<br>
Husen Jiruwala<br>
</blockquote></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/CALmDwq3y3HrQuckrN9VuW%2BzaRCGUN82csy=
UYuXQeptJy2Fxs1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3y3HrQuc=
krN9VuW%2BzaRCGUN82csyUYuXQeptJy2Fxs1w%40mail.gmail.com</a>.<br />

--000000000000369801056c8b4ba8--

.

On 05/19/18 11:52, husain jiruwala wrote:
> Hi
>
> I dont think updateAll can't be const, its not changing the logical state of the container. Data within the container can of course  change  but not the internal observable state of the container within the loop.

The traditional convention is to treat element values as part of the
container state. For example, you cannot modify an element of a const
vector - the const qualifier means the vector, including its contents,
is not mutable. Breaking that convention just for the sake of this new
for loop would be counter-intuitive.

--
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/0db75eb7-5a5b-4e54-73f3-2840648515fe%40gmail.com.

.

------=_Part_15626_651846242.1526722369604
Content-Type: text/plain; charset="UTF-8"

Agreed.

Thanks

--
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/b8fe5ad9-aefc-4424-9388-22e0aef3aa8c%40isocpp.org.

------=_Part_15626_651846242.1526722369604--

.

On Saturday, 19 May 2018 01:59:03 PDT Nicolas Lesser wrote:
> Well yes, but then you have to give it another name. Or you'll need to
> shadow it, which might be confusing I guess and it conflicts as said above.

Use std::as_const()

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1651393.t52NUBtgoK%40tjmaciei-mobl1.

.

--0000000000003f6bb4056c959e36
Content-Type: text/plain; charset="UTF-8"

I think it's a good idea, but how to track dependencies?

A naiive first thought suggests:

struct Container
{
  [[invalidates_iterators]]
  template<class...Args> auto emplace_back(Args&&...args)
};

But then how does the compiler track whether a given iterator belongs to a
container (although the for case might be more simple)?

Is this perhaps why other languages use a run-time check?

A runtime check during debug builds might be a reasonable QOI library
feature for containers in which iterator validity has a dependency on
container mutation.




On Sat, 19 May 2018 at 17:23, Thiago Macieira <thiago@macieira.org> wrote:

> On Saturday, 19 May 2018 01:59:03 PDT Nicolas Lesser wrote:
> > Well yes, but then you have to give it another name. Or you'll need to
> > shadow it, which might be confusing I guess and it conflicts as said
> above.
>
> Use std::as_const()
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/1651393.t52NUBtgoK%40tjmaciei-mobl1
> .
>

--
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/CALvx3ha4jPTiBRqJ31SsiqXhrjx8tYCthz-BEH9vjNY3eKxLYQ%40mail.gmail.com.

--0000000000003f6bb4056c959e36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think it&#39;s a good idea, but how to track dependencie=
s?<div><br></div><div>A naiive first thought suggests:</div><div><br></div>=
<div>struct Container=C2=A0</div><div>{</div><div>=C2=A0=C2=A0<span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">[[invalidates_iterators]]</span></div><div>=C2=A0 template&lt;class=
....Args&gt; auto emplace_back(Args&amp;&amp;...args)=C2=A0</div><div>};</di=
v><div><br></div><div>But then how does the compiler track whether a given =
iterator belongs to a container (although the for case might be more simple=
)?</div><div><br></div><div>Is this perhaps why other languages use a run-t=
ime check?</div><div><br></div><div>A runtime check during debug builds mig=
ht be a reasonable QOI library feature for containers in which iterator val=
idity has a dependency on container mutation.</div><div><br></div><div><br>=
</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Sat, 19 May 2018 at 17:23, Thiago Macieira &lt;<a href=3D"mailto:thiago@=
macieira.org">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Saturday, 19 May 2018 01:59:03 PDT Nicolas Lesser wrote:<b=
r>
&gt; Well yes, but then you have to give it another name. Or you&#39;ll nee=
d to<br>
&gt; shadow it, which might be confusing I guess and it conflicts as said a=
bove.<br>
<br>
Use std::as_const()<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/1651393.t52NUBtgoK%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/1651393.t52NUBtgoK%40tjmaciei-mobl1</a>.<br>
</blockquote></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/CALvx3ha4jPTiBRqJ31SsiqXhrjx8tYCthz-B=
EH9vjNY3eKxLYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha4jPTiBRqJ=
31SsiqXhrjx8tYCthz-BEH9vjNY3eKxLYQ%40mail.gmail.com</a>.<br />

--0000000000003f6bb4056c959e36--

.