------=_Part_273_90046538.1482150540036
Content-Type: multipart/alternative;
 boundary="----=_Part_274_190085060.1482150540036"

------=_Part_274_190085060.1482150540036
Content-Type: text/plain; charset=UTF-8

I am wondering whether it would make sense to add a mut keyword opposite of
const.
My personal reasoning would be:

   1. personally I am tired of writing const nearly everwhere, when it
   seems what I mostly want is const as default.
   2. introducing in 2020 would allow us to write new code using mut to
   explicitly state that we want mutability. There would be no change in
   behavior.
   3. would allow for additional Core Guideline analysis.
   4. mut could perhaps be synonym to mutable.
   5. I would not use mutable because it simply is too long to write.
   6. finally in 2023 there could be a way of forcing code (maybe only
   certain namespaces) to be const by default and mutable when explicitly
   stated.

Sorry if this has previously been discussed / disregarded but could not yet
find 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/c230823e-4d28-4225-9bbc-abe49eb6dadb%40isocpp.org.

------=_Part_274_190085060.1482150540036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am wondering whether it would make sense to add a <font =
face=3D"courier new, monospace">mut</font> keyword opposite of <font face=
=3D"courier new, monospace">const</font>.<div>My personal reasoning would b=
e:</div><div><ol><li>personally I am tired of writing <font face=3D"courier=
 new, monospace">const</font> nearly everwhere, when it seems what I mostly=
 want is <font face=3D"courier new, monospace">const</font> as default.</li=
><li>introducing in 2020 would allow us to write new code using <font face=
=3D"courier new, monospace">mut</font> to explicitly state that we want mut=
ability. There would be no change in behavior.<br></li><li>would allow for =
additional Core Guideline analysis.</li><li><font face=3D"courier new, mono=
space">mut</font> could perhaps be synonym to <font face=3D"courier new, mo=
nospace">mutable</font>.</li><li>I would not use <font face=3D"courier new,=
 monospace">mutable</font> because it simply is too long to write.</li><li>=
finally in 2023 there could be a way of forcing code (maybe only certain na=
mespaces) to be <font face=3D"courier new, monospace">const</font> by defau=
lt and <font face=3D"courier new, monospace">mutable</font> when explicitly=
 stated.</li></ol><div>Sorry if this has previously been discussed / disreg=
arded but could not yet find the discussion.</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/c230823e-4d28-4225-9bbc-abe49eb6dadb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c230823e-4d28-4225-9bbc-abe49eb6dadb=
%40isocpp.org</a>.<br />

------=_Part_274_190085060.1482150540036--

------=_Part_273_90046538.1482150540036--

.

On 19 December 2016 at 14:29,  <lcidfire@gmail.com> wrote:
> I am wondering whether it would make sense to add a mut keyword opposite of
> const.
> My personal reasoning would be:
>
> personally I am tired of writing const nearly everwhere, when it seems what
> I mostly want is const as default.
> introducing in 2020 would allow us to write new code using mut to explicitly
> state that we want mutability. There would be no change in behavior.
> would allow for additional Core Guideline analysis.
> mut could perhaps be synonym to mutable.
> I would not use mutable because it simply is too long to write.
> finally in 2023 there could be a way of forcing code (maybe only certain
> namespaces) to be const by default and mutable when explicitly stated.

Not going to happen, because there's billions of lines of code that
would break if const is made the default.

--
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/CAFk2RUaWFyuC-1VfewNPcQL-6wmviai8yuCYHUwhuYZ7%2B%2BSHJg%40mail.gmail.com.

.

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

Yes, but if you would actually read it, you'd see that default const is
proposed as an eventual and opt-in feature, with the ability to redundantly
specify mut[able] before then just being proposed as a piece of
self-training/preparation.

--
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/CACGiwhE9krE9dcEDz3cHHZoQQq8Hi7PiFq%3D2F1MZv6mg-NhKZQ%40mail.gmail.com.

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

<div dir=3D"ltr">Yes, but if you would actually read it, you&#39;d see that=
 default const is proposed as an eventual and opt-in feature, with the abil=
ity to redundantly specify mut[able] before then just being proposed as a p=
iece of self-training/preparation.<br></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/CACGiwhE9krE9dcEDz3cHHZoQQq8Hi7PiFq%3=
D2F1MZv6mg-NhKZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE9krE9dc=
EDz3cHHZoQQq8Hi7PiFq%3D2F1MZv6mg-NhKZQ%40mail.gmail.com</a>.<br />

--001a1130cf06a3615f0544022017--

.

