--001a11c382d0d318a70515f8e820
Content-Type: text/plain; charset=UTF-8

I am not really fond of the idea, but if you want to play with it, you
could try adding an attribute to your favorite compiler:

[[modifies-only: a_, b_]]
void f();

And have the compiler diagnose violations with either a warning or
optionally an error as a QoI.  I believe this is a more sensible approach
to the problem, even if I don't quite buy into the premise. I have had to
maintain complicated code, and while it is not always the case that you
can, I recommend working on cleaning up the code rather than trying to
"document" this with enforcement.

Note that whenever the next guy attempts to modify something else they
won't stop because it is not in the list of modifiable members, but rather
will add another element there... complexity does not shrink because you
describe it, it only shrinks if you put an effort to clean it up.

    David

On Wed, May 13, 2015 at 3:38 PM, <mash.boyko2014@gmail.com> wrote:

> Would it be part of the function interface if the data was public instead
> of private?
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c382d0d318a70515f8e820
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am not really fond of the idea, but if you want to play =
with it, you could try adding an attribute to your favorite compiler:<br><b=
r>[[modifies-only: a_, b_]]<br>void f();<br><br>And have the compiler diagn=
ose violations with either a warning or optionally an error as a QoI.=C2=A0=
 I believe this is a more sensible approach to the problem, even if I don&#=
39;t quite buy into the premise. I have had to maintain complicated code, a=
nd while it is not always the case that you can, I recommend working on cle=
aning up the code rather than trying to &quot;document&quot; this with enfo=
rcement.<br><br>Note that whenever the next guy attempts to modify somethin=
g else they won&#39;t stop because it is not in the list of modifiable memb=
ers, but rather will add another element there... complexity does not shrin=
k because you describe it, it only shrinks if you put an effort to clean it=
 up.<br><br>=C2=A0 =C2=A0 David</div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Wed, May 13, 2015 at 3:38 PM,  <span dir=3D"ltr">&lt=
;<a href=3D"mailto:mash.boyko2014@gmail.com" target=3D"_blank">mash.boyko20=
14@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Would it be part of the function interface if the data was publi=
c instead of private?</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <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+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c382d0d318a70515f8e820--

.

There is, of course, the inverse idea=E2=80=94explicitly indicate which
members are const.

class Foo {
  int i_will_change;
  int i_will_not;
public:
  void bar() const(i_will_not);
};


On 5/13/15, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote:
> I am not really fond of the idea, but if you want to play with it, you
> could try adding an attribute to your favorite compiler:
>
> [[modifies-only: a_, b_]]
> void f();
>
> And have the compiler diagnose violations with either a warning or
> optionally an error as a QoI.  I believe this is a more sensible approach
> to the problem, even if I don't quite buy into the premise. I have had to
> maintain complicated code, and while it is not always the case that you
> can, I recommend working on cleaning up the code rather than trying to
> "document" this with enforcement.
>
> Note that whenever the next guy attempts to modify something else they
> won't stop because it is not in the list of modifiable members, but rathe=
r
> will add another element there... complexity does not shrink because you
> describe it, it only shrinks if you put an effort to clean it up.
>
>     David
>
> On Wed, May 13, 2015 at 3:38 PM, <mash.boyko2014@gmail.com> wrote:
>
>> Would it be part of the function interface if the data was public instea=
d
>> of private?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.