Proposal:
   Non-const member functions should be (internally) auto-propagated to con=
st
   if the object is const.
   Currently compile error happens.

class X
   {
     public:
       X() {}
       void f()
         {
           // non modifying operations like printing
         }

   };

int main()
   {
     X x;   // making this const brings compiler err
     x.f();
     return 0;
   }


$ g++ -Wall -ggdb -std=3Dc++11 t.cpp
t.cpp: In function =E2=80=98int main()=E2=80=99:
t.cpp:15:9: error: passing =E2=80=98const X=E2=80=99 as =E2=80=98this=E2=80=
=99 argument of =E2=80=98void X::f()=E2=80=99=20
discards qualifiers [-fpermissive]
      x.f();
          ^

Comments:

If X::f() does not modify the object then everything is ok,
and consequently code should compile successfully.
Otherwise correctly a compile error will happen.

A compile error should happen if and only if the object
actually gets modified in the not-explicitly-const-declared
member func.

If x gets defined as const, then the code should successfully compile
if the member func does not modify the object.

--=20
Rgds,
U.Mutlu


--=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/.

.

------=_Part_165_761034084.1439388381262
Content-Type: multipart/alternative;
 boundary="----=_Part_166_540437738.1439388381262"

------=_Part_166_540437738.1439388381262
Content-Type: text/plain; charset=UTF-8

 At compile-time, how does the compiler determine whether the object is
modified or not?

--

---
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/.

------=_Part_166_540437738.1439388381262
Content-Type: text/html; charset=UTF-8

<div dir="ltr"> At compile-time, how does the compiler determine whether the object is modified or not?<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_166_540437738.1439388381262--
------=_Part_165_761034084.1439388381262--

.

On 2015-08-12 09:39, U.Mutlu wrote:
> Proposal:
>   Non-const member functions should be (internally) auto-propagated to
> const

Er... no? Just make the member const in the first place. If it can be,
it should be. If it can't be, it can't be, period. I find it extremely
hard to imagine that this minor convenience is worth the complexities
that would be involved to implement it, just so that you can be lazy
about writing your code properly in the first place.

In fact, "complexities" is probably an understatement; if the member is
in a different TU, there's no reasonable way you could implement such a
feature.

--
Matthew

--

---
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/.

.

Matthew Woehlke wrote on 08/12/2015 04:21 PM:
> On 2015-08-12 09:39, U.Mutlu wrote:
>> Proposal:
>>    Non-const member functions should be (internally) auto-propagated to
>> const
>
> Er... no? Just make the member const in the first place. If it can be,
> it should be. If it can't be, it can't be, period. I find it extremely
> hard to imagine that this minor convenience is worth the complexities
> that would be involved to implement it, just so that you can be lazy
> about writing your code properly in the first place.
>
> In fact, "complexities" is probably an understatement; if the member is
> in a different TU, there's no reasonable way you could implement such a
> feature.


I find it funny when a class that compiles fine in the first place
as a normal non-const object, should not make it neccessary to change
the class definition only because one wants to create a const object
of the same class...

The problem arose here when I wanted in a member func to print whether
the object is const or not. It works only for one of the cases.
It won't work for both the const and non-const case due to a limit
in the 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Nevin Liber wrote on 08/12/2015 05:25 PM:
> On 12 August 2015 at 09:21, Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
>
>> Er... no? Just make the member const in the first place. If it can be,
>> it should be. If it can't be, it can't be, period. I find it extremely
>> hard to imagine that this minor convenience is worth the complexities
>> that would be involved to implement it, just so that you can be lazy
>> about writing your code properly in the first place.
>>
>
> And the one place I'd want it might be for getters such as:
>
> T& get() { return data_; }
> T const& get() const { return data_; }
>
> it won't do the correct thing, as one has to change the return type.

Exactly!
Another good reason to fix it in the language specification.



--

---
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/.

.

On 2015-08-12 11:25, Nevin Liber wrote:
> On 12 August 2015 at 09:21, Matthew Woehlke wrote:
>> Er... no? Just make the member const in the first place. If it can be,
>> it should be. If it can't be, it can't be, period. I find it extremely
>> hard to imagine that this minor convenience is worth the complexities
>> that would be involved to implement it, just so that you can be lazy
>> about writing your code properly in the first place.
>
> And the one place I'd want it might be for getters such as:
>
> T& get() { return data_; }
> T const& get() const { return data_; }
>
> it won't do the correct thing, as one has to change the return type.

That's a different feature, and one that's been discussed before. What's
desired there is something more like:

  auto get() maybe_const -> T maybe_const& { ... }

You do get both flavors for writing only once, but you must still
annotate the method properly.

--
Matthew

--

---
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/.

.

On 2015-08-12 11:28, U.Mutlu wrote:
> The problem arose here when I wanted in a member func to print whether
> the object is const or not. It works only for one of the cases.
> It won't work for both the const and non-const case due to a limit
> in the language.

Are you talking about something like Nevin's example?

The compiler CANNOT save you from properly annotating your function.
Adding a way to instruct the compiler to *always* generate both const
and non-const flavors of a method, while only having to write the
definition once, is a very different feature from how you worded your
original request.

That feature *has* been requested before, and I think would be useful to
have. (I don't recall what happened that we don't have it yet... maybe
just no one has followed through with an official proposal?)

The "implicit conversion" is not going to happen; by the time the
compiler knows that you want it, it is too late. You have to be explicit
up front.

--
Matthew

--

---
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/.

.