On 19 December 2016 at 14:33, D. B. <db0451@gmail.com> wrote:
> Yes, but if you would actually read it, you'd see that default const is
> proposed as an eventual and opt-in feature, with the ability to redundantly
> specify mut[able] before then just being proposed as a piece of
> self-training/preparation.


Which part of it is opt-in?

--
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/CAFk2RUaAGi%2B6ZWYUP72KK2JR-sHisna67GMf3H70PGtjOHwPQg%40mail.gmail.com.

.

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

On Mon, Dec 19, 2016 at 12:35 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 19 December 2016 at 14:33, D. B. <db0451@gmail.com> wrote:
> > Yes, but if you would actually read it, you'd see that default const is
> > proposed as an eventual and opt-in feature, with the ability to
> redundantly
> > specify mut[able] before then just being proposed as a piece of
> > self-training/preparation.
>
>
> Which part of it is opt-in?


The below suggests this, or at least that's the impression that I got from
the phrases
"a way of forcing" and particularly "maybe only certain namespaces":

> introducing in 2020 would allow us to write new code using mut to
explicitly
> state that we want mutability. There would be no change in behavior.
> [...]
> finally in 2023 there could be a way of forcing code (maybe only certain
> namespaces) to be const by default and mutable when explicitly stated.

--
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/CACGiwhH_jio26%2BMubzO%3DaN%3DH%3DNXx0BqjD_juUEbz2y9rXY69Gw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 19, 2016 at 12:35 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a ta=
rget=3D"_blank" href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"=
gmail_quote"><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">On 19 Dece=
mber 2016 at 14:33, D. B. &lt;<a href=3D"mailto:db0451@gmail.com">db0451@gm=
ail.com</a>&gt; wrote:<br>
&gt; Yes, but if you would actually read it, you&#39;d see that default con=
st is<br>
&gt; proposed as an eventual and opt-in feature, with the ability to redund=
antly<br>
&gt; specify mut[able] before then just being proposed as a piece of<br>
&gt; self-training/preparation.<br>
<br>
<br>
</div></div>Which part of it is opt-in?</blockquote><div><br></div><div>The=
 below suggests this, or at least that&#39;s the impression that I got from=
 the phrases<br></div><div>&quot;a way of forcing&quot; and particularly &q=
uot;maybe only certain namespaces&quot;:<br><br><span class=3D"gmail-im">&g=
t; introducing in 2020 would allow us to write new code using mut to explic=
itly<br>
&gt; state that we want mutability. There would be no change in behavior.<b=
r>
&gt; [...]<br>
&gt; finally in 2023 there could be a way of forcing code (maybe only certa=
in<br>
&gt; namespaces) to be const by default and mutable when explicitly stated.=
</span> <br></div></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/CACGiwhH_jio26%2BMubzO%3DaN%3DH%3DNXx=
0BqjD_juUEbz2y9rXY69Gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhH_=
jio26%2BMubzO%3DaN%3DH%3DNXx0BqjD_juUEbz2y9rXY69Gw%40mail.gmail.com</a>.<br=
 />

--001a1130cf061cb9a305440233f2--

.

On 19 December 2016 at 14:38, D. B. <db0451@gmail.com> wrote:
>> On 19 December 2016 at 14:33, D. B. <db0451@gmail.com> wrote:
>> > Yes, but if you would actually read it, you'd see that default const is
>> > proposed as an eventual and opt-in feature, with the ability to
>> > redundantly
>> > specify mut[able] before then just being proposed as a piece of
>> > self-training/preparation.
>>
>>
>> Which part of it is opt-in?
> The below suggests this, or at least that's the impression that I got from
> the phrases
> "a way of forcing" and particularly "maybe only certain namespaces":


Good luck with that. This non-proposal will drop dead the second it
enters formal review.

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

.

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

I couldn't care less if it does or doesn't! I just wanted to point out that
it's somewhat more nuanced than you're giving it credit for. Presumably
because you formed a strong opinion at the outset and now won't budge on it.

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

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

<div dir=3D"ltr">I couldn&#39;t care less if it does or doesn&#39;t! I just=
 wanted to point out that it&#39;s somewhat more nuanced than you&#39;re gi=
ving it credit for. Presumably because you formed a strong opinion at the o=
utset and now won&#39;t budge on it.<br></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/CACGiwhHqj2mNiDptaDsSgDFVr5tm_ckUf33u=
FxzBhwNsmjzbwg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHqj2mNiDpt=
aDsSgDFVr5tm_ckUf33uFxzBhwNsmjzbwg%40mail.gmail.com</a>.<br />

