------=_Part_17_22491298.1391895381381
Content-Type: text/plain; charset=UTF-8

The following operators must be implemented as member functions:

* assignment operator (`operator=`)
* array subscript operator (`operator[]`)
* dereference operator (unary `operator*`)
* member access through pointer operator (`operator->`)
* function call operator (`operator()`)

There seems to be no technical reason for preventing these from being
implemented as free functions (non-member functions).

The two exceptions I can think of are the compiler-generated copy and move
assignment operators. It seems reasonable to require them to be member
functions, because otherwise the compiler would be unable to generate those
when it finishes parsing the class. I am not too attached to being able to
provide free-function definitions of `operator=` for other arguments,
except that the restriction is artificial. We already have special cases
for the copy and move assignment operators in the form templates never
being considered instead of the compiler-generated version. The other
operators are much more important to me.

The use case that motivates this proposal is an integer class. I can define
this:

template<typename T>
T * operator+(T * const pointer, my_integer const & offset) {
    return pointer + offset.value();
}

And everything is fine. I cannot, however, define this:

template<typename T>
T & operator[](T * const pointer, my_integer const & index) {
    return pointer[offset.value()];
}

Because `operator[]` must be a member function, and I cannot add member
functions to a pointer. This forces users of my class to treat my class
different from built-in types by always using `*(pointer + index)`, which
violates C++'s design goal of not giving built-in types advantages over
user-defined types.

I also have several classes where I would implement the dereference
operator and member access through pointer operator for some of my classes
as free functions (following the general advice of maximizing encapsulation
by preferring free functions over member functions / friend functions), but
I cannot.

It seems that any objections to allowing these to be non-member functions
would apply to allowing any operator to be implementable as a non-member
function. Consistency and allowing increased encapsulation seem to be
strong arguments in favor of allowing.

--

---
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_17_22491298.1391895381381
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The following operators must be implemented as member func=
tions:<br><br>* assignment operator (`operator=3D`)<br>* array subscript op=
erator (`operator[]`)<br>* dereference operator (unary `operator*`)<br>* me=
mber access through pointer operator (`operator-&gt;`)<br>* function call o=
perator (`operator()`)<br><br>There seems to be no technical reason for pre=
venting these from being implemented as free functions (non-member function=
s).<br><br>The
 two exceptions I can think of are the compiler-generated copy and move=20
assignment operators. It seems reasonable to require them to be member=20
functions, because otherwise the compiler would be unable to generate=20
those when it finishes parsing the class. I am not too attached to being
 able to provide free-function definitions of `operator=3D` for other=20
arguments, except that the restriction is artificial. We already have=20
special cases for the copy and move assignment operators in the form=20
templates never being considered instead of the compiler-generated=20
version. The other operators are much more important to me.<br><br>The use =
case that motivates this proposal is an integer class. I can define this:<b=
r><br>template&lt;typename T&gt;<br>T * operator+(T * const pointer, my_int=
eger const &amp; offset) {<br>&nbsp; &nbsp; return pointer + offset.value()=
;<br>}<br><br>And everything is fine. I cannot, however, define this:<br><b=
r>template&lt;typename T&gt;<br>T &amp; operator[](T * const pointer, my_in=
teger const &amp; index) {<br>&nbsp; &nbsp; return pointer[offset.value()];=
<br>}<br><br>Because
 `operator[]` must be a member function, and I cannot add member=20
functions to a pointer. This forces users of my class to treat my class=20
different from built-in types by always using `*(pointer + index)`,=20
which violates C++'s design goal of not giving built-in types advantages
 over user-defined types.<br><br>I also have several classes where I=20
would implement the dereference operator and member access through=20
pointer operator for some of my classes as free functions (following the
 general advice of maximizing encapsulation by preferring free functions
 over member functions / friend functions), but I cannot.<br><br>It=20
seems that any objections to allowing these to be non-member functions=20
would apply to allowing any operator to be implementable as a non-member
 function. Consistency and allowing increased encapsulation seem to be=20
strong arguments in favor of allowing.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------=_Part_17_22491298.1391895381381--

.