--001a1144261240a62b0544023d13--

.

--089e013d1ae0bdcb870544023d0e
Content-Type: text/plain; charset=UTF-8

so that we have mut[mutable] and mutable keyword? I really doubt it's a
good idea. Also reasoning is kind of weak?
As my programs are made of mainly from variables (which are mutable), I do
not want to write mut everywhere next to them and I like const much more.



2016-12-19 13:35 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:

> On 19 December 2016 at 14:33, D. B. <db0451@gmail.com> wrote:
> > Yes, but if you would actually read it, you'd see that default const is
> > proposed as an eventual and opt-in feature, with the ability to
> redundantly
> > specify mut[able] before then just being proposed as a piece of
> > self-training/preparation.
>
>
> Which part of it is opt-in?
>
> --
> 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/CAFk2RUaAGi%2B6ZWYUP72KK2JR-
> sHisna67GMf3H70PGtjOHwPQg%40mail.gmail.com.
>

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

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

<div dir=3D"ltr"><div>so that we have mut[mutable] and mutable keyword? I r=
eally doubt it&#39;s a good idea. Also reasoning is kind of weak?<br></div>=
<div>As my programs are made of mainly from variables (which are mutable), =
I do not want to write mut everywhere next to them and I like const much mo=
re.<br><br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">2016-12-19 13:35 GMT+01:00 Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On 19 December 2016 at 14:33, D. B. &lt;<a href=3D"mailto:db045=
1@gmail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt; Yes, but if you would actually read it, you&#39;d see that default con=
st is<br>
&gt; proposed as an eventual and opt-in feature, with the ability to redund=
antly<br>
&gt; specify mut[able] before then just being proposed as a piece of<br>
&gt; self-training/preparation.<br>
<br>
<br>
</span>Which part of it is opt-in?<br>
<span class=3D""><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">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaAGi%2B6ZWYUP72KK2JR-sH=
isna67GMf3H70PGtjOHwPQg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
CAFk2RUaAGi%<wbr>2B6ZWYUP72KK2JR-<wbr>sHisna67GMf3H70PGtjOHwPQg%<wbr>40mail=
..gmail.com</a>.<br>
</blockquote></div><br></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/CAOkZZiHrrhzVkNbprULUP_g5HRbF1q0MgD_2=
VieG8pR2V_fKng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiHrrhzVkNbp=
rULUP_g5HRbF1q0MgD_2VieG8pR2V_fKng%40mail.gmail.com</a>.<br />

--089e013d1ae0bdcb870544023d0e--

.

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

To clarify, I'm inclined to agree with Ville, and actually like having to
write const. I just didn't instantly see this as a breaking change. But if
it *was* opt-in, I doubt I'd be among those opting.

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

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

<div dir=3D"ltr">To clarify, I&#39;m inclined to agree with Ville, and actu=
ally like having to write const. I just didn&#39;t instantly see this as a =
breaking change. But if it <i>was</i> opt-in, I doubt I&#39;d be among thos=
e opting.<br></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/CACGiwhEnRb5rZxmpzZN5WZ9EuwP3Jqax_Qtj=
qZtn2jkRLMtMfw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEnRb5rZxmp=
zZN5WZ9EuwP3Jqax_QtjqZtn2jkRLMtMfw%40mail.gmail.com</a>.<br />

--001a114ccb68df87b805440241a4--

.

On 19 December 2016 at 14:41, D. B. <db0451@gmail.com> wrote:
> I couldn't care less if it does or doesn't! I just wanted to point out that
> it's somewhat more nuanced than you're giving it credit for. Presumably
> because you formed a strong opinion at the outset and now won't budge on it.


Suggesting that the language rules would be different in certain
namespaces doesn't help. Trying to make
const the default is a complete non-starter, and no amount of begging
and pleading will make me budge on it.

--
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/CAFk2RUZ%2BCtMp3_-qxdJnHT4%2B8r_8APx1AX_z44x05PZjDeKX5g%40mail.gmail.com.

.

------=_Part_163_1994814468.1482206779819
Content-Type: multipart/alternative;
 boundary="----=_Part_164_1624496931.1482206779819"

------=_Part_164_1624496931.1482206779819
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, December 19, 2016 at 4:29:00 AM UTC-8, lcid...@gmail.com wrote:
>
> I am wondering whether it would make sense to add a mut keyword opposite=
=20
> of const.
> My personal reasoning would be:
>
>    1. personally I am tired of writing const nearly everwhere, when it=20
>    seems what I mostly want is const as default.
>    2. introducing in 2020 would allow us to write new code using mut to=
=20
>    explicitly state that we want mutability. There would be no change in=
=20
>    behavior.
>    3. would allow for additional Core Guideline analysis.
>    4. mut could perhaps be synonym to mutable.
>    5. I would not use mutable because it simply is too long to write.
>
> #define mut mutable  // problem solved

Please don't waste anyone's time by proposing synonyms for keywords.

Now, as to whether "mutable" as the opposite of "const" is a good idea...
I'm sympathetic to the idea that every keyword should have an inverse. We=
=20
have both `const` and `mutable` to force constness/nonconstness on data=20
members, for example. We have both `signed` and `unsigned` for integer=20
types. And there have definitely been times and places where I've wished I=
=20
could tag a local variable to say, "Dang it, watch out! This variable can't=
=20
be `const` because it'll be mutated in the loop on line 357!"  Being able=
=20
to tag that variable as `mutable` would be pretty neat.
*But.* Given that mutability is the default in C++ (and as Ville said, that=
=20
won't ever change), the closest analogue I can think of to the `mutable`=20
keyword would be the `auto` keyword in C and C++03. It meant simply "this=
=20
variable is on the stack", and was the inverse of extern/static. Since it=
=20
was the default, basically nobody ever wrote it anywhere: `auto int x;` was=
=20
better written as just `int x;`. The `auto` keyword was *so much* ignored=
=20
by working programmers that it was able to be reclaimed in C++11.
Therefore I would hesitate to introduce any new keyword (or even new place=
=20
for an old keyword, such as `mutable`) whose purpose is just to be the=20
default.  If `auto` is any guide, working programmers will ignore it and=20
then it'll just be dead weight in the standard, ready to be ripped out=20
again in 2023.

If you're really interested in point 3 "would allow for additional Core=20
Guideline analysis", then I recommend starting a new thread or document=20
(maybe here, maybe somewhere else) where you write down exactly what kind=
=20
of static analysis you're hoping for. What new thing could the static=20
analyzer do if it saw "mut" on a variable or parameter? What new thing=20
could it do with variables or parameters that were neither "mut" nor=20
"const"? If it did these things, how would the programmer's life be=20
improved? Once you've got something concrete there, you could try to=20
convince someone to implement "mut" as an attribute or as a template=20
annotation along the lines of owner<T>:

    using mut<T> =3D T;  // analyzer knows that this is a deliberately=20
mutable T

But, as I said, I personally don't know what the static analyzer would *do*=
=20
with the above information if it had it.  Complain if you *didn't* mutate=
=20
the variable? :P  (Some analyzers/front-ends can do this today anyway:=20
"unmodified local variable could be declared const" and so on.)

=E2=80=93Arthur

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/74a5f12f-0bde-4f4f-ac19-7fa3d3126737%40isocpp.or=
g.

------=_Part_164_1624496931.1482206779819
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 19, 2016 at 4:29:00 AM UTC-8, lcid...@=
gmail.com 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"lt=
r">I am wondering whether it would make sense to add a <font face=3D"courie=
r new, monospace">mut</font> keyword opposite of <font face=3D"courier new,=
 monospace">const</font>.<div>My personal reasoning would be:</div><div><ol=
><li>personally I am tired of writing <font face=3D"courier new, monospace"=
>const</font> nearly everwhere, when it seems what I mostly want is <font f=
ace=3D"courier new, monospace">const</font> as default.</li><li>introducing=
 in 2020 would allow us to write new code using <font face=3D"courier new, =
monospace">mut</font> to explicitly state that we want mutability. There wo=
uld be no change in behavior.<br></li><li>would allow for additional Core G=
uideline analysis.</li><li><font face=3D"courier new, monospace">mut</font>=
 could perhaps be synonym to <font face=3D"courier new, monospace">mutable<=
/font>.</li><li>I would not use <font face=3D"courier new, monospace">mutab=
le</font> because it simply is too long to write.</li></ol></div></div></bl=
ockquote><div><font face=3D"courier new, monospace">#define mut mutable =C2=
=A0// problem solved</font></div><div><br></div><div>Please don&#39;t waste=
 anyone&#39;s time by proposing synonyms for keywords.</div><div><br></div>=
<div>Now, as to whether &quot;mutable&quot; as the opposite of &quot;const&=
quot; is a good idea...</div><div>I&#39;m sympathetic to the idea that ever=
y keyword should have an inverse. We have both `const` and `mutable` to for=
ce constness/nonconstness on data members, for example. We have both `signe=
d` and `unsigned` for integer types. And there have definitely been times a=
nd places where I&#39;ve wished I could tag a local variable to say, &quot;=
Dang it, watch out! This variable can&#39;t be `const` because it&#39;ll be=
 mutated in the loop on line 357!&quot; =C2=A0Being able to tag that variab=
le as `mutable` would be pretty neat.</div><div><i><b>But.</b></i> Given th=
at mutability is the default in C++ (and as Ville said, that won&#39;t ever=
 change), the closest analogue I can think of to the `mutable` keyword woul=
d be the `auto` keyword in C and C++03. It meant simply &quot;this variable=
 is on the stack&quot;, and was the inverse of extern/static. Since it was =
the default, basically nobody ever wrote it anywhere: `auto int x;` was bet=
ter written as just `int x;`. The `auto` keyword was <i>so much</i> ignored=
 by working programmers that it was able to be reclaimed in C++11.</div><di=
v>Therefore I would hesitate to introduce any new keyword (or even new plac=
e for an old keyword, such as `mutable`) whose purpose is just to be the de=
fault. =C2=A0If `auto` is any guide, working programmers will ignore it and=
 then it&#39;ll just be dead weight in the standard, ready to be ripped out=
 again in 2023.</div><div><br></div><div>If you&#39;re really interested in=
 point 3 &quot;would allow for additional Core Guideline analysis&quot;, th=
en I recommend starting a new thread or document (maybe here, maybe somewhe=
re else) where you write down exactly what kind of static analysis you&#39;=
re hoping for. What new thing could the static analyzer do if it saw &quot;=
mut&quot; on a variable or parameter? What new thing could it do with varia=
bles or parameters that were neither &quot;mut&quot; nor &quot;const&quot;?=
 If it did these things, how would the programmer&#39;s life be improved? O=
nce you&#39;ve got something concrete there, you could try to convince some=
one to implement &quot;mut&quot; as an attribute or as a template annotatio=
n along the lines of owner&lt;T&gt;:</div><div><br></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 using mut&lt;T&gt; =3D T; =C2=A0// a=
nalyzer knows that this is a deliberately mutable T</font></div><div><br></=
div><div>But, as I said, I personally don&#39;t know what the static analyz=
er would <i>do</i> with the above information if it had it. =C2=A0Complain =
if you <i>didn&#39;t</i> mutate the variable? :P =C2=A0(Some analyzers/fron=
t-ends can do this today anyway: &quot;unmodified local variable could be d=
eclared const&quot; and so on.)</div><div><br></div><div>=E2=80=93Arthur</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/74a5f12f-0bde-4f4f-ac19-7fa3d3126737%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/74a5f12f-0bde-4f4f-ac19-7fa3d3126737=
%40isocpp.org</a>.<br />

------=_Part_164_1624496931.1482206779819--

------=_Part_163_1994814468.1482206779819--

.

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

Why add a new keyword when we already have 'mutable'? 'override' and
'final' aren't keywords (and 'auto' was reclaimed) for the exact reason
that *we ought not introduce keywords lightly*; I don't see the extra 4
letters being a good argument.

On Mon, Dec 19, 2016 at 11:06 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com=
>
wrote:

> On Monday, December 19, 2016 at 4:29:00 AM UTC-8, lcid...@gmail.com wrote=
:
>>
>> I am wondering whether it would make sense to add a mut keyword opposite
>> of const.
>> My personal reasoning would be:
>>
>>    1. personally I am tired of writing const nearly everwhere, when it
>>    seems what I mostly want is const as default.
>>    2. introducing in 2020 would allow us to write new code using mut to
>>    explicitly state that we want mutability. There would be no change in
>>    behavior.
>>    3. would allow for additional Core Guideline analysis.
>>    4. mut could perhaps be synonym to mutable.
>>    5. I would not use mutable because it simply is too long to write.
>>
>> #define mut mutable  // problem solved
>
> Please don't waste anyone's time by proposing synonyms for keywords.
>
> Now, as to whether "mutable" as the opposite of "const" is a good idea...
> I'm sympathetic to the idea that every keyword should have an inverse. We
> have both `const` and `mutable` to force constness/nonconstness on data
> members, for example. We have both `signed` and `unsigned` for integer
> types. And there have definitely been times and places where I've wished =
I
> could tag a local variable to say, "Dang it, watch out! This variable can=
't
> be `const` because it'll be mutated in the loop on line 357!"  Being able
> to tag that variable as `mutable` would be pretty neat.
> *But.* Given that mutability is the default in C++ (and as Ville said,
> that won't ever change), the closest analogue I can think of to the
> `mutable` keyword would be the `auto` keyword in C and C++03. It meant
> simply "this variable is on the stack", and was the inverse of
> extern/static. Since it was the default, basically nobody ever wrote it
> anywhere: `auto int x;` was better written as just `int x;`. The `auto`
> keyword was *so much* ignored by working programmers that it was able to
> be reclaimed in C++11.
> Therefore I would hesitate to introduce any new keyword (or even new plac=
e
> for an old keyword, such as `mutable`) whose purpose is just to be the
> default.  If `auto` is any guide, working programmers will ignore it and
> then it'll just be dead weight in the standard, ready to be ripped out
> again in 2023.
>
> If you're really interested in point 3 "would allow for additional Core
> Guideline analysis", then I recommend starting a new thread or document
> (maybe here, maybe somewhere else) where you write down exactly what kind
> of static analysis you're hoping for. What new thing could the static
> analyzer do if it saw "mut" on a variable or parameter? What new thing
> could it do with variables or parameters that were neither "mut" nor
> "const"? If it did these things, how would the programmer's life be
> improved? Once you've got something concrete there, you could try to
> convince someone to implement "mut" as an attribute or as a template
> annotation along the lines of owner<T>:
>
>     using mut<T> =3D T;  // analyzer knows that this is a deliberately
> mutable T
>
> But, as I said, I personally don't know what the static analyzer would
> *do* with the above information if it had it.  Complain if you *didn't*
> mutate the variable? :P  (Some analyzers/front-ends can do this today
> anyway: "unmodified local variable could be declared const" and so on.)
>
> =E2=80=93Arthur
>
> --
> 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/74a5f12f-0bde-4f4f-
> ac19-7fa3d3126737%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/74a5f12f-0b=
de-4f4f-ac19-7fa3d3126737%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAMD6iD--RMuj7aozowjMHMnFAohARWDreAa9e8u335wK9Jj=
e-g%40mail.gmail.com.

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

<div dir=3D"ltr">Why add a new keyword when we already have &#39;mutable&#3=
9;? &#39;override&#39; and &#39;final&#39; aren&#39;t keywords (and &#39;au=
to&#39; was reclaimed) for the exact reason that <i>we ought not introduce =
keywords lightly</i>; I don&#39;t see the extra 4 letters being a good argu=
ment.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon=
, Dec 19, 2016 at 11:06 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><span class=3D"">On Monday, December 19, 2016 at 4:29:00 AM UTC-8, <a=
 href=3D"mailto:lcid...@gmail.com" target=3D"_blank">lcid...@gmail.com</a> =
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">I am wonderi=
ng whether it would make sense to add a <font face=3D"courier new, monospac=
e">mut</font> keyword opposite of <font face=3D"courier new, monospace">con=
st</font>.<div>My personal reasoning would be:</div><div><ol><li>personally=
 I am tired of writing <font face=3D"courier new, monospace">const</font> n=
early everwhere, when it seems what I mostly want is <font face=3D"courier =
new, monospace">const</font> as default.</li><li>introducing in 2020 would =
allow us to write new code using <font face=3D"courier new, monospace">mut<=
/font> to explicitly state that we want mutability. There would be no chang=
e in behavior.<br></li><li>would allow for additional Core Guideline analys=
is.</li><li><font face=3D"courier new, monospace">mut</font> could perhaps =
be synonym to <font face=3D"courier new, monospace">mutable</font>.</li><li=
>I would not use <font face=3D"courier new, monospace">mutable</font> becau=
se it simply is too long to write.</li></ol></div></div></blockquote></span=
><div><font face=3D"courier new, monospace">#define mut mutable =C2=A0// pr=
oblem solved</font></div><div><br></div><div>Please don&#39;t waste anyone&=
#39;s time by proposing synonyms for keywords.</div><div><br></div><div>Now=
, as to whether &quot;mutable&quot; as the opposite of &quot;const&quot; is=
 a good idea...</div><div>I&#39;m sympathetic to the idea that every keywor=
d should have an inverse. We have both `const` and `mutable` to force const=
ness/nonconstness on data members, for example. We have both `signed` and `=
unsigned` for integer types. And there have definitely been times and place=
s where I&#39;ve wished I could tag a local variable to say, &quot;Dang it,=
 watch out! This variable can&#39;t be `const` because it&#39;ll be mutated=
 in the loop on line 357!&quot; =C2=A0Being able to tag that variable as `m=
utable` would be pretty neat.</div><div><i><b>But.</b></i> Given that mutab=
ility is the default in C++ (and as Ville said, that won&#39;t ever change)=
, the closest analogue I can think of to the `mutable` keyword would be the=
 `auto` keyword in C and C++03. It meant simply &quot;this variable is on t=
he stack&quot;, and was the inverse of extern/static. Since it was the defa=
ult, basically nobody ever wrote it anywhere: `auto int x;` was better writ=
ten as just `int x;`. The `auto` keyword was <i>so much</i> ignored by work=
ing programmers that it was able to be reclaimed in C++11.</div><div>Theref=
ore I would hesitate to introduce any new keyword (or even new place for an=
 old keyword, such as `mutable`) whose purpose is just to be the default.=
=C2=A0 If `auto` is any guide, working programmers will ignore it and then =
it&#39;ll just be dead weight in the standard, ready to be ripped out again=
 in 2023.</div><div><br></div><div>If you&#39;re really interested in point=
 3 &quot;would allow for additional Core Guideline analysis&quot;, then I r=
ecommend starting a new thread or document (maybe here, maybe somewhere els=
e) where you write down exactly what kind of static analysis you&#39;re hop=
ing for. What new thing could the static analyzer do if it saw &quot;mut&qu=
ot; on a variable or parameter? What new thing could it do with variables o=
r parameters that were neither &quot;mut&quot; nor &quot;const&quot;? If it=
 did these things, how would the programmer&#39;s life be improved? Once yo=
u&#39;ve got something concrete there, you could try to convince someone to=
 implement &quot;mut&quot; as an attribute or as a template annotation alon=
g the lines of owner&lt;T&gt;:</div><div><br></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 using mut&lt;T&gt; =3D T; =C2=A0// analyze=
r knows that this is a deliberately mutable T</font></div><div><br></div><d=
iv>But, as I said, I personally don&#39;t know what the static analyzer wou=
ld <i>do</i> with the above information if it had it.=C2=A0 Complain if you=
 <i>didn&#39;t</i> mutate the variable? :P =C2=A0(Some analyzers/front-ends=
 can do this today anyway: &quot;unmodified local variable could be declare=
d const&quot; and so on.)</div><div><br></div><div>=E2=80=93Arthur</div></d=
iv><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/74a5f12f-0bde-4f4f-ac19-7fa3d3126737%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/74a5=
f12f-0bde-4f4f-<wbr>ac19-7fa3d3126737%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAMD6iD--RMuj7aozowjMHMnFAohARWDreAa9=
e8u335wK9Jje-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD--RMuj7aoz=
owjMHMnFAohARWDreAa9e8u335wK9Jje-g%40mail.gmail.com</a>.<br />

--001a11405f40a6501b05441c265e--

.

------=_Part_305_1385165352.1482396497576
Content-Type: multipart/alternative;
 boundary="----=_Part_306_1653839506.1482396497576"

------=_Part_306_1653839506.1482396497576
Content-Type: text/plain; charset=UTF-8

Swift solves this pretty nicely with the let/var keywords:

var foo = 3   // foo is mutable
let bar = 3    // bar is const

Assuming you're happy typing "auto" instead of "var", and depending on your
feelings about macros, you could easily implement this for your own code:

#define let const auto

--
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/1d2dccb3-8360-4ab9-a4d7-5fe7e6c6adbc%40isocpp.org.

------=_Part_306_1653839506.1482396497576
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Swift solves this pretty nicely with the let/var keywords:=
<div><br></div><div>var foo =3D 3 =C2=A0 // foo is mutable</div><div>let ba=
r =3D 3 =C2=A0 =C2=A0// bar is const</div><div><br></div><div>Assuming you&=
#39;re happy typing &quot;auto&quot; instead of &quot;var&quot;, and depend=
ing on your feelings about macros, you could easily implement this for your=
 own code:</div><div><br></div><div>#define let const auto</div><div><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/1d2dccb3-8360-4ab9-a4d7-5fe7e6c6adbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d2dccb3-8360-4ab9-a4d7-5fe7e6c6adbc=
%40isocpp.org</a>.<br />

------=_Part_306_1653839506.1482396497576--

------=_Part_305_1385165352.1482396497576--

.

------=_Part_2889_373122929.1482660626861
Content-Type: multipart/alternative;
 boundary="----=_Part_2890_1138223485.1482660626861"

------=_Part_2890_1138223485.1482660626861
Content-Type: text/plain; charset=UTF-8

Several minor points first (some were mentioned above):

1. What is it exactly opposite to? The keyword `const` has more than one
meaning.
2. As above, `const` everywhere (literally) seems bad.
3. Why should it be a keyword to help analysis?
4. Seems too bad having `mut` as well as `mutable` in a language. Confusing.
5. Is it worth to break existed code massively?

There can be more problems, if you want things further than just some
syntactic sugar:

1. Despite the ambiguity in the meaning/intention of `const`, why do you
think making objects immutable (as possible/by default) is the right
direction of the style of code in general, in a language which allows first
class side effects of expression evaluation?
2. You can define mutability based on the current object model even you
know nothing about the exact value representation for every object type.
But how can you define immutability as the base, esp. for types has no
predefined value equivalence at all?
3. There is only one kind of mutability implied by the current object
model. This can be not ideal, but it at least provides some guarantees for
easy interops. On the opposite, ultimately, can you insist/assert there
can/should be only one exact immutability expected by users of the
language? (This problem may apply to so-called `const`-correctness, too.
For instance, is `const` enough to allow constant propagation? Is implicit
`const` really appropriate on the key type of associative containers?)


--
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/55b36967-62db-4f78-86af-3266c9f6ffec%40isocpp.org.

------=_Part_2890_1138223485.1482660626861
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Several minor points first (some were mentioned above):<br=
><br>1. What is it exactly opposite to? The keyword `const` has more than o=
ne meaning.<br>2. As above, `const` everywhere (literally) seems bad.<br>3.=
 Why should it be a keyword to help analysis?<br>4. Seems too bad having `m=
ut` as well as `mutable` in a language. Confusing.<br>5. Is it worth to bre=
ak existed code massively?<br><br>There can be more problems, if you want t=
hings further than just some syntactic sugar:<br><br>1. Despite the ambigui=
ty in the meaning/intention of `const`, why do you think making objects imm=
utable (as possible/by default) is the right direction of the style of code=
 in general, in a language which allows first class side effects of express=
ion evaluation?<br>2. You can define mutability based on the current object=
 model even you know nothing about the exact value representation for every=
 object type. But how can you define immutability as the base, esp. for typ=
es has no predefined value equivalence at all?<br>3. There is only one kind=
 of mutability implied by the current object model. This can be not ideal, =
but it at least provides some guarantees for easy interops. On the opposite=
, ultimately, can you insist/assert there can/should be only one exact immu=
tability expected by users of the language? (This problem may apply to so-c=
alled `const`-correctness, too. For instance, is `const` enough to allow co=
nstant propagation? Is implicit `const` really appropriate on the key type =
of associative containers?)<br><br><br><iframe style=3D"padding: 0px; posit=
ion: absolute; top: 0px; left: 0px; width: 1456px; height: 188px; visibilit=
y: hidden;" frameborder=3D"0"></iframe></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/55b36967-62db-4f78-86af-3266c9f6ffec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55b36967-62db-4f78-86af-3266c9f6ffec=
%40isocpp.org</a>.<br />

------=_Part_2890_1138223485.1482660626861--

------=_Part_2889_373122929.1482660626861--

.

------=_Part_98_1212486978.1483001598016
Content-Type: multipart/alternative;
 boundary="----=_Part_99_961975756.1483001598016"

------=_Part_99_961975756.1483001598016
Content-Type: text/plain; charset=UTF-8

I've been wondering about having implicit in addition to explicit..
It'd allow constructors that could be explicit (especially single-argument
ones) to be explicitly marked implicit.
That way, compilers could (optionally) warn when neither explicit nor
implicit is specified.

Then, maybe, in 10, 20 or 30 years, explicit could become the default
unless specified otherwise.

I've thought about mutable in the past too, especially for references.
We've now got string_view for const string& (which is const implicitly) so
a major case is covered already.

--
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/c31ef030-13c3-4aa8-8b03-0989d40c4a00%40isocpp.org.

------=_Part_99_961975756.1483001598016
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve been wondering about having implicit in addition =
to explicit..<div>It&#39;d allow constructors that could be explicit (espec=
ially single-argument ones) to be explicitly marked implicit.</div><div>Tha=
t way, compilers could (optionally) warn when neither explicit nor implicit=
 is specified.</div><div><br></div><div>Then, maybe, in 10, 20 or 30 years,=
 explicit could become the default unless specified otherwise.</div><div><b=
r></div><div>I&#39;ve thought about mutable in the past too, especially for=
 references. We&#39;ve now got string_view for const string&amp; (which is =
const implicitly) so a major case is covered already.</div><div><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/c31ef030-13c3-4aa8-8b03-0989d40c4a00%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c31ef030-13c3-4aa8-8b03-0989d40c4a00=
%40isocpp.org</a>.<br />

------=_Part_99_961975756.1483001598016--

------=_Part_98_1212486978.1483001598016--

.