Topic: Non-member function call, subscripting and
Author: jmonnon@aldebaran.com
Date: Fri, 23 Jun 2017 10:03:37 -0700 (PDT)
Raw View
------=_Part_594_1576976543.1498237417953
Content-Type: multipart/alternative;
boundary="----=_Part_595_1150732690.1498237417953"
------=_Part_595_1150732690.1498237417953
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello,
This is a proposal to allow operator(), operator[] and operator-> to be=20
defined as non-member functions.
I do not know if this has already been proposed and potential arguments=20
against it, so please let me know.
The main motivation for this proposal is consistency. It makes also easier=
=20
to externally adapt existing types for use with generic algorithms, as show=
=20
examples.
Thank you in advance for your reviews and comments.
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
--=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/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%40isocpp.or=
g.
------=_Part_595_1150732690.1498237417953
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<div><br></div><div>This is a proposal to allow oper=
ator(), operator[] and operator-> to be defined as non-member functions.=
</div><div>I do not know if this has already been proposed and potential ar=
guments against it, so please let me know.</div><div><br></div><div>The mai=
n motivation for this proposal is consistency. It makes also easier to exte=
rnally adapt existing types for use with generic algorithms, as show exampl=
es.</div><div><br></div><div>Thank you in advance for your reviews and comm=
ents.</div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous=
=C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d'en=
aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes les=
copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e=
%40isocpp.org</a>.<br />
------=_Part_595_1150732690.1498237417953--
------=_Part_594_1576976543.1498237417953
Content-Type: text/plain; charset=US-ASCII;
name=proposal_non_member_operators.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=proposal_non_member_operators.txt
X-Attachment-Id: 4c7d7d70-dcba-4558-9900-40be383cc3b2
Content-ID: <4c7d7d70-dcba-4558-9900-40be383cc3b2>
Non-member function call, subscripting and dereferencing operators
I. Introduction
This is a proposal to allow operator(), operator[] and operator-> to be defined as non-member functions.
II. Motivation And Scope
The main motivation of this proposal is to get a better language consistency by removing design exceptions. It is also to facilitate generic programming by making easier to adapt existing types to concepts required by generic algorithms / data structures.
a. Consistency
Most operators can be defined as member functions or as non-member functions taking the instance as a first parameter.
The only exceptions, that is the only operators that can only be defined as member functions, are:
- operator= (assignment)
- operator() (function call)
- operator[] (subscripting)
- operator-> (class member access)
From this group, operator= stands apart as it is under most conditions automatically generated by the compiler when not explicitly defined by the user. Allowing to define operator= as a non-member function could change the meaning of assignment for a given type in the "middle" of a translation unit. This would arguably result in non-obvious code.
The three other operators ((), [] and ->) do not suffer this problem. They do not seem in any manner different than other operators that can already be defined as non-member functions.
For example, operator() and operator[] may modify the class instance, but so are all @= operators (@ standing for +, -, *, etc.)
operator* and operator& handle dereferencing and memory aspects, so operator-> should be allowed to be defined under the same rules.
It is important to favor consistency and to limit exceptions in the design of a language. Every design exception will lend to unnecessary complications (see examples below). Powerful designs are those that are the most consistent, as can be seen in mathematics for example.
b. Generic programming
() and [] provide a very concise and clear syntax for function call and subscripting. These operators are also already used by built-in types and standard components (native functions and closures for (), pointers, arrays and most standard containers for [], etc.).
It is thus highly desirable to rely on these operators when writing user-defined types, so as to avoid an unnecessary syntactic diversity for semantically equivalent operations (here, function call and element access).
This is especially important in generic programming, whose goal is to provide algorithms and data structures easily usable with the maximum number of types. As programmers, in our everyday work we often use types defined in third-party libraries for which we don't have access to the source code. It is often the case that one of these types almost models the required concept for a generic algorithm we want to use, except for one operation that is named in a different way.
For instance, it is common that a type has a predominant action whose name can vary: run, trigger, call, apply, launch, invoke, etc. According to Bjarne Stroustrup, this is the perfect case for the function call operator ("The C++ Language" 4ed, 19.2.2).
Because operator() cannot be defined as a non-member function, our only possibility to make our third-party type model the required concept is to write a wrapper type that duplicates its interface only to forward calls, and to finally add a non-static member operator(). This may be a lot of work, especially if the interface of the third-party type is rich.
Note: lamdbas are often not the right tool for this job, as their interface may be too restrictive (they are strictly function objects), and their behavior can be too limited (no default construction in the general case, no ordering, etc., see section VI. 3. for an example).
Indeed, it would be much easier to externally define a non-member operator().
operator[] and operator-> are in the same situation. For instance, element access is often given various names (get, element, value, etc.) that hinder generic programming.
With non-member operators, it is easy to adapt existing types we don't have access to the source code, in order to homogenize syntactic differences and make them model the required concepts for our generic algorithms and data structures (see section III for examples).
c. Unclear initial motivation
Finally, it seems the initial motivation for the restrictions on operator(), operator[] and operator-> is not clear. As Bjarne Stroustrup declared in "The Design and Evolution of C++":
> in the original design of C++ [...], I restricted
> operators [], () and -> to be members. It seemed a harmless
> restriction that eliminated the possibility of some obscure errors
> because these operators invariably depend on and typically modify the
> state of their left-hand operand. However, it is probably a case of
> unnecessary nannyism."
> ("The Design and Evolution of C++", Section 3.6.2 "Members and Friends", p. 83)
As shown above, many operators already modify their left-hand operand (@=, etc.), so operator[], operator() and operator-> are not different with this respect.
III. Examples
a. Uniform access to elements
// A third-party type we cannot modify the definition.
class url {
// ...
public:
std::string_view scheme() const;
std::string_view authority() const;
std::string_view path() const;
// ...
};
// In another third-party library:
class kv_doc {
// ...
public:
value const& get(key k) const;
// ...
};
// We want to access elements in url and kv_doc in an
// uniform way by subscripting.
enum class url_part {
scheme,
authority,
path,
// ...
};
// _Not_ currently allowed:
std::string_view operator[](url const& u, url_part part) {
// Forward to the right method.
switch (part) {
case url_part::scheme: return u.scheme();
// ...
}
}
// _Not_ currently allowed:
kv_doc::value const& operator[](kv_doc const& doc, kv_doc::key k) {
// Simply forward to get().
return doc.get(k);
}
// Now we can reuse some generic algorithm relying on subscripting.
// Compare the amount of work we've done here to writing wrapper
// types to add non-static member operator[].
template<typename Range, typename Index, typename Value>
auto some_algo(Range const& range, Index idx, Value const& value) {
// ...
for (auto const& elem: range) {
if (elem[idx] == value) // ...
}
// ...
}
// urls is a range of url.
auto result_https = some_algo(urls, url_part::scheme, "https");
// vec3s is a range of 3-dimensional float vectors.
auto result_abscissa = some_algo(vec3s, 1, 0.f); // Will test: elem[1] == 0.f
// docs is a range of kv_doc.
auto result_n32 = some_algo(docs, "type", "N32"); // Will test: elem["type"] == "N32"
See also the definition of bounded_range in "Elements of Programming" (Section 12.1 "Simple Composite Objects"), where operator[] is forced to be treated as an exception.
b. Making functional patterns easier to use
1. Function composition
We want to adapt third-party types to make them function objects,
so that we can use them with our (function) composition tools.
// In a third-party library
// (we don't have access to the source code):
class parser {
// ...
public:
document parse(std::istream*) const;
// ...
};
safe_document sanitize(document const&);
class database {
// ...
public:
transaction_id store(safe_document const&);
// ...
};
// In our code, we adapt these types to make them function objects.
// We just forward to the right method, so non-member overloading is
// much easier than wrapping.
// _Not_ currently allowed:
auto operator()(parser const& p, std::istream* i) {
// Simply forward to parse().
return p.parse(i);
}
// _Not_ currently allowed:
auto operator()(database& db, safe_document const& doc) {
// Simply forward to store().
return db.store(doc);
}
// ... and be able to use our composition tools:
// parse is a parser instance,
// store is a database instance
// files is a container of std::istream*
// Will perform store(sanitize(parse(file))) on each file.
// See section VI. a. for a simple implementation of |.
std::for_each(std::execution::par,
begin(files), end(files),
parse | sanitize | store);
2. Monadic composition
Non-member operator() makes the use of functional patterns easier, such as basic function composition but richer compositions are possible.
// In our code, we replace the previous operator() definitions
// by these ones.
// We now return std::optionals that are empty in case of error.
// _Not_ currently allowed:
std::optional<document> operator()(parser const& p, std::istream* i) {
try {
return {p.parse(i)};
} catch (std::exception const& e) {
// log error
}
return {};
}
std::optional<safe_document> sanitize_total(document const&) {
try {
return {sanitize(doc)};
} catch (std::exception const& e) {
// log error
}
return {};
}
// _Not_ currently allowed:
std::optional<transaction_id> operator()(database& db, safe_document const& doc) {
try {
return {db.store(doc)};
} catch (std::exception const& e) {
// log error
}
return {};
}
// Will perform the equivalent of store(sanitize(parse(doc))),
// but will propagate any empty optional.
// See section VI. b. for an naive implementation of >>.
std::vector<std::optional<transaction_id>> transactions;
boost::range::transform(files, std::back_inserter(transactions),
parse >> sanitize_total >> store);
See also section VI. c. for an example of lambdas' limitations explained above.
c. Duality between pure functions and collections of values
1. Pure function as a collection of values
// Third-party code:
// A linear recurrence computes a value based on the n previous values.
// Fibonacci is such an example, based on the 2 previous values.
// The designer decided to implement it as a function object...
class some_linear_recurrence {
// Typically, a mutable state can memoize the results if necessary.
public:
value_type operator()(value_type const& x) const;
// ...
};
// Our code:
// ... but a pure function can also be viewed as a collection of values.
// In our context, it is easier to manipulate this linear recurrence
// as a collection of values, so we define the subscripting operator:
template<typename T>
T operator[](some_linear_recurrence const& f, T const& x) {
return f(x);
}
2. Collection of values as a pure function
// Third-party code:
// The designer decided to implement it as a collection of values...
class some_linear_recurrence {
// Typically, a mutable state can memoize the results if necessary.
public:
value_type operator[](value_type x) const;
// ...
};
// Our code:
// ... but a collection of values can also be viewed as a pure function.
// In our context, it is easier to manipulate this linear recurrence
// as a pure function, so we define the function call operator:
template<typename T>
T operator()(some_linear_recurrence const& f, T const& x) {
return f[x];
}
IV. Impact On The Standard
Being a pure extension, this proposal shouldn't break any existing code.
The behavior of non-member operators is well-known, so no surprise is to be expected.
V. Standardese
The following changes are based on the document n4659.pdf.
1. Replace 16.5.4 [over.call] by (modifications are between `*`):
operator() shall be *implemented either by* a non-static member function (12.2.1) with an arbitrary number of parameters *or by a non-member function with at least one parameter, the first one evaluating to a class object*.
It can have default arguments*, except for the first argument of the non-member form*.
It implements the function call syntax
postfix-expression ( expression-list-opt )
where the postfix-expression evaluates to a class object and the possibly empty expression-list matches the parameter list of an operator() member function of the class *, or postfix-expression followed by the expression-list matches the parameter list of the non-member form*.
Thus, a call x(arg1,...) is *either* interpreted as x.operator()(arg1, ...) for a class object x of type T if *T::operator()(T1, ...)* exists, *or is interpreted as operator()(x, arg1, ...), depending on wether* the operator is selected as the best match function by the overload resolution mechanism (16.3.3).
2. Replace 16.5.5 [over.sub] by (modifications are between `*`):
operator[] shall be *implemented either by* a non-static member function with exactly one parameter *or by a non-member function with two parameters, the first one evaluating to a class object*. It implements the subscripting syntax
postfix-expression [ expr-or-braced-init-list ]
Thus, a subscripting expression x[y] is *either* interpreted as x.operator[](y) for a class object x of type T if T::operator[](T1) exists, *or is interpreted as operator[](x, arg1, ...), depending on wether* the operator is selected as the best match function by the overload resolution mechanism (16.3.3).
3. Replace 16.5.6 [over.ref] by (modifications are between `*`):
operator-> shall be *implemented either by* a non-static member function taking no parameters *or by a non-member function taking one parameter evaluating to a class object*. It implements the class member access syntax that uses ->.
postfix-expression -> template-opt id-expression
postfix-expression -> pseudo-destructor-name
An expression x->m is interpreted as (x.operator->())->m for a class object x of type T if T::operator->() exists*, or as (operator->(x))->m, depending on wether* the operator is selected as the best match function by the overload resolution mechanism (16.3).
VI. Annexes
a. Simple function composition
#define MEMBER_OP_EQUAL_AND_LESS_THAN_1(type, member0) \
bool operator==(type const& x) const { \
return member0 == x.member0; \
} \
bool operator<(type const& x) const { \
return member0 < x.member0; \
}
#define MEMBER_OP_EQUAL_AND_LESS_THAN_2(type, member0, member1) \
bool operator==(type const& x) const { \
return member0 == x.member0 && member1 == x.member1; \
} \
bool operator<(type const& x) const { \
return member0 < x.member0 || \
(!(x.member0 < member0) && member1 < x.member1); \
}
// Function<U (T)> F,
// Function<V (U)> G
template<typename F, typename G>
struct compose {
F f;
G g;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_2(compose, f, g)
// Function<V (T)>:
template<typename T>
auto operator()(T const& t) { // should perfect-forward
// Doesn't handle the void case.
// Should void be regular, this code would be sufficient...
return g(f(t));
}
};
template<typename F, typename G>
compose<F, G> operator|(F f, G g) {
return {f, g};
}
b. Simple monad composition
// Calls g if the optional is not empty, otherwise returns an empty optional.
//
// Function<std::optional<V> (U)> G
template<typename U, typename G>
auto monad_bind(std::optional<U> const& opt, G g) {
using OptV = std::decay_t<decltype(g(*opt))>;
if (opt) return g(*opt);
else return OptV{};
};
// Function<std::optional<U> (T)> F,
// Function<std::optional<V> (U)> G
template<typename F, typename G>
struct monad_compose {
F f;
G g;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_2(monad_compose, f, g)
// Function<std::optional<V> (T)>:
template<typename T>
auto operator()(T const& t) {
return monad_bind(f(t), g);
}
};
template<typename F, typename G>
monad_compose<F, G> operator>>(F f, G g) {
return {f, g};
}
c. Transformation-based iterator
// Computes a new value on increment.
//
// Function<Value (Value)> Transfo
template<typename Value, typename Transfo>
struct transfo_iter {
Value v;
Transfo f;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_2(transfo_iter, v, f)
// ForwardIterator:
transfo_iter& operator++() {
v = f(v);
return *this;
}
Value const& operator*() const {
return v;
}
// ...
// We want transfo_iter to be default constructible, comparable,
// ordonnable (to roughly follow the definition of the Regular concept
// in Elements of Programming, section 1.5), so Value _and_ Transfo
// must also be.
};
// Example of transfo_iter use for drawing "orbits".
struct point {
double x, y;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_2(point, x, y)
};
void draw_segment(point const& a, point const& b);
// Draws segments for the given points.
//
// ForwardIterator TotallyOrdered I
template<typename I>
void draw_nonempty(I begin, I end) {
// Precondition: ++begin is defined
I previous; // _Here_: won't work if transfo_iter contains a stateful lambda
do {
previous = begin;
++begin;
draw_segment(*previous, *begin);
} while (begin < end); // _Here_: won't work if transfo_iter contains a lambda
}
// We define a few point transformations.
struct rotate {
double theta;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_1(rotate, theta)
// Transformation:
point operator()(point const& p) const {
using namespace std;
return {cos(theta) * p.x - sin(theta) * p.y,
sin(theta) * p.x + cos(theta) * p.y};
}
};
struct scale {
double d;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_1(scale, d)
// Transformation:
point operator()(point const& p) const {
return {d * p.x, d * p.y};
}
};
struct translate {
double x, y;
// Regular:
MEMBER_OP_EQUAL_AND_LESS_THAN_2(translate, x, y)
// Transformation:
point operator()(point const& p) const {
return {x + p.x, y + p.y};
}
};
// f is a transformation on point: it takes a point and return a new point.
// We reuse our function composition tool (see VI. a).
auto f = rotate{pi / 8} | scale{1.1} | translate{0.0, 1.0};
using I = transfo_iter<point, decltype(f)>;
// Draw until we go beyond {10, 10}.
draw_nonempty(I{{1.0, 1.0}, f}, I{{10.0, 10.0}, f});
VII. References
Elements of Programming, Stepanov A. & McJones P., 2009, Addison-Wesley
The Design and Evolution of C++, Stroustrup B., 1994, Addison-Wesley Professional
------=_Part_594_1576976543.1498237417953--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 23 Jun 2017 10:50:30 -0700 (PDT)
Raw View
------=_Part_644_1907623133.1498240230859
Content-Type: multipart/alternative;
boundary="----=_Part_645_1536795377.1498240230860"
------=_Part_645_1536795377.1498240230860
Content-Type: text/plain; charset="UTF-8"
On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:
>
> Hello,
>
> This is a proposal to allow operator(), operator[] and operator-> to be
> defined as non-member functions.
> I do not know if this has already been proposed and potential arguments
> against it, so please let me know.
>
OK, first question: what's the syntax for *preventing people* from
overriding these things on my types?
These operators are pretty intimately connected to the very interfaces by
which we use to interact with objects of those types. It fundamentally
means something about a type that it has a function call operator on it,
for example. That type is a "functor".
If I don't want my type to be a functor, that is my prerogative. So there
needs to be a way to say that I *don't* want someone to force my type to
have an interface that I didn't give it.
Indeed, the ability to define `operator()` from outside a class effectively
means that you can insert *any* interface into any class type you want.
You'd just add an `operator()` overload, using a tag type to differentiate
which pseudo-member function you want to call.
It seems to me that what you're trying to do would be best done with
specialization functions, not through direct interactions with a type.
The main motivation for this proposal is consistency.
>
That's not really good enough of a reason, as the inconsistency actually
has a purpose. As explained above.
It makes also easier to externally adapt existing types for use with
> generic algorithms, as show examples.
>
Specialization functions would be the preferred way to handle that.
> Thank you in advance for your reviews and comments.
>
--
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/58241e72-ee58-4e46-897c-2bc644fa51db%40isocpp.org.
------=_Part_645_1536795377.1498240230860
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldeb=
aran.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"ltr=
">Hello,<div><br></div><div>This is a proposal to allow operator(), operato=
r[] and operator-> to be defined as non-member functions.</div><div>I do=
not know if this has already been proposed and potential arguments against=
it, so please let me know.</div></div></blockquote><div><br>OK, first ques=
tion: what's the syntax for <i>preventing people</i> from overriding th=
ese things on my types?<br><br>These operators are pretty intimately connec=
ted to the very interfaces by which we use to interact with objects of thos=
e types. It fundamentally means something about a type that it has a functi=
on call operator on it, for example. That type is a "functor".<br=
><br>If I don't want my type to be a functor, that is my prerogative. S=
o there needs to be a way to say that I <i>don't</i> want someone to fo=
rce my type to have an interface that I didn't give it.<br><br>Indeed, =
the ability to define `operator()` from outside a class effectively means t=
hat you can insert <i>any</i>
interface into any class type you want. You'd just add an `operator()`=
=20
overload, using a tag type to differentiate which pseudo-member function
you want to call.<br><br>It seems to me that what you're trying to do =
would be best done with specialization functions, not through direct intera=
ctions with a type.<br><br></div><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"><div></div><div>The main motivation for this proposal i=
s consistency.</div></div></blockquote><div><br>That's not really good =
enough of a reason, as the inconsistency actually has a purpose. As explain=
ed above.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>It makes also easier to externally adapt existing types for =
use with generic algorithms, as show examples.</div></div></blockquote><div=
><br>Specialization functions would be the preferred way to handle that.<br=
><br></div><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"><d=
iv><br></div><div>Thank you in advance for your reviews and comments.</div>=
</div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/58241e72-ee58-4e46-897c-2bc644fa51db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58241e72-ee58-4e46-897c-2bc644fa51db=
%40isocpp.org</a>.<br />
------=_Part_645_1536795377.1498240230860--
------=_Part_644_1907623133.1498240230859--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 23 Jun 2017 15:10:15 -0400
Raw View
--001a114344862edee10552a55b79
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:
>>
>> Hello,
>>
>> This is a proposal to allow operator(), operator[] and operator-> to be
>> defined as non-member functions.
>> I do not know if this has already been proposed and potential arguments
>> against it, so please let me know.
>>
>
> OK, first question: what's the syntax for *preventing people* from
> overriding these things on my types?
>
Wanting to prevent people from doing things is a bad idea, because the
people who want to do things are living in the future of the people who
want to prevent them from doing things, and the people in the future have
better information about what they need than people in the past.
In any case, having those functions defined as non-members is no different
from having any other functions or operators that take such objects as
parameters. I don't see why operator[] should be treated differently than
operator+.
--
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/CAHSYqdbstK5OoH-b4n-kg631%3DUXyJmCa01CoZQLK%3DyQbJ3DMSQ%40mail.gmail.com.
--001a114344862edee10552a55b79
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 F=
ri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> 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 Friday, June 23, 2017 at 1:03:38 PM UTC-4, <a href=3D"mailto:jmo..=
..@aldebaran.com" target=3D"_blank">jmo...@aldebaran.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>T=
his is a proposal to allow operator(), operator[] and operator-> to be d=
efined as non-member functions.</div><div>I do not know if this has already=
been proposed and potential arguments against it, so please let me know.</=
div></div></blockquote></span><div><br>OK, first question: what's the s=
yntax for <i>preventing people</i> from overriding these things on my types=
?</div></div></blockquote><div><br>Wanting to prevent people from doing thi=
ngs is a bad idea, because the people who want to do things are living in t=
he future of the people who want to prevent them from doing things, and the=
people in the future have better information about what they need than peo=
ple in the past.<br><br>In any case, having those functions defined as non-=
members is no different from having any other functions or operators that t=
ake such objects as parameters.=C2=A0 I don't see why operator[] should=
be treated differently than operator+.</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" 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/CAHSYqdbstK5OoH-b4n-kg631%3DUXyJmCa01=
CoZQLK%3DyQbJ3DMSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbstK5O=
oH-b4n-kg631%3DUXyJmCa01CoZQLK%3DyQbJ3DMSQ%40mail.gmail.com</a>.<br />
--001a114344862edee10552a55b79--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 23 Jun 2017 21:38:49 +0200
Raw View
On 23.06.2017 19:50, Nicol Bolas wrote:
> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:
>
> Hello,
>
> This is a proposal to allow operator(), operator[] and operator-> to
> be defined as non-member functions.
> I do not know if this has already been proposed and potential
> arguments against it, so please let me know.
>
>
> OK, first question: what's the syntax for /preventing people/ from
> overriding these things on my types?
>
What's the syntax for preventing people from overloading operator+?
What's the syntax for preventing people from overloading the stream
insertion operator?
What's the syntax for preventing people from creating a free function
that does additional operation?
Granted, syntax is slightly different, but only that, plus also:
What's the syntax for preventing people from specializing some traits
for your type?
`operator()`, `operator[]` and `operator->` aren't that special, you can
do enough harm 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/57bb240d-f8ab-ad30-30fa-9def036e100d%40gmail.com.
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 23 Jun 2017 12:59:24 -0700 (PDT)
Raw View
------=_Part_602_748796744.1498247964264
Content-Type: multipart/alternative;
boundary="----=_Part_603_1632594891.1498247964264"
------=_Part_603_1632594891.1498247964264
Content-Type: text/plain; charset="UTF-8"
On Friday, June 23, 2017 at 12:03:38 PM UTC-5, jmo...@aldebaran.com wrote:
>
> The main motivation for this proposal is consistency. It makes also easier
> to externally adapt existing types for use with generic algorithms, as show
> examples.
>
The examples for non-member operator[] and operator() seem pretty
uncompelling. The first one seems like a bad algorithm (why not just pass
in a predicate instead of enforcing indexing? It'd probably be less typing
overall), the second one doesn't even directly use your operator() anywhere
- it's buried... somewhere. I think these could use much stronger examples
of cases where the best solution would be to add the overload, but we
can't, so we're left with some subpar solution. And provide before/after
examples demonstrating the improvement. Otherwise, right now it's kind
of... meh.
For operator->(), that one is fundamentally different. Either the class is
designed to be a proxy pointer/iterator... or not. What would it mean to
add operator->() to some other class? Do you have an example for wanting to
do this?
--
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/8be0ba86-e5c5-4bfb-bbb1-04e4dc109a12%40isocpp.org.
------=_Part_603_1632594891.1498247964264
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, June 23, 2017 at 12:03:38 PM UTC-5, jmo...@=
aldebaran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>The main motivation for this proposal is consistency. It make=
s also easier to externally adapt existing types for use with generic algor=
ithms, as show examples.<br></div></div></blockquote><div><br></div><div>Th=
e examples for non-member operator[] and operator() seem pretty uncompellin=
g. The first one seems like a bad algorithm (why not just pass in a predica=
te instead of enforcing indexing? It'd probably be less typing overall)=
, the second one doesn't even directly use your operator() anywhere - i=
t's buried... somewhere. I think these could use much stronger examples=
of cases where the best solution would be to add the overload, but we can&=
#39;t, so we're left with some subpar solution. And provide before/afte=
r examples demonstrating the improvement. Otherwise, right now it's kin=
d of... meh.=C2=A0</div><div><br></div><div>For operator->(), that one i=
s fundamentally different. Either the class is designed to be a proxy point=
er/iterator... or not. What would it mean to add operator->() to some ot=
her class? Do you have an example for wanting to do this?=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8be0ba86-e5c5-4bfb-bbb1-04e4dc109a12%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8be0ba86-e5c5-4bfb-bbb1-04e4dc109a12=
%40isocpp.org</a>.<br />
------=_Part_603_1632594891.1498247964264--
------=_Part_602_748796744.1498247964264--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 23 Jun 2017 14:17:58 -0700 (PDT)
Raw View
------=_Part_674_946964182.1498252678932
Content-Type: multipart/alternative;
boundary="----=_Part_675_1791535552.1498252678932"
------=_Part_675_1791535552.1498252678932
Content-Type: text/plain; charset="UTF-8"
On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen wrote:
>
> On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:
>>>
>>> Hello,
>>>
>>> This is a proposal to allow operator(), operator[] and operator-> to be
>>> defined as non-member functions.
>>> I do not know if this has already been proposed and potential arguments
>>> against it, so please let me know.
>>>
>>
>> OK, first question: what's the syntax for *preventing people* from
>> overriding these things on my types?
>>
>
> Wanting to prevent people from doing things is a bad idea, because the
> people who want to do things are living in the future of the people who
> want to prevent them from doing things, and the people in the future have
> better information about what they need than people in the past.
>
> In any case, having those functions defined as non-members is no different
> from having any other functions or operators that take such objects as
> parameters. I don't see why operator[] should be treated differently than
> operator+.
>
First, I contest the idea that `operator()` is no different from the
others. You might argue that with `->` and `[]`, but not function call. The
reason being that `operator()` has no parameter restrictions associated
with it; you can overload it with any number of parameters of any type.
`operator->` takes no parameters, and `operator[]` takes exactly one
parameter. So the damage you can cause by external overloads is minimal.
But `operator()` can take anything; you can inject entire interfaces into a
type through clever use of tag types. Overloading `operator()` from outside
a type is functionally equivalent to allowing you to add (non-friend)
member functions to a type.
Second, my principle objection is that these operations are fundamentally
part of the type. If a type is not a pointer-like type, then it has
absolutely no business overloading `operator->`. If a type is not an
array-like type, then it has no business overloading `operator[]`. And if a
type is not a function-like type, then it has no business overloading
`operator()`. And these are fundamental properties of the type; they're
*not* something you can just graft onto any old type you like.
We allow overloading `operator+` from outside of a type because we *need to*.
That allows you to add two different types. The same goes for most of the
rest of the out-of-class overloads; it permits mixing. We allow this for
prefix and postfix unary operators because... well, I have no idea why, but
I wouldn't have permitted it. Of course, the saving grace there is that it
really doesn't matter, because there can only be *one* pre/postfix overload
for each type, for each unary operator.
--
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/072af265-43c7-4b9c-8567-671d32655a8c%40isocpp.org.
------=_Part_675_1791535552.1498252678932
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"HS51cAwIAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmck...@gmail.com</a>></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>On Friday, June 23, 2017 at 1:03:38 PM UT=
C-4, <a>jmo...@aldebaran.com</a> wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Hello,<div><br></div><div>This is a proposal to allow =
operator(), operator[] and operator-> to be defined as non-member functi=
ons.</div><div>I do not know if this has already been proposed and potentia=
l arguments against it, so please let me know.</div></div></blockquote></sp=
an><div><br>OK, first question: what's the syntax for <i>preventing peo=
ple</i> from overriding these things on my types?</div></div></blockquote><=
div><br>Wanting to prevent people from doing things is a bad idea, because =
the people who want to do things are living in the future of the people who=
want to prevent them from doing things, and the people in the future have =
better information about what they need than people in the past.<br><br>In =
any case, having those functions defined as non-members is no different fro=
m having any other functions or operators that take such objects as paramet=
ers.=C2=A0 I don't see why operator[] should be treated differently tha=
n operator+.</div></div></div></div></blockquote><div><br>First, I contest =
the idea that `operator()` is no different from the others. You might argue=
that with `->` and `[]`, but not function call. The reason being that `=
operator()` has no parameter restrictions associated with it; you can overl=
oad it with any number of parameters of any type. `operator->` takes no =
parameters, and `operator[]` takes exactly one parameter. So the damage you=
can cause by external overloads is minimal.<br><br>But `operator()` can ta=
ke anything; you can inject entire interfaces into a type through clever us=
e of tag types. Overloading `operator()` from outside a type is functionall=
y equivalent to allowing you to add (non-friend) member functions to a type=
..<br><br>Second, my principle objection is that these operations are fundam=
entally part of the type. If a type is not a pointer-like type, then it has=
absolutely no business overloading `operator->`. If a type is not an ar=
ray-like type, then it has no business overloading `operator[]`. And if a t=
ype is not a function-like type, then it has no business overloading `opera=
tor()`. And these are fundamental properties of the type; they're <i>no=
t</i> something you can just graft onto any old type you like.<br><br>We al=
low overloading `operator+` from outside of a type because we <i>need to</i=
>. That allows you to add two different types. The same goes for most of th=
e rest of the out-of-class overloads; it permits mixing. We allow this for =
prefix and postfix unary operators because... well, I have no idea why, but=
I wouldn't have permitted it. Of course, the saving grace there is tha=
t it really doesn't matter, because there can only be <i>one</i> pre/po=
stfix overload for each type, for each unary operator.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/072af265-43c7-4b9c-8567-671d32655a8c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/072af265-43c7-4b9c-8567-671d32655a8c=
%40isocpp.org</a>.<br />
------=_Part_675_1791535552.1498252678932--
------=_Part_674_946964182.1498252678932--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 23 Jun 2017 18:51:20 -0400
Raw View
--94eb2c190040d52aa30552a8714f
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> So the damage you can cause
>
What makes it "damage"?
> But `operator()` can take anything; you can inject entire interfaces into
> a type through clever use of tag types. Overloading `operator()` from
> outside a type is functionally equivalent to allowing you to add
> (non-friend) member functions to a type.
>
And that could lead to dancing? What exactly is the problem here? It
makes that much of a difference to deny saying Object(a, b, c) and forcing
people to say Apply(Object, a, b, c)?
As is, a type that has a member function template makes even its private
members accessible to everyone, so privacy is dead anyway:
class X { int m; public: template <class T> void f() const { } };
class H { };
static int private_m;
template <> void X::f<H>() const { private_m = m; }
int read_m(const X &x) { x.f<H>(); return private_m; }
--
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/CAHSYqdZsZu3Zc6P-w94Jrs2pAhfzyDrcaFq-yjhsx62PSz%3DOog%40mail.gmail.com.
--94eb2c190040d52aa30552a8714f
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 F=
ri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> 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"><div>So the =
damage you can cause<br></div></div></blockquote><div><br>What makes it &qu=
ot;damage"?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>But `operator()` can take anything; you can inject entire interfa=
ces into a type through clever use of tag types. Overloading `operator()` f=
rom outside a type is functionally equivalent to allowing you to add (non-f=
riend) member functions to a type.</div></div></blockquote><div><br>And tha=
t could lead to dancing?=C2=A0 What exactly is the problem here?=C2=A0 It m=
akes that much of a difference to deny saying=C2=A0<font face=3D"monospace,=
monospace">Object(a, b, c)</font>=C2=A0and forcing people to say=C2=A0<fon=
t face=3D"monospace, monospace">Apply(Object, a, b, c)</font>?<br><br>As is=
, a type that has a member function template makes even its private members=
accessible to everyone, so privacy is dead anyway:<br><br>=C2=A0 =C2=A0 cl=
ass X { int m; public: template <class T> void f() const { } };<br>=
=C2=A0 =C2=A0 class H { };<br>=C2=A0 =C2=A0 static int private_m;<br>=C2=A0=
=C2=A0 template <> void X::f<H>() const { private_m =3D m; }<b=
r>=C2=A0 =C2=A0 int read_m(const X &x) { x.f<H>(); return private=
_m; }<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" 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/CAHSYqdZsZu3Zc6P-w94Jrs2pAhfzyDrcaFq-=
yjhsx62PSz%3DOog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZsZu3Zc6=
P-w94Jrs2pAhfzyDrcaFq-yjhsx62PSz%3DOog%40mail.gmail.com</a>.<br />
--94eb2c190040d52aa30552a8714f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 23 Jun 2017 16:40:35 -0700 (PDT)
Raw View
------=_Part_939_1558469732.1498261235371
Content-Type: multipart/alternative;
boundary="----=_Part_940_1293807109.1498261235371"
------=_Part_940_1293807109.1498261235371
Content-Type: text/plain; charset="UTF-8"
On Friday, June 23, 2017 at 6:51:43 PM UTC-4, Hyman Rosen wrote:
>
> On Fri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> So the damage you can cause
>>
>
> What makes it "damage"?
>
You have taken a type which was not a functor and made it a functor. You
have taken a type that was not array-like or pointer-like and made it
array/pointer-like.
If those are not the purpose of those types, then you have damaged that
type's interface by violating the single responsibility principle.
But `operator()` can take anything; you can inject entire interfaces into a
>> type through clever use of tag types. Overloading `operator()` from outside
>> a type is functionally equivalent to allowing you to add (non-friend)
>> member functions to a type.
>>
>
> And that could lead to dancing? What exactly is the problem here? It
> makes that much of a difference to deny saying Object(a, b, c) and
> forcing people to say Apply(Object, a, b, c)?
>
Yes! If I wanted `Object(a, b, c)` to be a meaningful interface in my
class, then *I would have put it there*.
Your logic could be just as easily used to say that we should allow anyone
to inject any member function into any class type we want. If that's what
you want, then that is what should be proposed. And if we don't want that,
then we definitely don't want `operator()` overloading, which is the
effective equivalent of it.
As is, a type that has a member function template makes even its private
> members accessible to everyone, so privacy is dead anyway:
>
No, privacy is not dead. It is still restricted to just that template.
Sure, users can specialize that template using types that didn't exist when
you wrote it. But privacy is still restricted to exactly and only those
template specializations. It doesn't go everywhere.
And even if it did, your argument is essentially that every class should be
open to injection of any member functions that anyone likes.
--
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/5515596c-18e2-4b95-a693-e3ea0f535422%40isocpp.org.
------=_Part_940_1293807109.1498261235371
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 23, 2017 at 6:51:43 PM UTC-4, Hyman Rosen =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Fri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"97GEFx0UAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmck...@gmail.com</a>></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"><div>So the damage you can cause<br></div></div=
></blockquote><div><br>What makes it "damage"?<br></div></div></d=
iv></div></blockquote><div><br>You have taken a type which was not a functo=
r and made it a functor. You have taken a type that was not array-like or p=
ointer-like and made it array/pointer-like.<br><br>If those are not the pur=
pose of those types, then you have damaged that type's interface by vio=
lating the single responsibility principle.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But `oper=
ator()` can take anything; you can inject entire interfaces into a type thr=
ough clever use of tag types. Overloading `operator()` from outside a type =
is functionally equivalent to allowing you to add (non-friend) member funct=
ions to a type.</div></div></blockquote><div><br>And that could lead to dan=
cing?=C2=A0 What exactly is the problem here?=C2=A0 It makes that much of a=
difference to deny saying=C2=A0<font face=3D"monospace, monospace">Object(=
a, b, c)</font>=C2=A0and forcing people to say=C2=A0<font face=3D"monospace=
, monospace">Apply(Object, a, b, c)</font>?<br></div></div></div></div></bl=
ockquote><div><br>Yes! If I wanted `Object(a, b, c)` to be a meaningful int=
erface in my class, then <i>I would have put it there</i>.<br><br>Your logi=
c could be just as easily used to say that we should allow anyone to inject=
any member function into any class type we want. If that's what you wa=
nt, then that is what should be proposed. And if we don't want that, th=
en we definitely don't want `operator()` overloading, which is the effe=
ctive equivalent of it.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>As is, a type =
that has a member function template makes even its private members accessib=
le to everyone, so privacy is dead anyway:<br></div></div></div></div></blo=
ckquote><div><br>No, privacy is not dead. It is still restricted to just th=
at template. Sure, users can specialize that template using types that didn=
't exist when you wrote it. But privacy is still restricted to exactly =
and only those template specializations. It doesn't go everywhere.</div=
><br>And even if it did, your argument is essentially that every class shou=
ld be open to injection of any member functions that anyone likes.<br></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5515596c-18e2-4b95-a693-e3ea0f535422%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5515596c-18e2-4b95-a693-e3ea0f535422=
%40isocpp.org</a>.<br />
------=_Part_940_1293807109.1498261235371--
------=_Part_939_1558469732.1498261235371--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 23 Jun 2017 17:22:48 -0700
Raw View
--001a1149d4bee885260552a9b8c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 23 June 2017 at 10:03, <jmonnon@aldebaran.com> wrote:
> Hello,
>
> This is a proposal to allow operator(), operator[] and operator-> to be
> defined as non-member functions.
> I do not know if this has already been proposed and potential arguments
> against it, so please let me know.
>
> The main motivation for this proposal is consistency. It makes also easie=
r
> to externally adapt existing types for use with generic algorithms, as sh=
ow
> examples.
>
Overloading operator-> would mean that there can be a set of possible
operator-> functions for a single type, with different return types. What
do you expect to happen there? Should the selected operator-> depend on
whether the type contains the named member? (You might like to look at the
'operator.' wording to get some idea of how complicated this can become.)
Overloading operator() sounds like it would potentially lead to a much more
expensive overload resolution process for potentially every function call
in the program, unless it's handled very carefully. For instance, someone
is going to write something like this:
template<typename R, typename ...T, typename ...U,
enable_if<each_U_is_either_T_or_optional_T<list<T...>,
list<U...>>::value, int> =3D 0>
optional<R> operator()(R(*f)(T...), U &&...u) {
/* if any u's are nullopt, return nullopt, otherwise return
f(unwrap(forward<U>(u))) */
}
.... in order to allow:
optional<int> a, b;
int f(int x, int y);
optional<int> c =3D f(a, b); // implicitly use ::operator() here, only ca=
ll
'f' if neither 'a' nor 'b' is nullopt
.... and likewise for a bunch of other templates that are functors in the
category theory sense.
And now we potentially have a large number of operator() overloads to
consider for every single function call, and considering each of them
requires some nontrivial template instantiation work.
Overloading operator[] seems fine, though. It's just a normal binary
operator with slightly funny syntax, after all.
> Thank you in advance for your reviews and comments.
>
>
>
>
> *This email and any attachment thereto are confidential and intended
> solely for the use of the individual or entity to whom they are
> addressed.If you are not the intended recipient, please be advised that
> disclosing, copying, distributing or taking any action in reliance on the
> contents of this email is strictly prohibited. In such case, please
> immediately advise the sender, and delete all copies and attachment from
> your system.This email shall not be construed and is not tantamount to an
> offer, an acceptance of offer, or an agreement by SoftBank Robotics Europ=
e
> on any discussion or contractual document whatsoever. No employee or agen=
t
> is authorized to represent or bind SoftBank Robotics Europe to third
> parties by email, or act on behalf of SoftBank Robotics Europe by email,
> without express written confirmation by SoftBank Robotics Europe=E2=80=99=
duly
> authorized representatives.*
> ------------------------------
>
>
>
>
> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes son=
t confidentiels,
> et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0=
qui ils sont
> adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas
> divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi d=
e ce
> message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=
=A9diteur et de
> supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de vo=
tre
> syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une =
offre, =C3=A0 une
> acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Eur=
ope sur toute
> discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =
=C3=AAtre
> interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank R=
obotics Europe
> n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=
=A9t=C3=A9 par email, ou =C3=A0 agir
> au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation
> =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftB=
ank Robotics Europe ou
> par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir =
appropri=C3=A9e.*
>
> --
> 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/8bd2a86c-2b01-491b-
> 8ee9-30d78aa4b35e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b=
01-491b-8ee9-30d78aa4b35e%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/CAOfiQqnSxuzzqhefD3wcawuY%2B2PiDVOj3D3h41HYHLafk=
u2sTQ%40mail.gmail.com.
--001a1149d4bee885260552a9b8c1
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 2=
3 June 2017 at 10:03, <span dir=3D"ltr"><<a href=3D"mailto:jmonnon@alde=
baran.com" target=3D"_blank">jmonnon@aldebaran.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>=
This is a proposal to allow operator(), operator[] and operator-> to be =
defined as non-member functions.</div><div>I do not know if this has alread=
y been proposed and potential arguments against it, so please let me know.<=
/div><div><br></div><div>The main motivation for this proposal is consisten=
cy. It makes also easier to externally adapt existing types for use with ge=
neric algorithms, as show examples.</div></div></blockquote><div><br></div>=
<div>Overloading operator-> would mean that there can be a set of possib=
le operator-> functions for a single type, with different return types. =
What do you expect to happen there? Should the selected operator-> depen=
d on whether the type contains the named member? (You might like to look at=
the 'operator.' wording to get some idea of how complicated this c=
an become.)</div><div><br></div><div>Overloading operator() sounds like it =
would potentially lead to a much more expensive overload resolution process=
for potentially every function call in the program, unless it's handle=
d very carefully. For instance, someone is going to write something like th=
is:</div><div><br></div><div>=C2=A0 template<typename R, typename ...T, =
typename ...U,</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable_if=
<each_U_is_either_T_or_optional_T<list<T...>, list<U...>&=
gt;::value, int> =3D 0></div><div>=C2=A0 optional<R> operator()=
(R(*f)(T...), U &&...u) {</div><div>=C2=A0 =C2=A0 /* if any u's=
are nullopt, return nullopt, otherwise return f(unwrap(forward<U>(u)=
)) */</div><div>=C2=A0 }</div><div><br></div><div>... in order to allow:</d=
iv><div><br></div><div>=C2=A0 optional<int> a, b;</div><div>=C2=A0 in=
t f(int x, int y);</div><div>=C2=A0 optional<int> c =3D f(a, b); // i=
mplicitly use ::operator() here, only call 'f' if neither 'a=
9; nor 'b' is nullopt</div><div><br></div><div>... and likewise for=
a bunch of other templates that are functors in the category theory sense.=
</div><div><br></div><div>And now we potentially have a large number of ope=
rator() overloads to consider for every single function call, and consideri=
ng each of them requires some nontrivial template instantiation work.</div>=
<div><br></div><div>Overloading operator[] seems fine, though. It's jus=
t a normal binary operator with slightly funny syntax, after all.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Thank you=
in advance for your reviews and comments.</div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<span class=
=3D"HOEnZb"><font color=3D"#888888"><br></font></span></i></font></p><span =
class=3D"HOEnZb"><font color=3D"#888888"><p style=3D"margin:0px"><font colo=
r=3D"#808080" size=3D"1"><i></i></font></p></font></span><p></p><span class=
=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8bd2=
a86c-2b01-491b-<wbr>8ee9-30d78aa4b35e%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></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" 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/CAOfiQqnSxuzzqhefD3wcawuY%2B2PiDVOj3D=
3h41HYHLafku2sTQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSxuzzqh=
efD3wcawuY%2B2PiDVOj3D3h41HYHLafku2sTQ%40mail.gmail.com</a>.<br />
--001a1149d4bee885260552a9b8c1--
.
Author: jmonnon@aldebaran.com
Date: Sat, 24 Jun 2017 09:26:52 -0700 (PDT)
Raw View
------=_Part_1117_288644718.1498321612845
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le vendredi 23 juin 2017 21:59:24 UTC+2, Barry Revzin a =C3=A9crit :
>
>
> On Friday, June 23, 2017 at 12:03:38 PM UTC-5, jmo...@aldebaran.com wrote=
:
>>
>> The main motivation for this proposal is consistency. It makes also=20
>> easier to externally adapt existing types for use with generic algorithm=
s,=20
>> as show examples.
>>
>
> The examples for non-member operator[] and operator() seem pretty=20
> uncompelling. The first one seems like a bad algorithm (why not just pass=
=20
> in a predicate instead of enforcing indexing? It'd probably be less typin=
g=20
> overall), the second one doesn't even directly use your operator() anywhe=
re=20
> - it's buried... somewhere. I think these could use much stronger example=
s=20
> of cases where the best solution would be to add the overload, but we=20
> can't, so we're left with some subpar solution. And provide before/after=
=20
> examples demonstrating the improvement. Otherwise, right now it's kind=20
> of... meh.=20
>
About the first example, you could also use operator[] to modify / create=
=20
an element =C3=A0 la std::map. In this case, a predicate would not be enoug=
h.=20
`[]` could be used as a "standard" way to access an element. But in the=20
current state of the language, while designing a concept it is best to=20
avoid relying on [] and (), if you want your concepts to be as easy to=20
model as possible: if operator() and operator[] were not defined by the=20
creator of a type, modeling the concept implies to duplicate the type (and=
=20
its interface) and to add the operators. This is too much work compared to=
=20
be able to define these operators as non-members.
So when designing concepts, an alternative is to use free functions (at()=
=20
and call() for example), which is less natural, less concise and not=20
compatible with builtin types.
The second example relies on function composition. If you don't have=20
function objects, your function composition tools are unusable... Having to=
=20
duplicate types instead of slightly adapting them is too bad, especially=20
when you can do so with other operators.=20
>
> For operator->(), that one is fundamentally different. Either the class i=
s=20
> designed to be a proxy pointer/iterator... or not. What would it mean to=
=20
> add operator->() to some other class? Do you have an example for wanting =
to=20
> do this?=20
>
Currently, it is possible to implement operator* as a non-member but not=20
operator->, which seems strange.
You often have types with methods get(), load(), value(), etc. An=20
interesting syntax unification is to provide operator* for these types,=20
that just forward to get() / load() / value(). Then, if you have operator*=
=20
that returns an l-value, why not having operator-> ? It would allow to have=
=20
the syntax (*my_object).method() equivalent to my_object->method(), as=20
expected.
Here is another example of adapting an existing type with non-member=20
operators. This one is currently possible, since it uses arithmetical=20
operators:
The creator of a type is responsible for the interface she provides.
But the user can decide that in her context some operators not provided by=
=20
the creator of the type are meaningful.
For example, std::array forms a mathematical vector space with most=20
arithmetical types. Roughly speaking, this means that an std::array can=20
represent a mathematical vector and we just have to choose an appropriate=
=20
scalar type.
std::array has already the right behavior (value semantics, etc.), except=
=20
for the absence of arithmetical operators (+, *, etc.).
The user can't modify std::array definition, but she can add these=20
operators as non-members.
For example:
// In the user's context, adaptation of std::array to model the VectorSpace=
=20
concept.
// AdditiveSemigroup T
template<typename T, std::size_t N>
auto operator+(std::array<T, N> a, std::array<T, N> const& b) {
std::transform(begin(a), end(a), begin(b), begin(a), std::plus<T>{});
return a;
}
// VectorSpace (T, S) (T is the vector type, S is the scalar type)
template<typename S, typename T, std::size_t N>
auto operator*(S const& s, std::array<T, N> a) {
std::transform(begin(a), end(a), begin(a), [=3D](auto const& x) {
return s * x;
});
return a;
}
The user can also add @=3D versions (+=3D, *=3D, etc.) for efficiency reaso=
ns.
Now the user can use std::array as a vector space in her generic algorithms=
..
The amount of work is minimal because of the possibility to define
non-member operators.
For example (std::array<float, N>, int) forms a vector space.
So if v0, v1 are std::array<float, N> and k is an int, this kind of
expression is valid:
auto v2 =3D k * (v0 + v1);
Types are tools to be used by the user in whatever way makes sense in her=
=20
context.
The creator of a type cannot imagine all these contexts, and shouldn't=20
artificially
limit the user's possibilities.
C++ has the right approach concerning most operators (+, -, etc.), so why=
=20
operator(), operator[] and operator-> should be exceptions?
Whatever the quality of the examples, I see this proposal as a way to fix=
=20
an anomaly in the language.
In my opinion, in the design of the language consistency should be the=20
default, and each non-consistent behavior should be motivated, not the=20
opposite.
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
--=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/7a6059d7-4dcb-4703-8b45-dd2590a5a19b%40isocpp.or=
g.
------=_Part_1117_288644718.1498321612845
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le vendredi 23 juin 2017 21:59:24 UTC+2, Barry Rev=
zin a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><br>On Friday, June 23, 2017 at 12:03:38 PM UTC-5, <a>jmo...@alde=
baran.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>The main motivation for this proposal is consistency. It makes also =
easier to externally adapt existing types for use with generic algorithms, =
as show examples.<br></div></div></blockquote><div><br></div><div>The examp=
les for non-member operator[] and operator() seem pretty uncompelling. The =
first one seems like a bad algorithm (why not just pass in a predicate inst=
ead of enforcing indexing? It'd probably be less typing overall), the s=
econd one doesn't even directly use your operator() anywhere - it's=
buried... somewhere. I think these could use much stronger examples of cas=
es where the best solution would be to add the overload, but we can't, =
so we're left with some subpar solution. And provide before/after examp=
les demonstrating the improvement. Otherwise, right now it's kind of...=
meh.=C2=A0</div></div></blockquote><div><br>About the first example, you c=
ould also use operator[] to modify / create an element =C3=A0 la std::map. =
In this case, a predicate would not be enough. `[]` could be used as a &quo=
t;standard" way to access an element. But in the current state of the =
language, while designing a concept it is best to avoid relying on [] and (=
), if you want your concepts to be as easy to model as possible: if operato=
r() and operator[] were not defined by the creator of a type, modeling the =
concept implies to duplicate the type (and its interface) and to add the op=
erators. This is too much work compared to be able to define these operator=
s as non-members.<br>So when designing concepts, an alternative is to use f=
ree functions (at() and call() for example), which is less natural, less co=
ncise and not compatible with builtin types.<br><br>The second example reli=
es on function composition. If you don't have function objects, your fu=
nction composition tools are unusable... Having to duplicate types instead =
of slightly adapting them is too bad, especially when you can do so with ot=
her operators. <br></div><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"><div><br></div><div>For operator->(), that one is fundamenta=
lly different. Either the class is designed to be a proxy pointer/iterator.=
... or not. What would it mean to add operator->() to some other class? D=
o you have an example for wanting to do this?=C2=A0</div></div></blockquote=
><div><br>Currently, it is possible to implement operator* as a non-member =
but not operator->, which seems strange.<br>You often have types with me=
thods get(), load(), value(), etc. An interesting syntax unification is to =
provide operator* for these types, that just forward to get() / load() / va=
lue(). Then, if you have operator* that returns an l-value, why not having =
operator-> ? It would allow to have the syntax (*my_object).method() equ=
ivalent to my_object->method(), as expected.<br><br><br>Here is another =
example of adapting an existing type with non-member operators. This one is=
currently possible, since it uses arithmetical operators:<br><br>The creat=
or of a type is responsible for the interface she provides.<br>But the user=
can decide that in her context some operators not provided by the creator =
of the type are meaningful.<br>For example, std::array forms a mathematical=
vector space with most arithmetical types. Roughly speaking, this means th=
at an std::array can represent a mathematical vector and we just have to ch=
oose an appropriate scalar type.<br>std::array has already the right behavi=
or (value semantics, etc.), except for the absence of arithmetical operator=
s (+, *, etc.).<br>The user can't modify std::array definition, but she=
can add these operators as non-members.<br>For example:<br><br>// In the u=
ser's context, adaptation of std::array to model the VectorSpace concep=
t.<br><br>// AdditiveSemigroup T<br>template<typename T, std::size_t N&g=
t;<br>auto operator+(std::array<T, N> a, std::array<T, N> const=
& b) {<br>=C2=A0=C2=A0=C2=A0 std::transform(begin(a), end(a), begin(b),=
begin(a), std::plus<T>{});<br>=C2=A0=C2=A0=C2=A0 return a;<br>}<br><=
br>// VectorSpace (T, S) (T is the vector type, S is the scalar type)<br>te=
mplate<typename S, typename T, std::size_t N><br>auto operator*(S con=
st& s, std::array<T, N> a) {<br>=C2=A0=C2=A0=C2=A0 std::transform=
(begin(a), end(a), begin(a), [=3D](auto const& x) {<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 return s * x;<br>=C2=A0=C2=A0=C2=A0 });<br>=C2=
=A0=C2=A0=C2=A0 return a;<br>}<br><br>The user can also add @=3D versions (=
+=3D, *=3D, etc.) for efficiency reasons.<br><br>Now the user can use std::=
array as a vector space in her generic algorithms.<br>The amount of work is=
minimal because of the possibility to define<br>non-member operators.<br><=
br>For example (std::array<float, N>, int) forms a vector space.<br>S=
o if v0, v1 are std::array<float, N> and k is an int, this kind of<br=
>expression is valid:<br><br>auto v2 =3D k * (v0 + v1);<br><br>Types are to=
ols to be used by the user in whatever way makes sense in her context.<br>T=
he creator of a type cannot imagine all these contexts, and shouldn't a=
rtificially<br>limit the user's possibilities.<br>C++ has the right app=
roach concerning most operators (+, -, etc.), so why operator(), operator[]=
and operator-> should be exceptions?<br><br>Whatever the quality of the=
examples, I see this proposal as a way to fix an anomaly in the language.<=
br>In my opinion, in the design of the language consistency should be the d=
efault, and each non-consistent behavior should be motivated, not the oppos=
ite.<br></div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous=
=C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d'en=
aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes les=
copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7a6059d7-4dcb-4703-8b45-dd2590a5a19b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a6059d7-4dcb-4703-8b45-dd2590a5a19b=
%40isocpp.org</a>.<br />
------=_Part_1117_288644718.1498321612845--
.
Author: jmonnon@aldebaran.com
Date: Sat, 24 Jun 2017 09:47:04 -0700 (PDT)
Raw View
------=_Part_1255_882655323.1498322824875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le samedi 24 juin 2017 02:23:10 UTC+2, Richard Smith a =C3=A9crit :
>
> On 23 June 2017 at 10:03, <jmo...@aldebaran.com <javascript:>> wrote:
>
>> Hello,
>>
>> This is a proposal to allow operator(), operator[] and operator-> to be=
=20
>> defined as non-member functions.
>> I do not know if this has already been proposed and potential arguments=
=20
>> against it, so please let me know.
>>
>> The main motivation for this proposal is consistency. It makes also=20
>> easier to externally adapt existing types for use with generic algorithm=
s,=20
>> as show examples.
>>
>
> Overloading operator-> would mean that there can be a set of possible=20
> operator-> functions for a single type, with different return types. What=
=20
> do you expect to happen there? Should the selected operator-> depend on=
=20
> whether the type contains the named member? (You might like to look at th=
e=20
> 'operator.' wording to get some idea of how complicated this can become.)
>
Currently, operator-> must be defined as a non-static member function=20
taking no parameters (16.5.6) . The non-member form would take a single=20
argument evaluating to a class object, so there would be only one version=
=20
by type, if I understand correctly.
>
> Overloading operator() sounds like it would potentially lead to a much=20
> more expensive overload resolution process for potentially every function=
=20
> call in the program, unless it's handled very carefully. For instance,=20
> someone is going to write something like this:
>
> template<typename R, typename ...T, typename ...U,
> enable_if<each_U_is_either_T_or_optional_T<list<T...>,=20
> list<U...>>::value, int> =3D 0>
> optional<R> operator()(R(*f)(T...), U &&...u) {
> /* if any u's are nullopt, return nullopt, otherwise return=20
> f(unwrap(forward<U>(u))) */
> }
>
> ... in order to allow:
>
> optional<int> a, b;
> int f(int x, int y);
> optional<int> c =3D f(a, b); // implicitly use ::operator() here, only=
=20
> call 'f' if neither 'a' nor 'b' is nullopt
>
> ... and likewise for a bunch of other templates that are functors in the=
=20
> category theory sense.
>
> And now we potentially have a large number of operator() overloads to=20
> consider for every single function call, and considering each of them=20
> requires some nontrivial template instantiation work.
>
> I'm not sure if this example work (f is not a member function for example=
).
Anyway, it would be the user responsibility to add or not such an overload.=
=20
And it is already possible to seriously slow down compilation by providing=
=20
a bunch of template "enabled-if" operators (+, -, <<, and the others).
=20
> Overloading operator[] seems fine, though. It's just a normal binary=20
> operator with slightly funny syntax, after all.
> =20
>
>> Thank you in advance for your reviews and comments.
>>
>>
>>
>>
>> *This email and any attachment thereto are confidential and intended=20
>> solely for the use of the individual or entity to whom they are=20
>> addressed.If you are not the intended recipient, please be advised that=
=20
>> disclosing, copying, distributing or taking any action in reliance on th=
e=20
>> contents of this email is strictly prohibited. In such case, please=20
>> immediately advise the sender, and delete all copies and attachment from=
=20
>> your system.This email shall not be construed and is not tantamount to a=
n=20
>> offer, an acceptance of offer, or an agreement by SoftBank Robotics Euro=
pe=20
>> on any discussion or contractual document whatsoever. No employee or age=
nt=20
>> is authorized to represent or bind SoftBank Robotics Europe to third=20
>> parties by email, or act on behalf of SoftBank Robotics Europe by email,=
=20
>> without express written confirmation by SoftBank Robotics Europe=E2=80=
=99 duly=20
>> authorized representatives.*
>> ------------------------------
>>
>>
>>
>>
>> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes so=
nt=20
>> confidentiels, et exclusivement destin=C3=A9s =C3=A0 la personne ou l'en=
tit=C3=A9 =C3=A0 qui=20
>> ils sont adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9=
, vous =C3=AAtes pri=C3=A9=20
>> de ne pas divulguer, copier, distribuer ou prendre toute d=C3=A9cision s=
ur la=20
>> foi de ce message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatemen=
t=20
>> l'exp=C3=A9diteur et de supprimer toutes les copies et =C3=A9ventuelles =
pi=C3=A8ces=20
>> jointes de votre syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quiva=
ut pas =C3=A0 une=20
>> offre, =C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de So=
ftBank Robotics=20
>> Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne=20
>> peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou age=
nt de SoftBank Robotics=20
>> Europe n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la =
soci=C3=A9t=C3=A9 par email, ou =C3=A0=20
>> agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=
=E2=80=99une=20
>> confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=
=A9gal de SoftBank=20
>> Robotics Europe ou par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=
=A9gation de=20
>> pouvoir appropri=C3=A9e.*
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b=
01-491b-8ee9-30d78aa4b35e%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2=
b01-491b-8ee9-30d78aa4b35e%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
--=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/1ff81804-737c-4999-a27b-8e10608de2cb%40isocpp.or=
g.
------=_Part_1255_882655323.1498322824875
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le samedi 24 juin 2017 02:23:10 UTC+2, Richard Smi=
th a =C3=A9crit=C2=A0:<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"><div><div class=3D"gmail_quote">On 23 June 2017 at 10:03, <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"zc9qtBoZAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">jmo...@aldebaran.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>This is a proposal=
to allow operator(), operator[] and operator-> to be defined as non-mem=
ber functions.</div><div>I do not know if this has already been proposed an=
d potential arguments against it, so please let me know.</div><div><br></di=
v><div>The main motivation for this proposal is consistency. It makes also =
easier to externally adapt existing types for use with generic algorithms, =
as show examples.</div></div></blockquote><div><br></div><div>Overloading o=
perator-> would mean that there can be a set of possible operator-> f=
unctions for a single type, with different return types. What do you expect=
to happen there? Should the selected operator-> depend on whether the t=
ype contains the named member? (You might like to look at the 'operator=
..' wording to get some idea of how complicated this can become.)</div><=
/div></div></div></blockquote><div><br>Currently, operator-> must be def=
ined as a non-static member function taking no parameters (16.5.6) . The no=
n-member form would take a single argument evaluating to a class object, so=
there would be only one version by type, if I understand correctly.<br></d=
iv><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"><div><div =
class=3D"gmail_quote"><div><br></div><div>Overloading operator() sounds lik=
e it would potentially lead to a much more expensive overload resolution pr=
ocess for potentially every function call in the program, unless it's h=
andled very carefully. For instance, someone is going to write something li=
ke this:</div><div><br></div><div>=C2=A0 template<typename R, typename .=
...T, typename ...U,</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enab=
le_if<each_U_is_either_T_<wbr>or_optional_T<list<T...>, list<=
;U...>>::value, int> =3D 0></div><div>=C2=A0 optional<R> =
operator()(R(*f)(T...), U &&...u) {</div><div>=C2=A0 =C2=A0 /* if a=
ny u's are nullopt, return nullopt, otherwise return f(unwrap(forward&l=
t;U>(u))) */</div><div>=C2=A0 }</div><div><br></div><div>... in order to=
allow:</div><div><br></div><div>=C2=A0 optional<int> a, b;</div><div=
>=C2=A0 int f(int x, int y);</div><div>=C2=A0 optional<int> c =3D f(a=
, b); // implicitly use ::operator() here, only call 'f' if neither=
'a' nor 'b' is nullopt</div><div><br></div><div>... and li=
kewise for a bunch of other templates that are functors in the category the=
ory sense.</div><div><br></div><div>And now we potentially have a large num=
ber of operator() overloads to consider for every single function call, and=
considering each of them requires some nontrivial template instantiation w=
ork.</div><div><br></div></div></div></div></blockquote><div>I'm not su=
re if this example work (f is not a member function for example).<br>Anyway=
, it would be the user responsibility to add or not such an overload. And i=
t is already possible to seriously slow down compilation by providing a bun=
ch of template "enabled-if" operators (+, -, <<, and the ot=
hers).<br></div><div>=C2=A0</div><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"><div><div class=3D"gmail_quote"><div></div><div>Overloa=
ding operator[] seems fine, though. It's just a normal binary operator =
with slightly funny syntax, after all.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Thank you in advance for your review=
s and comments.</div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font size=3D"1" color=3D"#808080">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font size=3D"1" color=3D"#808080"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<span><font c=
olor=3D"#888888"><br></font></span></i></font></p><span><font color=3D"#888=
888"><p style=3D"margin:0px"><font size=3D"1" color=3D"#808080"><i></i></fo=
nt></p></font></span><p></p><span><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
zc9qtBoZAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"zc9qtBoZAQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8bd2a86c-2b01-491b-<wbr>8ee9-=
30d78aa4b35e%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous=
=C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d'en=
aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes les=
copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1ff81804-737c-4999-a27b-8e10608de2cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ff81804-737c-4999-a27b-8e10608de2cb=
%40isocpp.org</a>.<br />
------=_Part_1255_882655323.1498322824875--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Jun 2017 10:47:45 -0700 (PDT)
Raw View
------=_Part_1034_11450154.1498326465346
Content-Type: multipart/alternative;
boundary="----=_Part_1035_1183925390.1498326465346"
------=_Part_1035_1183925390.1498326465346
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, June 24, 2017 at 12:26:52 PM UTC-4, jmo...@aldebaran.com wrote=
:
>
> Le vendredi 23 juin 2017 21:59:24 UTC+2, Barry Revzin a =C3=A9crit :
>>
>>
>> On Friday, June 23, 2017 at 12:03:38 PM UTC-5, jmo...@aldebaran.com=20
>> wrote:
>>>
>>> The main motivation for this proposal is consistency. It makes also=20
>>> easier to externally adapt existing types for use with generic algorith=
ms,=20
>>> as show examples.
>>>
>>
>> The examples for non-member operator[] and operator() seem pretty=20
>> uncompelling. The first one seems like a bad algorithm (why not just pas=
s=20
>> in a predicate instead of enforcing indexing? It'd probably be less typi=
ng=20
>> overall), the second one doesn't even directly use your operator() anywh=
ere=20
>> - it's buried... somewhere. I think these could use much stronger exampl=
es=20
>> of cases where the best solution would be to add the overload, but we=20
>> can't, so we're left with some subpar solution. And provide before/after=
=20
>> examples demonstrating the improvement. Otherwise, right now it's kind=
=20
>> of... meh.=20
>>
>
> About the first example, you could also use operator[] to modify / create=
=20
> an element =C3=A0 la std::map. In this case, a predicate would not be eno=
ugh.=20
> `[]` could be used as a "standard" way to access an element.
>
To access an element of what? You couldn't use it to access an element from=
=20
`list`, or from any of the `set`s.
The rules that STL devised for interfaces give `operator[]` a special=20
meaning for sequence containers. It means that access to the element is=20
(amortized) O(1). If a container cannot fulfill that promise, then it ought=
=20
not provide `operator[]`.
That operator is not meant to be a catch-all means of "accessing an=20
element". Trying to use it that way is a *bad thing*.
We already have ways of accessing the i-th element of a forward range: you=
=20
use iterators and `std::advance`. This is a good thing, because it allows=
=20
different types to exhibit the behavior that works best for them.
But in the current state of the language, while designing a concept it is=
=20
> best to avoid relying on [] and (), if you want your concepts to be as ea=
sy=20
> to model as possible: if operator() and operator[] were not defined by th=
e=20
> creator of a type,
>
Why did the creator of the type *not* implement `operator[]`? Was it=20
because the access would not be O(1), and therefore the type *shouldn't* be=
=20
used with algorithms that expect O(1) access? Why do you assume that the=20
lack of `operator[]` was an accident or oversight, rather than a deliberate=
=20
piece of design to prevent people from thinking of the operation=20
incorrectly?
modeling the concept implies to duplicate the type (and its interface) and=
=20
> to add the operators. This is too much work compared to be able to define=
=20
> these operators as non-members.
> So when designing concepts, an alternative is to use free functions (at()=
=20
> and call() for example), which is less natural, less concise and not=20
> compatible with builtin types.
>
What concepts are you talking about? Range TS, the largest body of concepts=
=20
before the standard committee, includes no such thing. The closest it gets=
=20
is Invocable, which relies on the definition of `std::invoke`. And the only=
=20
reason Invocable it doesn't use `()` specifically is because `()` doesn't=
=20
work on member pointers (which is why `std::invoke` exists in the first=20
place). An object with a `call()` function is not Invocable. And=20
`std::invoke` is not meant to be a customization point.
Can you give an example of such a concept? One that fits into the standard=
=20
C++ paradigm?
The second example relies on function composition. If you don't have=20
> function objects, your function composition tools are unusable... Having =
to=20
> duplicate types instead of slightly adapting them is too bad, especially=
=20
> when you can do so with other operators.
>
If a type is not a functor, then how would you "adapt it" to an interface=
=20
that accepts functors? If that type wasn't a functor, then it presumably=20
has quite a few operations that you might want to call. How do you decide=
=20
*which* operation you want to call in the `operator()` overload?
And how do you prevent conflicts? If generic system inserts its=20
`operator()` overload for one operation, what happens when another system=
=20
inserts another `operator()` overload into the type which happens to match=
=20
the call signature? Or are they expected to use tag types to differentiate=
=20
their particular calls?
At which point, there is fundamentally *no difference* between overloading=
=20
`operator()` and simply inserting arbitrary functions into a class's member=
=20
function list.
Also, why is there a need to duplicate a type to do composition? Lambdas=20
can handle that adequately enough. After all, you're picking a single=20
function to call anyway, and that determination is made at the point where=
=20
you need to use it. This works a lot better as a lambda than by creating a=
=20
type and forwarding functions. After all, your functor doesn't need to=20
expose everything the type does; only that one specific operation.
>> For operator->(), that one is fundamentally different. Either the class=
=20
>> is designed to be a proxy pointer/iterator... or not. What would it mean=
to=20
>> add operator->() to some other class? Do you have an example for wanting=
to=20
>> do this?=20
>>
>
> Currently, it is possible to implement operator* as a non-member but not=
=20
> operator->, which seems strange.
>
Well yes; we ought to have forbidden that too. But the deed is done;=20
there's no reason to compound the mistake just for the sake of consistency.
You often have types with methods get(), load(), value(), etc. An=20
> interesting syntax unification is to provide operator* for these types,=
=20
> that just forward to get() / load() / value().
>
Yes, that is very interesting. It's also a very bad idea. Most types that=
=20
implement operator* don't throw exceptions if the value isn't there.=20
`optional::value` does. As such, it is *important* that readers of the code=
=20
see `value`, since that represents a possible site of an exception. By=20
contrast, `optional::operator*` does not throw exceptions. So `::value` and=
=20
`::operator*` are not the same thing at all.
And `std::future` is a great example of why. It does not have an=20
`operator*`. Why? Because the act of calling `get` may throw an exception;=
=20
the ability to pass exceptions through `promise`/`future`s is an important=
=20
feature. And since `operator*` isn't supposed to throw exceptions, there is=
=20
no such overload.
Now, users could write an `operator*` for `std::future`. How exactly would=
=20
you implement this? Would you call `future::get` and let its exception=20
bubble up, in violation of the expectation of `operator*`? Would you call=
=20
`future::get` and swallow any exceptions? If it's the latter, how do you=20
construct the return value if an exception manifests? And so forth.
The idea that you can force all of these things into the same `operator*`=
=20
or `operator->` box is decidedly reductive.
Then, if you have operator* that returns an l-value, why not having=20
> operator-> ? It would allow to have the syntax (*my_object).method()=20
> equivalent to my_object->method(), as expected.
>
>
> Here is another example of adapting an existing type with non-member=20
> operators. This one is currently possible, since it uses arithmetical=20
> operators:
>
> The creator of a type is responsible for the interface she provides.
> But the user can decide that in her context some operators not provided b=
y=20
> the creator of the type are meaningful.
> For example, std::array forms a mathematical vector space with most=20
> arithmetical types. Roughly speaking, this means that an std::array can=
=20
> represent a mathematical vector and we just have to choose an appropriate=
=20
> scalar type.
> std::array has already the right behavior (value semantics, etc.), except=
=20
> for the absence of arithmetical operators (+, *, etc.).
> The user can't modify std::array definition, but she can add these=20
> operators as non-members.
> For example:
> =20
>
<snip>
> The user can also add @=3D versions (+=3D, *=3D, etc.) for efficiency rea=
sons.
>
> Now the user can use std::array as a vector space in her generic=20
> algorithms.
> The amount of work is minimal because of the possibility to define
> non-member operators.
>
Yes, and this is a *terrible idea*. Why? Because it creates a huge mess of=
=20
the meaning of the type system.
An array is not conceptually an addable thing. Therefore, `std::array`,=20
which models the concept of an array, is not a thing that should be=20
addable. A mathematical vector is conceptually an addable thing. Therefore,=
=20
a type implementing that concept should be addable.
Now, that vector type may in fact be implemented in terms of `array`;=20
that's fine. But there's a difference between saying that an array is an=20
implementation detail of a vector and that all arrays *are vectors*. Not=20
every array is a vector, and therefore not every array should be able to be=
=20
treated as if it were a vector.
What you're doing is a violation of the Interface Segregation Principle=20
<https://en.wikipedia.org/wiki/Interface_segregation_principle>; it's the=
=20
generic programming equivalent of a fat interface base class. You make=20
every array conceptually a vector, even if the user doesn't want or need it=
=20
to be a vector.
We should not promote coding styles that violate things like this. We allow=
=20
the extension of binary math operators outside of a class, not because we=
=20
want people to inject their interfaces into other people's classes, but to=
=20
allow for two different types to be addable. To allow adding scalars and=20
vectors, for example.
This is not a tool that should be used to make a class which is not=20
conceptually addable into one that is.
--=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/7082d763-15f9-4bfa-b564-64b2442997aa%40isocpp.or=
g.
------=_Part_1035_1183925390.1498326465346
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 24, 2017 at 12:26:52 PM UTC-4, jmo...@al=
debaran.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Le vendredi 23 juin 2017 21:59:24 UTC+2, Barry Revzin a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Friday,=
June 23, 2017 at 12:03:38 PM UTC-5, <a>jmo...@aldebaran.com</a> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The main motivati=
on for this proposal is consistency. It makes also easier to externally ada=
pt existing types for use with generic algorithms, as show examples.<br></d=
iv></div></blockquote><div><br></div><div>The examples for non-member opera=
tor[] and operator() seem pretty uncompelling. The first one seems like a b=
ad algorithm (why not just pass in a predicate instead of enforcing indexin=
g? It'd probably be less typing overall), the second one doesn't ev=
en directly use your operator() anywhere - it's buried... somewhere. I =
think these could use much stronger examples of cases where the best soluti=
on would be to add the overload, but we can't, so we're left with s=
ome subpar solution. And provide before/after examples demonstrating the im=
provement. Otherwise, right now it's kind of... meh.=C2=A0</div></div><=
/blockquote><div><br>About the first example, you could also use operator[]=
to modify / create an element =C3=A0 la std::map. In this case, a predicat=
e would not be enough. `[]` could be used as a "standard" way to =
access an element.</div></div></blockquote><div><br>To access an element of=
what? You couldn't use it to access an element from `list`, or from an=
y of the `set`s.<br><br>The rules that STL devised for interfaces give `ope=
rator[]` a special meaning for sequence containers. It means that access to=
the element is (amortized) O(1). If a container cannot fulfill that promis=
e, then it ought not provide `operator[]`.<br><br>That operator is not mean=
t to be a catch-all means of "accessing an element". Trying to us=
e it that way is a <i>bad thing</i>.<br><br>We already have ways of accessi=
ng the i-th element of a forward range: you use iterators and `std::advance=
`. This is a good thing, because it allows different types to exhibit the b=
ehavior that works best for them.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>But in the current state of the lang=
uage, while designing a concept it is best to avoid relying on [] and (), i=
f you want your concepts to be as easy to model as possible: if operator() =
and operator[] were not defined by the creator of a type,</div></div></bloc=
kquote><div><br>Why did the creator of the type <i>not</i> implement `opera=
tor[]`? Was it because the access would not be O(1), and therefore the type=
<i>shouldn't</i> be used with algorithms that expect O(1) access? Why =
do you assume that the lack of `operator[]` was an accident or oversight, r=
ather than a deliberate piece of design to prevent people from thinking of =
the operation incorrectly?<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>modeling the concept implies to duplicate t=
he type (and its interface) and to add the operators. This is too much work=
compared to be able to define these operators as non-members.<br>So when d=
esigning concepts, an alternative is to use free functions (at() and call()=
for example), which is less natural, less concise and not compatible with =
builtin types.<br></div></div></blockquote><div><br>What concepts are you t=
alking about? Range TS, the largest body of concepts before the standard co=
mmittee, includes no such thing. The closest it gets is Invocable, which re=
lies on the definition of `std::invoke`. And the only reason Invocable it d=
oesn't use `()` specifically is because `()` doesn't work on member=
pointers (which is why `std::invoke` exists in the first place). An object=
with a `call()` function is not Invocable. And `std::invoke` is not meant =
to be a customization point.<br><br>Can you give an example of such a conce=
pt? One that fits into the standard C++ paradigm?<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The second example r=
elies on function composition. If you don't have function objects, your=
function composition tools are unusable... Having to duplicate types inste=
ad of slightly adapting them is too bad, especially when you can do so with=
other operators.<br></div></div></blockquote><div><br>If a type is not a f=
unctor, then how would you "adapt it" to an interface that accept=
s functors? If that type wasn't a functor, then it presumably has quite=
a few operations that you might want to call. How do you decide <i>which</=
i> operation you want to call in the `operator()` overload?<br><br>And how =
do you prevent conflicts? If generic system inserts its `operator()` overlo=
ad for one operation, what happens when another system inserts another `ope=
rator()` overload into the type which happens to match the call signature? =
Or are they expected to use tag types to differentiate their particular cal=
ls?<br><br>At which point, there is fundamentally <i>no difference</i> betw=
een overloading `operator()` and simply inserting arbitrary functions into =
a class's member function list.<br><br>Also, why is there a need to dup=
licate a type to do composition? Lambdas can handle that adequately enough.=
After all, you're picking a single function to call anyway, and that d=
etermination is made at the point where you need to use it. This works a lo=
t better as a lambda than by creating a type and forwarding functions. Afte=
r all, your functor doesn't need to expose everything the type does; on=
ly that one specific operation.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br></div><div>For operator->(), that one =
is fundamentally different. Either the class is designed to be a proxy poin=
ter/iterator... or not. What would it mean to add operator->() to some o=
ther class? Do you have an example for wanting to do this?=C2=A0</div></div=
></blockquote><div><br>Currently, it is possible to implement operator* as =
a non-member but not operator->, which seems strange.<br></div></div></b=
lockquote><div><br>Well yes; we ought to have forbidden that too. But the d=
eed is done; there's no reason to compound the mistake just for the sak=
e of consistency.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>You often have types with methods get(), load(), val=
ue(), etc. An interesting syntax unification is to provide operator* for th=
ese types, that just forward to get() / load() / value().</div></div></bloc=
kquote><div><br>Yes, that is very interesting. It's also a very bad ide=
a. Most types that implement operator* don't throw exceptions if the va=
lue isn't there. `optional::value` does. As such, it is <i>important</i=
> that readers of the code see `value`, since that represents a possible si=
te of an exception. By contrast, `optional::operator*` does not throw excep=
tions. So `::value` and `::operator*` are not the same thing at all.<br><br=
>And `std::future` is a great example of why. It does not have an `operator=
*`. Why? Because the act of calling `get` may throw an exception; the abili=
ty to pass exceptions through `promise`/`future`s is an important feature. =
And since `operator*` isn't supposed to throw exceptions, there is no s=
uch overload.<br><br>Now, users could write an `operator*` for `std::future=
`. How exactly would you implement this? Would you call `future::get` and l=
et its exception bubble up, in violation of the expectation of `operator*`?=
Would you call `future::get` and swallow any exceptions? If it's the l=
atter, how do you construct the return value if an exception manifests? And=
so forth.<br><br>The idea that you can force all of these things into the =
same `operator*` or `operator->` box is decidedly reductive.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Then, =
if you have operator* that returns an l-value, why not having operator->=
? It would allow to have the syntax (*my_object).method() equivalent to my=
_object->method(), as expected.<br><br><br>Here is another example of ad=
apting an existing type with non-member operators. This one is currently po=
ssible, since it uses arithmetical operators:<br><br>The creator of a type =
is responsible for the interface she provides.<br>But the user can decide t=
hat in her context some operators not provided by the creator of the type a=
re meaningful.<br>For example, std::array forms a mathematical vector space=
with most arithmetical types. Roughly speaking, this means that an std::ar=
ray can represent a mathematical vector and we just have to choose an appro=
priate scalar type.<br>std::array has already the right behavior (value sem=
antics, etc.), except for the absence of arithmetical operators (+, *, etc.=
).<br>The user can't modify std::array definition, but she can add thes=
e operators as non-members.<br>For example:<br>=C2=A0</div></div></blockquo=
te><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"><div><s=
nip><br>The user can also add @=3D versions (+=3D, *=3D, etc.) for effic=
iency reasons.<br><br>Now the user can use std::array as a vector space in =
her generic algorithms.<br>The amount of work is minimal because of the pos=
sibility to define<br>non-member operators.<br></div></div></blockquote><di=
v><br>Yes, and this is a <i>terrible idea</i>. Why? Because it creates a hu=
ge mess of the meaning of the type system.<br><br>An array is not conceptua=
lly an addable thing. Therefore, `std::array`, which models the concept of =
an array, is not a thing that should be addable. A mathematical vector is c=
onceptually an addable thing. Therefore, a type implementing that concept s=
hould be addable.<br><br>Now, that vector type may in fact be implemented i=
n terms of `array`; that's fine. But there's a difference between s=
aying that an array is an implementation detail of a vector and that all ar=
rays <i>are vectors</i>. Not every array is a vector, and therefore not eve=
ry array should be able to be treated as if it were a vector.<br><br>What y=
ou're doing is a violation of the <a href=3D"https://en.wikipedia.org/w=
iki/Interface_segregation_principle">Interface Segregation Principle</a>; i=
t's the generic programming equivalent of a fat interface base class. Y=
ou make every array conceptually a vector, even if the user doesn't wan=
t or need it to be a vector.<br><br>We should not promote coding styles tha=
t violate things like this. We allow the extension of binary math operators=
outside of a class, not because we want people to inject their interfaces =
into other people's classes, but to allow for two different types to be=
addable. To allow adding scalars and vectors, for example.<br><br>This is =
not a tool that should be used to make a class which is not conceptually ad=
dable into one that is.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7082d763-15f9-4bfa-b564-64b2442997aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7082d763-15f9-4bfa-b564-64b2442997aa=
%40isocpp.org</a>.<br />
------=_Part_1035_1183925390.1498326465346--
------=_Part_1034_11450154.1498326465346--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sat, 24 Jun 2017 16:18:17 -0700
Raw View
--001a113fe1540477490552bcf0f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 24 June 2017 at 09:47, <jmonnon@aldebaran.com> wrote:
>
> Le samedi 24 juin 2017 02:23:10 UTC+2, Richard Smith a =C3=A9crit :
>>
>> On 23 June 2017 at 10:03, <jmo...@aldebaran.com> wrote:
>>
>>> Hello,
>>>
>>> This is a proposal to allow operator(), operator[] and operator-> to be
>>> defined as non-member functions.
>>> I do not know if this has already been proposed and potential arguments
>>> against it, so please let me know.
>>>
>>> The main motivation for this proposal is consistency. It makes also
>>> easier to externally adapt existing types for use with generic algorith=
ms,
>>> as show examples.
>>>
>>
>> Overloading operator-> would mean that there can be a set of possible
>> operator-> functions for a single type, with different return types. Wha=
t
>> do you expect to happen there? Should the selected operator-> depend on
>> whether the type contains the named member? (You might like to look at t=
he
>> 'operator.' wording to get some idea of how complicated this can become.=
)
>>
>
> Currently, operator-> must be defined as a non-static member function
> taking no parameters (16.5.6) . The non-member form would take a single
> argument evaluating to a class object, so there would be only one version
> by type, if I understand correctly.
>
So in cases where multiple viable operator-> functions exist, the result
would be ambiguity, independent of the identifier after the -> ? That would
avoid this problem, but is notably a different choice than that made during
the design of 'operator.'. Your paper at least would need to describe and
explain this decision.
Overloading operator() sounds like it would potentially lead to a much more
>> expensive overload resolution process for potentially every function cal=
l
>> in the program, unless it's handled very carefully. For instance, someon=
e
>> is going to write something like this:
>>
>> template<typename R, typename ...T, typename ...U,
>> enable_if<each_U_is_either_T_or_optional_T<list<T...>,
>> list<U...>>::value, int> =3D 0>
>> optional<R> operator()(R(*f)(T...), U &&...u) {
>> /* if any u's are nullopt, return nullopt, otherwise return
>> f(unwrap(forward<U>(u))) */
>> }
>>
>> ... in order to allow:
>>
>> optional<int> a, b;
>> int f(int x, int y);
>> optional<int> c =3D f(a, b); // implicitly use ::operator() here, only
>> call 'f' if neither 'a' nor 'b' is nullopt
>>
>> ... and likewise for a bunch of other templates that are functors in the
>> category theory sense.
>>
>> And now we potentially have a large number of operator() overloads to
>> consider for every single function call, and considering each of them
>> requires some nontrivial template instantiation work.
>>
>> I'm not sure if this example work (f is not a member function for
> example).
>
I think I'm missing something -- why would it make a difference if 'f' is a
member function?
> Anyway, it would be the user responsibility to add or not such an
> overload. And it is already possible to seriously slow down compilation b=
y
> providing a bunch of template "enabled-if" operators (+, -, <<, and the
> others).
>
The large number of operator<< overloads are already a very significant
component of compile time for many programs. This has the potential to
apply the same problem to all function calls. I have not seen any evidence
that programmers take this into account when adding their neat new operator
overload. You're right that it's not the language's job to nanny the
programmer, but the principle that you don't pay for what you don't use
should apply to compilation performance as well as runtime.
I think there's also a question of whether you'd apply operator()
recursively: if we can rewrite f(a, b, c) as operator()(f, a, b, c), do we
then need to check whether we need to rewrite *that* as
operator()(operator(), f, a, b, c) and so on? Likewise, can a + b be
interpreted as operator()(operator+, a, b)?
> Overloading operator[] seems fine, though. It's just a normal binary
>> operator with slightly funny syntax, after all.
>>
>>
>>> Thank you in advance for your reviews and comments.
>>>
>>>
>>>
>>>
>>> *This email and any attachment thereto are confidential and intended
>>> solely for the use of the individual or entity to whom they are
>>> addressed.If you are not the intended recipient, please be advised that
>>> disclosing, copying, distributing or taking any action in reliance on t=
he
>>> contents of this email is strictly prohibited. In such case, please
>>> immediately advise the sender, and delete all copies and attachment fro=
m
>>> your system.This email shall not be construed and is not tantamount to =
an
>>> offer, an acceptance of offer, or an agreement by SoftBank Robotics Eur=
ope
>>> on any discussion or contractual document whatsoever. No employee or ag=
ent
>>> is authorized to represent or bind SoftBank Robotics Europe to third
>>> parties by email, or act on behalf of SoftBank Robotics Europe by email=
,
>>> without express written confirmation by SoftBank Robotics Europe=E2=80=
=99 duly
>>> authorized representatives.*
>>> ------------------------------
>>>
>>>
>>>
>>>
>>> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes s=
ont
>>> confidentiels, et exclusivement destin=C3=A9s =C3=A0 la personne ou l'e=
ntit=C3=A9 =C3=A0 qui
>>> ils sont adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=
=A9, vous =C3=AAtes pri=C3=A9
>>> de ne pas divulguer, copier, distribuer ou prendre toute d=C3=A9cision =
sur la
>>> foi de ce message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diateme=
nt
>>> l'exp=C3=A9diteur et de supprimer toutes les copies et =C3=A9ventuelles=
pi=C3=A8ces
>>> jointes de votre syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quiv=
aut pas =C3=A0 une
>>> offre, =C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de S=
oftBank Robotics
>>> Europe sur toute discussion ou document contractuel quel qu=E2=80=99il =
soit, et ne
>>> peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou ag=
ent de SoftBank Robotics
>>> Europe n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la=
soci=C3=A9t=C3=A9 par email, ou =C3=A0
>>> agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une
>>> confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=
=A9gal de SoftBank
>>> Robotics Europe ou par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=
=A9gation de
>>> pouvoir appropri=C3=A9e.*
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-
>>> 30d78aa4b35e%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-=
2b01-491b-8ee9-30d78aa4b35e%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>>
>
>
>
> *This email and any attachment thereto are confidential and intended
> solely for the use of the individual or entity to whom they are
> addressed.If you are not the intended recipient, please be advised that
> disclosing, copying, distributing or taking any action in reliance on the
> contents of this email is strictly prohibited. In such case, please
> immediately advise the sender, and delete all copies and attachment from
> your system.This email shall not be construed and is not tantamount to an
> offer, an acceptance of offer, or an agreement by SoftBank Robotics Europ=
e
> on any discussion or contractual document whatsoever. No employee or agen=
t
> is authorized to represent or bind SoftBank Robotics Europe to third
> parties by email, or act on behalf of SoftBank Robotics Europe by email,
> without express written confirmation by SoftBank Robotics Europe=E2=80=99=
duly
> authorized representatives.*
> ------------------------------
>
>
>
>
> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes son=
t confidentiels,
> et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0=
qui ils sont
> adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas
> divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi d=
e ce
> message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=
=A9diteur et de
> supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de vo=
tre
> syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une =
offre, =C3=A0 une
> acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Eur=
ope sur toute
> discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =
=C3=AAtre
> interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank R=
obotics Europe
> n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=
=A9t=C3=A9 par email, ou =C3=A0 agir
> au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation
> =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftB=
ank Robotics Europe ou
> par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir =
appropri=C3=A9e.*
>
> --
> 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/1ff81804-737c-4999-
> a27b-8e10608de2cb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1ff81804-73=
7c-4999-a27b-8e10608de2cb%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/CAOfiQq%3D%2BvWEyFO%3DU4fe9V_bcipwjNE%2Bfy%3DUhV=
y4f-OykVh4UPg%40mail.gmail.com.
--001a113fe1540477490552bcf0f5
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 2=
4 June 2017 at 09:47, <span dir=3D"ltr"><<a href=3D"mailto:jmonnon@alde=
baran.com" target=3D"_blank">jmonnon@aldebaran.com</a>></span> wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Le samedi 24 juin 2017 02:23:1=
0 UTC+2, Richard Smith a =C3=A9crit=C2=A0:<span class=3D""><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On=
23 June 2017 at 10:03, <span dir=3D"ltr"><<a rel=3D"nofollow">jmo...@a=
ldebaran.com</a>></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">Hello,<div><br></div><div>This is a proposal to allow operator()=
, operator[] and operator-> to be defined as non-member functions.</div>=
<div>I do not know if this has already been proposed and potential argument=
s against it, so please let me know.</div><div><br></div><div>The main moti=
vation for this proposal is consistency. It makes also easier to externally=
adapt existing types for use with generic algorithms, as show examples.</d=
iv></div></blockquote><div><br></div><div>Overloading operator-> would m=
ean that there can be a set of possible operator-> functions for a singl=
e type, with different return types. What do you expect to happen there? Sh=
ould the selected operator-> depend on whether the type contains the nam=
ed member? (You might like to look at the 'operator.' wording to ge=
t some idea of how complicated this can become.)</div></div></div></div></b=
lockquote></span><div><br>Currently, operator-> must be defined as a non=
-static member function taking no parameters (16.5.6) . The non-member form=
would take a single argument evaluating to a class object, so there would =
be only one version by type, if I understand correctly.</div></div></blockq=
uote><div><br></div><div>So in cases where multiple viable operator-> fu=
nctions exist, the result would be ambiguity, independent of the identifier=
after the -> ? That would avoid this problem, but is notably a differen=
t choice than that made during the design of 'operator.'. Your pape=
r at least would need to describe and explain this decision.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote"><div>Overloading operator() sounds like it would potentially lead=
to a much more expensive overload resolution process for potentially every=
function call in the program, unless it's handled very carefully. For =
instance, someone is going to write something like this:</div><div><br></di=
v><div>=C2=A0 template<typename R, typename ...T, typename ...U,</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable_if<each_U_is_either_T=
_<wbr>or_optional_T<list<T...>, list<U...>>::value, int&g=
t; =3D 0></div><div>=C2=A0 optional<R> operator()(R(*f)(T...), U &=
amp;&...u) {</div><div>=C2=A0 =C2=A0 /* if any u's are nullopt, ret=
urn nullopt, otherwise return f(unwrap(forward<U>(u))) */</div><div>=
=C2=A0 }</div><div><br></div><div>... in order to allow:</div><div><br></di=
v><div>=C2=A0 optional<int> a, b;</div><div>=C2=A0 int f(int x, int y=
);</div><div>=C2=A0 optional<int> c =3D f(a, b); // implicitly use ::=
operator() here, only call 'f' if neither 'a' nor 'b=
9; is nullopt</div><div><br></div><div>... and likewise for a bunch of othe=
r templates that are functors in the category theory sense.</div><div><br><=
/div><div>And now we potentially have a large number of operator() overload=
s to consider for every single function call, and considering each of them =
requires some nontrivial template instantiation work.</div><div><br></div><=
/div></div></div></blockquote></span><div>I'm not sure if this example =
work (f is not a member function for example).<br></div></div></blockquote>=
<div><br></div><div>I think I'm missing something -- why would it make =
a difference if 'f' is a member function?</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Anyway, it would be the u=
ser responsibility to add or not such an overload. And it is already possib=
le to seriously slow down compilation by providing a bunch of template &quo=
t;enabled-if" operators (+, -, <<, and the others).</div></div><=
/blockquote><div><br></div><div>The large number of operator<< overlo=
ads are already a very significant component of compile time for many progr=
ams. This has the potential to apply the same problem to all function calls=
.. I have not seen any evidence that programmers take this into account when=
adding their neat new operator overload. You're right that it's no=
t the language's job to nanny the programmer, but the principle that yo=
u don't pay for what you don't use should apply to compilation perf=
ormance as well as runtime.</div><div><br></div><div>I think there's al=
so a question of whether you'd apply operator() recursively: if we can =
rewrite f(a, b, c) as operator()(f, a, b, c), do we then need to check whet=
her we need to rewrite *that* as operator()(operator(), f, a, b, c) and so =
on? Likewise, can a + b be interpreted as operator()(operator+, a, b)?</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><span class=3D""><div></div><div>Overloading operator[] seems fine, th=
ough. It's just a normal binary operator with slightly funny syntax, af=
ter all.</div><div>=C2=A0</div></span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D""><div dir=3D"ltr"><div>Thank you in advance for your reviews and =
comments.</div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font size=3D"1" color=3D"#808080">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font size=3D"1" color=3D"#808080"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<span><font c=
olor=3D"#888888"><br></font></span></i></font></p><span><font color=3D"#888=
888"><p style=3D"margin:0px"><font size=3D"1" color=3D"#808080"><i></i></fo=
nt></p></font></span><p></p></span><span><font color=3D"#888888"><span clas=
s=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/8bd2a86c-2b01-491b-8ee9-<wbr>30d78aa4b35e%40isocpp.org</a>.<br=
>
</span></font></span></blockquote></div><br></div></div>
</blockquote></div><span class=3D"">
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></fon=
t></p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></f=
ont></p><p></p>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1ff81804-737c-4999-a27b-8e10608de2cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1ff8=
1804-737c-4999-<wbr>a27b-8e10608de2cb%40isocpp.org</a><wbr>.<br>
</blockquote></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" 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/CAOfiQq%3D%2BvWEyFO%3DU4fe9V_bcipwjNE=
%2Bfy%3DUhVy4f-OykVh4UPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq=
%3D%2BvWEyFO%3DU4fe9V_bcipwjNE%2Bfy%3DUhVy4f-OykVh4UPg%40mail.gmail.com</a>=
..<br />
--001a113fe1540477490552bcf0f5--
.
Author: jmonnon@aldebaran.com
Date: Sun, 25 Jun 2017 11:52:34 -0700 (PDT)
Raw View
------=_Part_1451_877114722.1498416754665
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le samedi 24 juin 2017 19:47:45 UTC+2, Nicol Bolas a =C3=A9crit :
>
> On Saturday, June 24, 2017 at 12:26:52 PM UTC-4, jmo...@aldebaran.com=20
> wrote:
>>
>> Le vendredi 23 juin 2017 21:59:24 UTC+2, Barry Revzin a =C3=A9crit :
>>>
>>>
>>> On Friday, June 23, 2017 at 12:03:38 PM UTC-5, jmo...@aldebaran.com=20
>>> wrote:
>>>>
>>>> The main motivation for this proposal is consistency. It makes also=20
>>>> easier to externally adapt existing types for use with generic algorit=
hms,=20
>>>> as show examples.
>>>>
>>>
>>> The examples for non-member operator[] and operator() seem pretty=20
>>> uncompelling. The first one seems like a bad algorithm (why not just pa=
ss=20
>>> in a predicate instead of enforcing indexing? It'd probably be less typ=
ing=20
>>> overall), the second one doesn't even directly use your operator() anyw=
here=20
>>> - it's buried... somewhere. I think these could use much stronger examp=
les=20
>>> of cases where the best solution would be to add the overload, but we=
=20
>>> can't, so we're left with some subpar solution. And provide before/afte=
r=20
>>> examples demonstrating the improvement. Otherwise, right now it's kind=
=20
>>> of... meh.=20
>>>
>>
>> About the first example, you could also use operator[] to modify / creat=
e=20
>> an element =C3=A0 la std::map. In this case, a predicate would not be en=
ough.=20
>> `[]` could be used as a "standard" way to access an element.
>>
>
> To access an element of what? You couldn't use it to access an element=20
> from `list`, or from any of the `set`s.
>
> The rules that STL devised for interfaces give `operator[]` a special=20
> meaning for sequence containers. It means that access to the element is=
=20
> (amortized) O(1). If a container cannot fulfill that promise, then it oug=
ht=20
> not provide `operator[]`.
>
> That operator is not meant to be a catch-all means of "accessing an=20
> element". Trying to use it that way is a *bad thing*.
>
> We already have ways of accessing the i-th element of a forward range: yo=
u=20
> use iterators and `std::advance`. This is a good thing, because it allows=
=20
> different types to exhibit the behavior that works best for them.
>
> But in the current state of the language, while designing a concept it is=
=20
>> best to avoid relying on [] and (), if you want your concepts to be as e=
asy=20
>> to model as possible: if operator() and operator[] were not defined by t=
he=20
>> creator of a type,
>>
>
> Why did the creator of the type *not* implement `operator[]`? Was it=20
> because the access would not be O(1), and therefore the type *shouldn't*=
=20
> be used with algorithms that expect O(1) access? Why do you assume that t=
he=20
> lack of `operator[]` was an accident or oversight, rather than a delibera=
te=20
> piece of design to prevent people from thinking of the operation=20
> incorrectly?
>
> modeling the concept implies to duplicate the type (and its interface) an=
d=20
>> to add the operators. This is too much work compared to be able to defin=
e=20
>> these operators as non-members.
>> So when designing concepts, an alternative is to use free functions (at(=
)=20
>> and call() for example), which is less natural, less concise and not=20
>> compatible with builtin types.
>>
>
> What concepts are you talking about? Range TS, the largest body of=20
> concepts before the standard committee, includes no such thing. The close=
st=20
> it gets is Invocable, which relies on the definition of `std::invoke`. An=
d=20
> the only reason Invocable it doesn't use `()` specifically is because `()=
`=20
> doesn't work on member pointers (which is why `std::invoke` exists in the=
=20
> first place). An object with a `call()` function is not Invocable. And=20
> `std::invoke` is not meant to be a customization point.
>
> Can you give an example of such a concept? One that fits into the standar=
d=20
> C++ paradigm?
>
> The second example relies on function composition. If you don't have=20
>> function objects, your function composition tools are unusable... Having=
to=20
>> duplicate types instead of slightly adapting them is too bad, especially=
=20
>> when you can do so with other operators.
>>
>
> If a type is not a functor, then how would you "adapt it" to an interface=
=20
> that accepts functors? If that type wasn't a functor, then it presumably=
=20
> has quite a few operations that you might want to call. How do you decide=
=20
> *which* operation you want to call in the `operator()` overload?
>
> And how do you prevent conflicts? If generic system inserts its=20
> `operator()` overload for one operation, what happens when another system=
=20
> inserts another `operator()` overload into the type which happens to matc=
h=20
> the call signature? Or are they expected to use tag types to differentiat=
e=20
> their particular calls?
>
> At which point, there is fundamentally *no difference* between=20
> overloading `operator()` and simply inserting arbitrary functions into a=
=20
> class's member function list.
>
> Also, why is there a need to duplicate a type to do composition? Lambdas=
=20
> can handle that adequately enough. After all, you're picking a single=20
> function to call anyway, and that determination is made at the point wher=
e=20
> you need to use it. This works a lot better as a lambda than by creating =
a=20
> type and forwarding functions. After all, your functor doesn't need to=20
> expose everything the type does; only that one specific operation.
>
>
>>> For operator->(), that one is fundamentally different. Either the class=
=20
>>> is designed to be a proxy pointer/iterator... or not. What would it mea=
n to=20
>>> add operator->() to some other class? Do you have an example for wantin=
g to=20
>>> do this?=20
>>>
>>
>> Currently, it is possible to implement operator* as a non-member but not=
=20
>> operator->, which seems strange.
>>
>
> Well yes; we ought to have forbidden that too. But the deed is done;=20
> there's no reason to compound the mistake just for the sake of consistenc=
y.
>
> You often have types with methods get(), load(), value(), etc. An=20
>> interesting syntax unification is to provide operator* for these types,=
=20
>> that just forward to get() / load() / value().
>>
>
> Yes, that is very interesting. It's also a very bad idea. Most types that=
=20
> implement operator* don't throw exceptions if the value isn't there.=20
> `optional::value` does. As such, it is *important* that readers of the=20
> code see `value`, since that represents a possible site of an exception. =
By=20
> contrast, `optional::operator*` does not throw exceptions. So `::value` a=
nd=20
> `::operator*` are not the same thing at all.
>
> And `std::future` is a great example of why. It does not have an=20
> `operator*`. Why? Because the act of calling `get` may throw an exception=
;=20
> the ability to pass exceptions through `promise`/`future`s is an importan=
t=20
> feature. And since `operator*` isn't supposed to throw exceptions, there =
is=20
> no such overload.
>
> Now, users could write an `operator*` for `std::future`. How exactly woul=
d=20
> you implement this? Would you call `future::get` and let its exception=20
> bubble up, in violation of the expectation of `operator*`? Would you call=
=20
> `future::get` and swallow any exceptions? If it's the latter, how do you=
=20
> construct the return value if an exception manifests? And so forth.
>
> The idea that you can force all of these things into the same `operator*`=
=20
> or `operator->` box is decidedly reductive.
>
> Then, if you have operator* that returns an l-value, why not having=20
>> operator-> ? It would allow to have the syntax (*my_object).method()=20
>> equivalent to my_object->method(), as expected.
>>
>>
>> Here is another example of adapting an existing type with non-member=20
>> operators. This one is currently possible, since it uses arithmetical=20
>> operators:
>>
>> The creator of a type is responsible for the interface she provides.
>> But the user can decide that in her context some operators not provided=
=20
>> by the creator of the type are meaningful.
>> For example, std::array forms a mathematical vector space with most=20
>> arithmetical types. Roughly speaking, this means that an std::array can=
=20
>> represent a mathematical vector and we just have to choose an appropriat=
e=20
>> scalar type.
>> std::array has already the right behavior (value semantics, etc.), excep=
t=20
>> for the absence of arithmetical operators (+, *, etc.).
>> The user can't modify std::array definition, but she can add these=20
>> operators as non-members.
>> For example:
>> =20
>>
> <snip>
>> The user can also add @=3D versions (+=3D, *=3D, etc.) for efficiency re=
asons.
>>
>> Now the user can use std::array as a vector space in her generic=20
>> algorithms.
>> The amount of work is minimal because of the possibility to define
>> non-member operators.
>>
>
> Yes, and this is a *terrible idea*. Why? Because it creates a huge mess=
=20
> of the meaning of the type system.
>
> An array is not conceptually an addable thing. Therefore, `std::array`,=
=20
> which models the concept of an array, is not a thing that should be=20
> addable. A mathematical vector is conceptually an addable thing. Therefor=
e,=20
> a type implementing that concept should be addable.
>
> Now, that vector type may in fact be implemented in terms of `array`;=20
> that's fine. But there's a difference between saying that an array is an=
=20
> implementation detail of a vector and that all arrays *are vectors*. Not=
=20
> every array is a vector, and therefore not every array should be able to =
be=20
> treated as if it were a vector.
>
> What you're doing is a violation of the Interface Segregation Principle=
=20
> <https://en.wikipedia.org/wiki/Interface_segregation_principle>; it's the=
=20
> generic programming equivalent of a fat interface base class. You make=20
> every array conceptually a vector, even if the user doesn't want or need =
it=20
> to be a vector.
>
> We should not promote coding styles that violate things like this. We=20
> allow the extension of binary math operators outside of a class, not=20
> because we want people to inject their interfaces into other people's=20
> classes, but to allow for two different types to be addable. To allow=20
> adding scalars and vectors, for example.
>
> This is not a tool that should be used to make a class which is not=20
> conceptually addable into one that is.
>
Please read the proposal for some answers to your questions.
The behavior of operator[] you mention is the one of the STL. But not all=
=20
code in the world must follow STL design decisions.
For example in Element of Programming section 12.1, Stepanov describes a=20
Linearizable concept in which `[]`'s complexity is not always O(1) but can=
=20
be O(n) depending on the underlying iterator. It is his design decision to=
=20
do so.
Frameworks and libraries in a given domain are not forced to follow STL,=20
and can assign whatever semantics and algorithmic complexity to operators=
=20
that makes sense in this domain.
One strength of C++ is that it doesn't impose a particular paradigm on the=
=20
user. Instead of artificially forbidding things on user, the
language should make as easy as possible the adaptation and composition of=
=20
components (types, functions, concepts, etc.).
If in my context I want to use (std::array<float>, int) as a vector space=
=20
(because it is mathematically well-defined and minimize my work), it is my=
=20
responsibility to do so. If it makes sense in my context to adapt a type as=
=20
a function object (because it enables monadic composition for example and=
=20
minimize my work), it is my decision to do so and I shouldn't have to fight=
=20
artificial limitations of the language.
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
--=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/0a173e48-6017-4d29-a633-3d5cabf70b35%40isocpp.or=
g.
------=_Part_1451_877114722.1498416754665
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le samedi 24 juin 2017 19:47:45 UTC+2, Nicol Bolas=
a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Saturday, June 24, 2017 at 12:26:52 PM UTC-4, <a>jmo...@aldebar=
an.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">L=
e vendredi 23 juin 2017 21:59:24 UTC+2, Barry Revzin a =C3=A9crit=C2=A0:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Friday, June 2=
3, 2017 at 12:03:38 PM UTC-5, <a>jmo...@aldebaran.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"><div>The main motivation for =
this proposal is consistency. It makes also easier to externally adapt exis=
ting types for use with generic algorithms, as show examples.<br></div></di=
v></blockquote><div><br></div><div>The examples for non-member operator[] a=
nd operator() seem pretty uncompelling. The first one seems like a bad algo=
rithm (why not just pass in a predicate instead of enforcing indexing? It&#=
39;d probably be less typing overall), the second one doesn't even dire=
ctly use your operator() anywhere - it's buried... somewhere. I think t=
hese could use much stronger examples of cases where the best solution woul=
d be to add the overload, but we can't, so we're left with some sub=
par solution. And provide before/after examples demonstrating the improveme=
nt. Otherwise, right now it's kind of... meh.=C2=A0</div></div></blockq=
uote><div><br>About the first example, you could also use operator[] to mod=
ify / create an element =C3=A0 la std::map. In this case, a predicate would=
not be enough. `[]` could be used as a "standard" way to access =
an element.</div></div></blockquote><div><br>To access an element of what? =
You couldn't use it to access an element from `list`, or from any of th=
e `set`s.<br><br>The rules that STL devised for interfaces give `operator[]=
` a special meaning for sequence containers. It means that access to the el=
ement is (amortized) O(1). If a container cannot fulfill that promise, then=
it ought not provide `operator[]`.<br><br>That operator is not meant to be=
a catch-all means of "accessing an element". Trying to use it th=
at way is a <i>bad thing</i>.<br><br>We already have ways of accessing the =
i-th element of a forward range: you use iterators and `std::advance`. This=
is a good thing, because it allows different types to exhibit the behavior=
that works best for them.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>But in the current state of the language, while =
designing a concept it is best to avoid relying on [] and (), if you want y=
our concepts to be as easy to model as possible: if operator() and operator=
[] were not defined by the creator of a type,</div></div></blockquote><div>=
<br>Why did the creator of the type <i>not</i> implement `operator[]`? Was =
it because the access would not be O(1), and therefore the type <i>shouldn&=
#39;t</i> be used with algorithms that expect O(1) access? Why do you assum=
e that the lack of `operator[]` was an accident or oversight, rather than a=
deliberate piece of design to prevent people from thinking of the operatio=
n incorrectly?<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>modeling the concept implies to duplicate the type (and its =
interface) and to add the operators. This is too much work compared to be a=
ble to define these operators as non-members.<br>So when designing concepts=
, an alternative is to use free functions (at() and call() for example), wh=
ich is less natural, less concise and not compatible with builtin types.<br=
></div></div></blockquote><div><br>What concepts are you talking about? Ran=
ge TS, the largest body of concepts before the standard committee, includes=
no such thing. The closest it gets is Invocable, which relies on the defin=
ition of `std::invoke`. And the only reason Invocable it doesn't use `(=
)` specifically is because `()` doesn't work on member pointers (which =
is why `std::invoke` exists in the first place). An object with a `call()` =
function is not Invocable. And `std::invoke` is not meant to be a customiza=
tion point.<br><br>Can you give an example of such a concept? One that fits=
into the standard C++ paradigm?<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>The second example relies on function comp=
osition. If you don't have function objects, your function composition =
tools are unusable... Having to duplicate types instead of slightly adaptin=
g them is too bad, especially when you can do so with other operators.<br><=
/div></div></blockquote><div><br>If a type is not a functor, then how would=
you "adapt it" to an interface that accepts functors? If that ty=
pe wasn't a functor, then it presumably has quite a few operations that=
you might want to call. How do you decide <i>which</i> operation you want =
to call in the `operator()` overload?<br><br>And how do you prevent conflic=
ts? If generic system inserts its `operator()` overload for one operation, =
what happens when another system inserts another `operator()` overload into=
the type which happens to match the call signature? Or are they expected t=
o use tag types to differentiate their particular calls?<br><br>At which po=
int, there is fundamentally <i>no difference</i> between overloading `opera=
tor()` and simply inserting arbitrary functions into a class's member f=
unction list.<br><br>Also, why is there a need to duplicate a type to do co=
mposition? Lambdas can handle that adequately enough. After all, you're=
picking a single function to call anyway, and that determination is made a=
t the point where you need to use it. This works a lot better as a lambda t=
han by creating a type and forwarding functions. After all, your functor do=
esn't need to expose everything the type does; only that one specific o=
peration.<br><br></div><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"><div></div><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"><d=
iv><br></div><div>For operator->(), that one is fundamentally different.=
Either the class is designed to be a proxy pointer/iterator... or not. Wha=
t would it mean to add operator->() to some other class? Do you have an =
example for wanting to do this?=C2=A0</div></div></blockquote><div><br>Curr=
ently, it is possible to implement operator* as a non-member but not operat=
or->, which seems strange.<br></div></div></blockquote><div><br>Well yes=
; we ought to have forbidden that too. But the deed is done; there's no=
reason to compound the mistake just for the sake of consistency.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>You often=
have types with methods get(), load(), value(), etc. An interesting syntax=
unification is to provide operator* for these types, that just forward to =
get() / load() / value().</div></div></blockquote><div><br>Yes, that is ver=
y interesting. It's also a very bad idea. Most types that implement ope=
rator* don't throw exceptions if the value isn't there. `optional::=
value` does. As such, it is <i>important</i> that readers of the code see `=
value`, since that represents a possible site of an exception. By contrast,=
`optional::operator*` does not throw exceptions. So `::value` and `::opera=
tor*` are not the same thing at all.<br><br>And `std::future` is a great ex=
ample of why. It does not have an `operator*`. Why? Because the act of call=
ing `get` may throw an exception; the ability to pass exceptions through `p=
romise`/`future`s is an important feature. And since `operator*` isn't =
supposed to throw exceptions, there is no such overload.<br><br>Now, users =
could write an `operator*` for `std::future`. How exactly would you impleme=
nt this? Would you call `future::get` and let its exception bubble up, in v=
iolation of the expectation of `operator*`? Would you call `future::get` an=
d swallow any exceptions? If it's the latter, how do you construct the =
return value if an exception manifests? And so forth.<br><br>The idea that =
you can force all of these things into the same `operator*` or `operator-&g=
t;` box is decidedly reductive.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Then, if you have operator* that returns an=
l-value, why not having operator-> ? It would allow to have the syntax =
(*my_object).method() equivalent to my_object->method(), as expected.<br=
><br><br>Here is another example of adapting an existing type with non-memb=
er operators. This one is currently possible, since it uses arithmetical op=
erators:<br><br>The creator of a type is responsible for the interface she =
provides.<br>But the user can decide that in her context some operators not=
provided by the creator of the type are meaningful.<br>For example, std::a=
rray forms a mathematical vector space with most arithmetical types. Roughl=
y speaking, this means that an std::array can represent a mathematical vect=
or and we just have to choose an appropriate scalar type.<br>std::array has=
already the right behavior (value semantics, etc.), except for the absence=
of arithmetical operators (+, *, etc.).<br>The user can't modify std::=
array definition, but she can add these operators as non-members.<br>For ex=
ample:<br>=C2=A0</div></div></blockquote><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"><div><snip><br>The user can also add @=3D vers=
ions (+=3D, *=3D, etc.) for efficiency reasons.<br><br>Now the user can use=
std::array as a vector space in her generic algorithms.<br>The amount of w=
ork is minimal because of the possibility to define<br>non-member operators=
..<br></div></div></blockquote><div><br>Yes, and this is a <i>terrible idea<=
/i>. Why? Because it creates a huge mess of the meaning of the type system.=
<br><br>An array is not conceptually an addable thing. Therefore, `std::arr=
ay`, which models the concept of an array, is not a thing that should be ad=
dable. A mathematical vector is conceptually an addable thing. Therefore, a=
type implementing that concept should be addable.<br><br>Now, that vector =
type may in fact be implemented in terms of `array`; that's fine. But t=
here's a difference between saying that an array is an implementation d=
etail of a vector and that all arrays <i>are vectors</i>. Not every array i=
s a vector, and therefore not every array should be able to be treated as i=
f it were a vector.<br><br>What you're doing is a violation of the <a h=
ref=3D"https://en.wikipedia.org/wiki/Interface_segregation_principle" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.g=
oogle.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInterface_segreg=
ation_principle\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBR2rEEc12PCzYy3-8C=
7Ye4xUWmw';return true;" onclick=3D"this.href=3D'https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInterface_segregation=
_principle\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBR2rEEc12PCzYy3-8C7Ye4x=
UWmw';return true;">Interface Segregation Principle</a>; it's the g=
eneric programming equivalent of a fat interface base class. You make every=
array conceptually a vector, even if the user doesn't want or need it =
to be a vector.<br><br>We should not promote coding styles that violate thi=
ngs like this. We allow the extension of binary math operators outside of a=
class, not because we want people to inject their interfaces into other pe=
ople's classes, but to allow for two different types to be addable. To =
allow adding scalars and vectors, for example.<br><br>This is not a tool th=
at should be used to make a class which is not conceptually addable into on=
e that is.<br></div></div></blockquote><div><br>Please read the proposal fo=
r some answers to your questions.<br><br>The behavior of operator[] you men=
tion is the one of the STL. But not all code in the world must follow STL d=
esign decisions.<br>For example in Element of Programming section 12.1, Ste=
panov describes a Linearizable concept in which `[]`'s complexity is no=
t always O(1) but can be O(n) depending on the underlying iterator. It is h=
is design decision to do so.<br><br>Frameworks and libraries in a given dom=
ain are not forced to follow STL, and can assign whatever semantics and alg=
orithmic complexity to operators that makes sense in this domain.<br>One st=
rength of C++ is that it doesn't impose a particular paradigm on the us=
er. Instead of artificially forbidding things on user, the<br>=C2=A0languag=
e should make as easy as possible the adaptation and composition of compone=
nts (types, functions, concepts, etc.).<br><br>If in my context I want to u=
se (std::array<float>, int) as a vector space (because it is mathemat=
ically well-defined and minimize my work), it is my responsibility to do so=
.. If it makes sense in my context to adapt a type as a function object (bec=
ause it enables monadic composition for example and minimize my work), it i=
s my decision to do so and I shouldn't have to fight artificial limitat=
ions of the language.<br></div></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous=
=C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d'en=
aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes les=
copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/0a173e48-6017-4d29-a633-3d5cabf70b35%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a173e48-6017-4d29-a633-3d5cabf70b35=
%40isocpp.org</a>.<br />
------=_Part_1451_877114722.1498416754665--
.
Author: jmonnon@aldebaran.com
Date: Sun, 25 Jun 2017 11:56:39 -0700 (PDT)
Raw View
------=_Part_1528_1786924401.1498416999432
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le dimanche 25 juin 2017 01:18:39 UTC+2, Richard Smith a =C3=A9crit :
>
> On 24 June 2017 at 09:47, <jmo...@aldebaran.com <javascript:>> wrote:
>>
>> Le samedi 24 juin 2017 02:23:10 UTC+2, Richard Smith a =C3=A9crit :
>>>
>>> On 23 June 2017 at 10:03, <jmo...@aldebaran.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> This is a proposal to allow operator(), operator[] and operator-> to b=
e=20
>>>> defined as non-member functions.
>>>> I do not know if this has already been proposed and potential argument=
s=20
>>>> against it, so please let me know.
>>>>
>>>> The main motivation for this proposal is consistency. It makes also=20
>>>> easier to externally adapt existing types for use with generic algorit=
hms,=20
>>>> as show examples.
>>>>
>>>
>>> Overloading operator-> would mean that there can be a set of possible=
=20
>>> operator-> functions for a single type, with different return types. Wh=
at=20
>>> do you expect to happen there? Should the selected operator-> depend on=
=20
>>> whether the type contains the named member? (You might like to look at =
the=20
>>> 'operator.' wording to get some idea of how complicated this can become=
..)
>>>
>>
>> Currently, operator-> must be defined as a non-static member function=20
>> taking no parameters (16.5.6) . The non-member form would take a single=
=20
>> argument evaluating to a class object, so there would be only one versio=
n=20
>> by type, if I understand correctly.
>>
>
> So in cases where multiple viable operator-> functions exist, the result=
=20
> would be ambiguity, independent of the identifier after the -> ? That wou=
ld=20
> avoid this problem, but is notably a different choice than that made duri=
ng=20
> the design of 'operator.'. Your paper at least would need to describe and=
=20
> explain this decision.
>
Yes there could be ambiguity, as with other operators.
The goal of the proposal is not to change the behavior of the operators=20
themselves, it is only to relax the "non-static member" constraints=20
(including on operator->).=20
>
> Overloading operator() sounds like it would potentially lead to a much=20
>>> more expensive overload resolution process for potentially every functi=
on=20
>>> call in the program, unless it's handled very carefully. For instance,=
=20
>>> someone is going to write something like this:
>>>
>>> template<typename R, typename ...T, typename ...U,
>>> enable_if<each_U_is_either_T_or_optional_T<list<T...>,=20
>>> list<U...>>::value, int> =3D 0>
>>> optional<R> operator()(R(*f)(T...), U &&...u) {
>>> /* if any u's are nullopt, return nullopt, otherwise return=20
>>> f(unwrap(forward<U>(u))) */
>>> }
>>>
>>> ... in order to allow:
>>>
>>> optional<int> a, b;
>>> int f(int x, int y);
>>> optional<int> c =3D f(a, b); // implicitly use ::operator() here, onl=
y=20
>>> call 'f' if neither 'a' nor 'b' is nullopt
>>>
>>> ... and likewise for a bunch of other templates that are functors in th=
e=20
>>> category theory sense.
>>>
>>> And now we potentially have a large number of operator() overloads to=
=20
>>> consider for every single function call, and considering each of them=
=20
>>> requires some nontrivial template instantiation work.
>>>
>>> I'm not sure if this example work (f is not a member function for=20
>> example).
>>
>
> I think I'm missing something -- why would it make a difference if 'f' is=
=20
> a member function?
>
You're right, I misread.
=20
> =20
>
>> Anyway, it would be the user responsibility to add or not such an=20
>> overload. And it is already possible to seriously slow down compilation =
by=20
>> providing a bunch of template "enabled-if" operators (+, -, <<, and the=
=20
>> others).
>>
>
> The large number of operator<< overloads are already a very significant=
=20
> component of compile time for many programs. This has the potential to=20
> apply the same problem to all function calls. I have not seen any evidenc=
e=20
> that programmers take this into account when adding their neat new operat=
or=20
> overload. You're right that it's not the language's job to nanny the=20
> programmer, but the principle that you don't pay for what you don't use=
=20
> should apply to compilation performance as well as runtime.
>
You pay only if you add such template operators. The situation is currently=
=20
the same with a lot of operators (+, <<, etc.), so I don't see a particular=
=20
problem here. Also most of the time, only a non-template version is needed=
=20
(see examples of the proposal).=20
>
> I think there's also a question of whether you'd apply operator()=20
> recursively: if we can rewrite f(a, b, c) as operator()(f, a, b, c), do w=
e=20
> then need to check whether we need to rewrite *that* as=20
> operator()(operator(), f, a, b, c) and so on? Likewise, can a + b be=20
> interpreted as operator()(operator+, a, b)?
>
I'm not sure to understand: to me we are in the usual overload resolution=
=20
mechanism (16.3.3).
Regards.
=20
>
>> Overloading operator[] seems fine, though. It's just a normal binary=20
>>> operator with slightly funny syntax, after all.
>>> =20
>>>
>>>> Thank you in advance for your reviews and comments.
>>>>
>>>>
>>>>
>>>>
>>>> *This email and any attachment thereto are confidential and intended=
=20
>>>> solely for the use of the individual or entity to whom they are=20
>>>> addressed.If you are not the intended recipient, please be advised tha=
t=20
>>>> disclosing, copying, distributing or taking any action in reliance on =
the=20
>>>> contents of this email is strictly prohibited. In such case, please=20
>>>> immediately advise the sender, and delete all copies and attachment fr=
om=20
>>>> your system.This email shall not be construed and is not tantamount to=
an=20
>>>> offer, an acceptance of offer, or an agreement by SoftBank Robotics Eu=
rope=20
>>>> on any discussion or contractual document whatsoever. No employee or a=
gent=20
>>>> is authorized to represent or bind SoftBank Robotics Europe to third=
=20
>>>> parties by email, or act on behalf of SoftBank Robotics Europe by emai=
l,=20
>>>> without express written confirmation by SoftBank Robotics Europe=E2=80=
=99 duly=20
>>>> authorized representatives.*
>>>> ------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes =
sont=20
>>>> confidentiels, et exclusivement destin=C3=A9s =C3=A0 la personne ou l'=
entit=C3=A9 =C3=A0 qui=20
>>>> ils sont adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=
=A9, vous =C3=AAtes pri=C3=A9=20
>>>> de ne pas divulguer, copier, distribuer ou prendre toute d=C3=A9cision=
sur la=20
>>>> foi de ce message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatem=
ent=20
>>>> l'exp=C3=A9diteur et de supprimer toutes les copies et =C3=A9ventuelle=
s pi=C3=A8ces=20
>>>> jointes de votre syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9qui=
vaut pas =C3=A0 une=20
>>>> offre, =C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de =
SoftBank Robotics=20
>>>> Europe sur toute discussion ou document contractuel quel qu=E2=80=99il=
soit, et ne=20
>>>> peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou a=
gent de SoftBank Robotics=20
>>>> Europe n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager l=
a soci=C3=A9t=C3=A9 par email, ou =C3=A0=20
>>>> agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans =
qu=E2=80=99une=20
>>>> confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=
=C3=A9gal de SoftBank=20
>>>> Robotics Europe ou par toute autre personne ayant re=C3=A7u d=C3=A9l=
=C3=A9gation de=20
>>>> pouvoir appropri=C3=A9e.*
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-=
2b01-491b-8ee9-30d78aa4b35e%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8bd2a86c=
-2b01-491b-8ee9-30d78aa4b35e%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>>
>>
>>
>>
>> *This email and any attachment thereto are confidential and intended=20
>> solely for the use of the individual or entity to whom they are=20
>> addressed.If you are not the intended recipient, please be advised that=
=20
>> disclosing, copying, distributing or taking any action in reliance on th=
e=20
>> contents of this email is strictly prohibited. In such case, please=20
>> immediately advise the sender, and delete all copies and attachment from=
=20
>> your system.This email shall not be construed and is not tantamount to a=
n=20
>> offer, an acceptance of offer, or an agreement by SoftBank Robotics Euro=
pe=20
>> on any discussion or contractual document whatsoever. No employee or age=
nt=20
>> is authorized to represent or bind SoftBank Robotics Europe to third=20
>> parties by email, or act on behalf of SoftBank Robotics Europe by email,=
=20
>> without express written confirmation by SoftBank Robotics Europe=E2=80=
=99 duly=20
>> authorized representatives.*
>> ------------------------------
>>
>>
>>
>>
>> *Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes so=
nt=20
>> confidentiels, et exclusivement destin=C3=A9s =C3=A0 la personne ou l'en=
tit=C3=A9 =C3=A0 qui=20
>> ils sont adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9=
, vous =C3=AAtes pri=C3=A9=20
>> de ne pas divulguer, copier, distribuer ou prendre toute d=C3=A9cision s=
ur la=20
>> foi de ce message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatemen=
t=20
>> l'exp=C3=A9diteur et de supprimer toutes les copies et =C3=A9ventuelles =
pi=C3=A8ces=20
>> jointes de votre syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quiva=
ut pas =C3=A0 une=20
>> offre, =C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de So=
ftBank Robotics=20
>> Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne=20
>> peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou age=
nt de SoftBank Robotics=20
>> Europe n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la =
soci=C3=A9t=C3=A9 par email, ou =C3=A0=20
>> agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=
=E2=80=99une=20
>> confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=
=A9gal de SoftBank=20
>> Robotics Europe ou par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=
=A9gation de=20
>> pouvoir appropri=C3=A9e.*
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1ff81804-73=
7c-4999-a27b-8e10608de2cb%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1ff81804-7=
37c-4999-a27b-8e10608de2cb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
--=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/15a96a9d-e2b8-4d2d-92c4-2751b5e5b41f%40isocpp.or=
g.
------=_Part_1528_1786924401.1498416999432
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le dimanche 25 juin 2017 01:18:39 UTC+2, Richard S=
mith a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote">On 24 June 2017 at 09:47, <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"b6nU-SlkAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmo...@aldebaran.com</a>></span> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">Le samedi 24 juin 2017 02:23:10 UTC+2, Richard S=
mith a =C3=A9crit=C2=A0:<span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote">On 23 June 2017 at 10:03, <spa=
n dir=3D"ltr"><<a rel=3D"nofollow">jmo...@aldebaran.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></d=
iv><div>This is a proposal to allow operator(), operator[] and operator->=
; to be defined as non-member functions.</div><div>I do not know if this ha=
s already been proposed and potential arguments against it, so please let m=
e know.</div><div><br></div><div>The main motivation for this proposal is c=
onsistency. It makes also easier to externally adapt existing types for use=
with generic algorithms, as show examples.</div></div></blockquote><div><b=
r></div><div>Overloading operator-> would mean that there can be a set o=
f possible operator-> functions for a single type, with different return=
types. What do you expect to happen there? Should the selected operator-&g=
t; depend on whether the type contains the named member? (You might like to=
look at the 'operator.' wording to get some idea of how complicate=
d this can become.)</div></div></div></div></blockquote></span><div><br>Cur=
rently, operator-> must be defined as a non-static member function takin=
g no parameters (16.5.6) . The non-member form would take a single argument=
evaluating to a class object, so there would be only one version by type, =
if I understand correctly.</div></div></blockquote><div><br></div><div>So i=
n cases where multiple viable operator-> functions exist, the result wou=
ld be ambiguity, independent of the identifier after the -> ? That would=
avoid this problem, but is notably a different choice than that made durin=
g the design of 'operator.'. Your paper at least would need to desc=
ribe and explain this decision.</div></div></div></div></blockquote><div><b=
r>Yes there could be ambiguity, as with other operators.<br>The goal of the=
proposal is not to change the behavior of the operators themselves, it is =
only to relax the "non-static member" constraints (including on o=
perator->). <br></div><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"><div><div class=3D"gmail_quote"><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Overloading operat=
or() sounds like it would potentially lead to a much more expensive overloa=
d resolution process for potentially every function call in the program, un=
less it's handled very carefully. For instance, someone is going to wri=
te something like this:</div><div><br></div><div>=C2=A0 template<typenam=
e R, typename ...T, typename ...U,</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0enable_if<each_U_is_either_T_<wbr>or_optional_T<list<=
T...>, list<U...>>::value, int> =3D 0></div><div>=C2=A0 o=
ptional<R> operator()(R(*f)(T...), U &&...u) {</div><div>=C2=
=A0 =C2=A0 /* if any u's are nullopt, return nullopt, otherwise return =
f(unwrap(forward<U>(u))) */</div><div>=C2=A0 }</div><div><br></div><d=
iv>... in order to allow:</div><div><br></div><div>=C2=A0 optional<int&g=
t; a, b;</div><div>=C2=A0 int f(int x, int y);</div><div>=C2=A0 optional<=
;int> c =3D f(a, b); // implicitly use ::operator() here, only call '=
;f' if neither 'a' nor 'b' is nullopt</div><div><br></d=
iv><div>... and likewise for a bunch of other templates that are functors i=
n the category theory sense.</div><div><br></div><div>And now we potentiall=
y have a large number of operator() overloads to consider for every single =
function call, and considering each of them requires some nontrivial templa=
te instantiation work.</div><div><br></div></div></div></div></blockquote><=
/span><div>I'm not sure if this example work (f is not a member functio=
n for example).<br></div></div></blockquote><div><br></div><div>I think I&#=
39;m missing something -- why would it make a difference if 'f' is =
a member function?</div></div></div></div></blockquote><div><br>You're =
right, I misread.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Anyway, it would be the =
user responsibility to add or not such an overload. And it is already possi=
ble to seriously slow down compilation by providing a bunch of template &qu=
ot;enabled-if" operators (+, -, <<, and the others).</div></div>=
</blockquote><div><br></div><div>The large number of operator<< overl=
oads are already a very significant component of compile time for many prog=
rams. This has the potential to apply the same problem to all function call=
s. I have not seen any evidence that programmers take this into account whe=
n adding their neat new operator overload. You're right that it's n=
ot the language's job to nanny the programmer, but the principle that y=
ou don't pay for what you don't use should apply to compilation per=
formance as well as runtime.</div></div></div></div></blockquote><div><br>Y=
ou pay only if you add such template operators. The situation is currently =
the same with a lot of operators (+, <<, etc.), so I don't see a =
particular problem here. Also most of the time, only a non-template version=
is needed (see examples of the proposal). <br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v><br></div><div>I think there's also a question of whether you'd a=
pply operator() recursively: if we can rewrite f(a, b, c) as operator()(f, =
a, b, c), do we then need to check whether we need to rewrite *that* as ope=
rator()(operator(), f, a, b, c) and so on? Likewise, can a + b be interpret=
ed as operator()(operator+, a, b)?</div></div></div></div></blockquote><div=
><br>I'm not sure to understand: to me we are in the usual overload res=
olution mechanism (16.3.3).<br><br>Regards.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><span><div></div><div>Overloading operator[] seems fine, though. It&#=
39;s just a normal binary operator with slightly funny syntax, after all.</=
div><div>=C2=A0</div></span><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir=
=3D"ltr"><div>Thank you in advance for your reviews and comments.</div></di=
v>
<br>
<p style=3D"margin:0px;text-align:left"><font size=3D"1" color=3D"#808080">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font size=3D"1" color=3D"#808080"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<span><font c=
olor=3D"#888888"><br></font></span></i></font></p><span><font color=3D"#888=
888"><p style=3D"margin:0px"><font size=3D"1" color=3D"#808080"><i></i></fo=
nt></p></font></span><p></p></span><span><font color=3D"#888888"><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/8bd2a86c-2b01-491b-8ee9-30d78aa4b35e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8bd2a86c-2b01-491b-<wbr>8ee9-=
30d78aa4b35e%40isocpp.org</a><wbr>.<br>
</span></font></span></blockquote></div><br></div></div>
</blockquote></div><span>
<br>
<p style=3D"margin:0px;text-align:left"><font size=3D"1" color=3D"#808080">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font></p><hr><p></p><p style=3D"mar=
gin:0px"><font size=3D"1" color=3D"#808080"><i>Ce message =C3=A9lectronique=
et =C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusiveme=
nt destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils son=
t adress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, =
vous =C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre=
toute d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d=
9;en aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes=
les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<=
br>Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =
=C3=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Rob=
otics Europe sur toute discussion ou document contractuel quel qu=E2=80=99i=
l soit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=
=C3=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 =
repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=
=A0 agir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans q=
u=E2=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9se=
ntant l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ay=
ant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></fon=
t></p><p style=3D"margin:0px"><font size=3D"1" color=3D"#808080"><i></i></f=
ont></p><p></p>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
b6nU-SlkAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"b6nU-SlkAQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/1ff81804-737c-4999-a27b-8e10608de2cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/1ff81804-737c-4999-a27b-8e10608de2cb%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/1ff81804-737c-4999-a27b-8e10608de2cb%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1ff81804-737c-4999-<wbr>a27b-=
8e10608de2cb%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></div>
<br>
<p style=3D"margin:0px;text-align:left"><font color=3D"#808080" size=3D"1">=
<i><span lang=3D"EN-US">This email and any attachment thereto are confident=
ial and intended solely for the use of the individual or entity to whom the=
y are addressed.<br>If you are not the intended recipient, please be advise=
d that disclosing, copying, distributing or taking any action in reliance o=
n the contents of this email is strictly prohibited. In such case, please i=
mmediately advise the sender, and delete all copies and attachment from you=
r system.<br>This email shall not be construed and is not tantamount to an =
offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe =
on any discussion or contractual document whatsoever. No employee or agent =
is authorized to represent or bind SoftBank Robotics Europe to third partie=
s by email, or act on behalf of SoftBank Robotics Europe by email, without =
express written confirmation by SoftBank Robotics Europe=E2=80=99 duly auth=
orized representatives.<br></span></i></font><hr><p></p><p style=3D"margin:=
0px"><font color=3D"#808080" size=3D"1"><i>Ce message =C3=A9lectronique et =
=C3=A9ventuelles pi=C3=A8ces jointes sont confidentiels, et exclusivement d=
estin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 qui ils sont ad=
ress=C3=A9s.<br>Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous=
=C3=AAtes pri=C3=A9 de ne pas divulguer, copier, distribuer ou prendre tou=
te d=C3=A9cision sur la foi de ce message =C3=A9lectronique. Merci d'en=
aviser imm=C3=A9diatement l'exp=C3=A9diteur et de supprimer toutes les=
copies et =C3=A9ventuelles pi=C3=A8ces jointes de votre syst=C3=A8me.<br>C=
e message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une offre, =C3=
=A0 une acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Roboti=
cs Europe sur toute discussion ou document contractuel quel qu=E2=80=99il s=
oit, et ne peut =C3=AAtre interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=
=A9 ou agent de SoftBank Robotics Europe n'est autoris=C3=A9 =C3=A0 rep=
r=C3=A9senter ou =C3=A0 engager la soci=C3=A9t=C3=A9 par email, ou =C3=A0 a=
gir au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=
=80=99une confirmation =C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentan=
t l=C3=A9gal de SoftBank Robotics Europe ou par toute autre personne ayant =
re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir appropri=C3=A9e.<br></i></font></=
p><p style=3D"margin:0px"><font color=3D"#808080" size=3D"1"><i></i></font>=
</p></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/15a96a9d-e2b8-4d2d-92c4-2751b5e5b41f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15a96a9d-e2b8-4d2d-92c4-2751b5e5b41f=
%40isocpp.org</a>.<br />
------=_Part_1528_1786924401.1498416999432--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Sun, 25 Jun 2017 22:49:31 +0200
Raw View
--001a114da7acad7ddc0552cef8ec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 23 June 2017 at 19:50, Nicol Bolas <jmckesson@gmail.com> wrote:
> OK, first question: what's the syntax for *preventing people* from
> overriding these things on my types?
>
Since C++11 we can "delete" free functions, operators included:
struct Foo
{
};
Foo operator+(const Foo&, const Foo&) =3D delete;
int main()
{
Foo a, b;
auto c =3D a + b; // error: use of deleted function
}
What more do you need to prevent people from overriding these things?
Jo=C3=ABl Lamotte
--=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/CAOU91OOjfwtkcWDzxbzO145Ce2_v6e5xTYjBx671MPuQ9_G=
3XA%40mail.gmail.com.
--001a114da7acad7ddc0552cef8ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 23 June 2017 at 19:50, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>OK, firs=
t question: what's the syntax for <i>preventing people</i> from overrid=
ing these things on my types?</div></blockquote></div><br>Since C++11 we ca=
n "delete" free functions, operators included:</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=3D"gmail_extr=
a">struct Foo</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_ex=
tra">};</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">Foo operator+(const Foo&, const Foo&) =3D delete;</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int main()</div><div =
class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 Foo a=
, b;</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 auto c =3D a + b; // err=
or: use of deleted function</div><div class=3D"gmail_extra">}</div><div><br=
></div><div><br></div><div>What more do you need to prevent people from ove=
rriding these things?</div><div><br></div><div>Jo=C3=ABl Lamotte</div><div>=
<br></div><div><br></div><div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAOU91OOjfwtkcWDzxbzO145Ce2_v6e5xTYjB=
x671MPuQ9_G3XA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OOjfwtkcWDz=
xbzO145Ce2_v6e5xTYjBx671MPuQ9_G3XA%40mail.gmail.com</a>.<br />
--001a114da7acad7ddc0552cef8ec--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 2 Jul 2017 18:40:49 -0700 (PDT)
Raw View
------=_Part_1543_1187035219.1499046049897
Content-Type: multipart/alternative;
boundary="----=_Part_1544_825039548.1499046049897"
------=_Part_1544_825039548.1499046049897
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=885:17:59=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen wrote:
>>
>> On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com=20
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> This is a proposal to allow operator(), operator[] and operator-> to b=
e=20
>>>> defined as non-member functions.
>>>> I do not know if this has already been proposed and potential argument=
s=20
>>>> against it, so please let me know.
>>>>
>>>
>>> OK, first question: what's the syntax for *preventing people* from=20
>>> overriding these things on my types?
>>>
>>
>> Wanting to prevent people from doing things is a bad idea, because the=
=20
>> people who want to do things are living in the future of the people who=
=20
>> want to prevent them from doing things, and the people in the future hav=
e=20
>> better information about what they need than people in the past.
>>
>> In any case, having those functions defined as non-members is no=20
>> different from having any other functions or operators that take such=20
>> objects as parameters. I don't see why operator[] should be treated=20
>> differently than operator+.
>>
>
> First, I contest the idea that `operator()` is no different from the=20
> others. You might argue that with `->` and `[]`, but not function call. T=
he=20
> reason being that `operator()` has no parameter restrictions associated=
=20
> with it; you can overload it with any number of parameters of any type.=
=20
> `operator->` takes no parameters, and `operator[]` takes exactly one=20
> parameter. So the damage you can cause by external overloads is minimal.
>
> But `operator()` can take anything; you can inject entire interfaces into=
=20
> a type through clever use of tag types. Overloading `operator()` from=20
> outside a type is functionally equivalent to allowing you to add=20
> (non-friend) member functions to a type.
>
> Second, my principle objection is that these operations are fundamentally=
=20
> part of the type. If a type is not a pointer-like type, then it has=20
> absolutely no business overloading `operator->`. If a type is not an=20
> array-like type, then it has no business overloading `operator[]`. And if=
a=20
> type is not a function-like type, then it has no business overloading=20
> `operator()`. And these are fundamental properties of the type; they're=
=20
> *not* something you can just graft onto any old type you like.
>
I don't think so. Overloading as construction of EDSL (e.g. in=20
boost.spirit) relies on violating your principles quite heavily.
And you even do not have ways to ensure least astonishment to well-educated=
=20
newbies. Arguably, what is, say, an array-like type? How to make sure a=20
type is like an array *enough*? No doubtfully `std::array` is like an array=
=20
enough, but what like `std::map`? Why no `const` on its `operator[]`?
If you merely need to encode additional information like intention of the=
=20
API to avoid misuse, there are other ways, like attributes.
> We allow overloading `operator+` from outside of a type because we *need=
=20
> to*. That allows you to add two different types. The same goes for most=
=20
> of the rest of the out-of-class overloads; it permits mixing. We allow th=
is=20
> for prefix and postfix unary operators because... well, I have no idea wh=
y,=20
> but I wouldn't have permitted it. Of course, the saving grace there is th=
at=20
> it really doesn't matter, because there can only be *one* pre/postfix=20
> overload for each type, for each unary operator.
>
--=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/0f28aa17-2523-46c1-8869-4eadc8c8051c%40isocpp.or=
g.
------=_Part_1544_825039548.1499046049897
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=885:17:59=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <span dir=3D"ltr=
"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, June 23, 2017 at=
1:03:38 PM UTC-4, <a>jmo...@aldebaran.com</a> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>This is a prop=
osal to allow operator(), operator[] and operator-> to be defined as non=
-member functions.</div><div>I do not know if this has already been propose=
d and potential arguments against it, so please let me know.</div></div></b=
lockquote></span><div><br>OK, first question: what's the syntax for <i>=
preventing people</i> from overriding these things on my types?</div></div>=
</blockquote><div><br>Wanting to prevent people from doing things is a bad =
idea, because the people who want to do things are living in the future of =
the people who want to prevent them from doing things, and the people in th=
e future have better information about what they need than people in the pa=
st.<br><br>In any case, having those functions defined as non-members is no=
different from having any other functions or operators that take such obje=
cts as parameters.=C2=A0 I don't see why operator[] should be treated d=
ifferently than operator+.</div></div></div></div></blockquote><div><br>Fir=
st, I contest the idea that `operator()` is no different from the others. Y=
ou might argue that with `->` and `[]`, but not function call. The reaso=
n being that `operator()` has no parameter restrictions associated with it;=
you can overload it with any number of parameters of any type. `operator-&=
gt;` takes no parameters, and `operator[]` takes exactly one parameter. So =
the damage you can cause by external overloads is minimal.<br><br>But `oper=
ator()` can take anything; you can inject entire interfaces into a type thr=
ough clever use of tag types. Overloading `operator()` from outside a type =
is functionally equivalent to allowing you to add (non-friend) member funct=
ions to a type.<br><br>Second, my principle objection is that these operati=
ons are fundamentally part of the type. If a type is not a pointer-like typ=
e, then it has absolutely no business overloading `operator->`. If a typ=
e is not an array-like type, then it has no business overloading `operator[=
]`. And if a type is not a function-like type, then it has no business over=
loading `operator()`. And these are fundamental properties of the type; the=
y're <i>not</i> something you can just graft onto any old type you like=
..<br></div></div></blockquote><div>I don't think so. Overloading as con=
struction of=C2=A0 EDSL (e.g. in boost.spirit) relies on violating your pri=
nciples quite heavily.<br></div><div><br></div><div>And you even do not hav=
e ways to ensure least astonishment to well-educated newbies. Arguably, wha=
t is, say, an array-like type? How to make sure a type is like an array <i>=
enough</i>? No doubtfully `std::array` is like an array enough, but what li=
ke `std::map`? Why no `const` on its `operator[]`?<br></div><div><br></div>=
<div>If you merely need to encode additional information like intention of =
the API to avoid misuse, there are other ways, like attributes.<br></div><d=
iv> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br>We allow overloading `operator+` from outside of a type because w=
e <i>need to</i>. That allows you to add two different types. The same goes=
for most of the rest of the out-of-class overloads; it permits mixing. We =
allow this for prefix and postfix unary operators because... well, I have n=
o idea why, but I wouldn't have permitted it. Of course, the saving gra=
ce there is that it really doesn't matter, because there can only be <i=
>one</i> pre/postfix overload for each type, for each unary operator.<br></=
div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/0f28aa17-2523-46c1-8869-4eadc8c8051c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f28aa17-2523-46c1-8869-4eadc8c8051c=
%40isocpp.org</a>.<br />
------=_Part_1544_825039548.1499046049897--
------=_Part_1543_1187035219.1499046049897--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 2 Jul 2017 20:11:48 -0700 (PDT)
Raw View
------=_Part_385_659003092.1499051509014
Content-Type: multipart/alternative;
boundary="----=_Part_386_595840133.1499051509015"
------=_Part_386_595840133.1499051509015
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, July 2, 2017 at 9:40:50 PM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=885:17:59=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen wrote:
>>>
>>> On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com=20
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> This is a proposal to allow operator(), operator[] and operator-> to=
=20
>>>>> be defined as non-member functions.
>>>>> I do not know if this has already been proposed and potential=20
>>>>> arguments against it, so please let me know.
>>>>>
>>>>
>>>> OK, first question: what's the syntax for *preventing people* from=20
>>>> overriding these things on my types?
>>>>
>>>
>>> Wanting to prevent people from doing things is a bad idea, because the=
=20
>>> people who want to do things are living in the future of the people who=
=20
>>> want to prevent them from doing things, and the people in the future ha=
ve=20
>>> better information about what they need than people in the past.
>>>
>>> In any case, having those functions defined as non-members is no=20
>>> different from having any other functions or operators that take such=
=20
>>> objects as parameters. I don't see why operator[] should be treated=20
>>> differently than operator+.
>>>
>>
>> First, I contest the idea that `operator()` is no different from the=20
>> others. You might argue that with `->` and `[]`, but not function call. =
The=20
>> reason being that `operator()` has no parameter restrictions associated=
=20
>> with it; you can overload it with any number of parameters of any type.=
=20
>> `operator->` takes no parameters, and `operator[]` takes exactly one=20
>> parameter. So the damage you can cause by external overloads is minimal.
>>
>> But `operator()` can take anything; you can inject entire interfaces int=
o=20
>> a type through clever use of tag types. Overloading `operator()` from=20
>> outside a type is functionally equivalent to allowing you to add=20
>> (non-friend) member functions to a type.
>>
>> Second, my principle objection is that these operations are fundamentall=
y=20
>> part of the type. If a type is not a pointer-like type, then it has=20
>> absolutely no business overloading `operator->`. If a type is not an=20
>> array-like type, then it has no business overloading `operator[]`. And i=
f a=20
>> type is not a function-like type, then it has no business overloading=20
>> `operator()`. And these are fundamental properties of the type; they're=
=20
>> *not* something you can just graft onto any old type you like.
>>
> I don't think so. Overloading as construction of EDSL (e.g. in=20
> boost.spirit) relies on violating your principles quite heavily.
>
My argument is not that you shouldn't be able to overload *any* operator=20
from outside the type. My argument is that you shouldn't be able to=20
overload *those* operators from outside of the type. If the maker of a type=
=20
didn't give it an `operator[]` overload, you don't have the right to impose=
=20
one upon it.
We've been able to make EDSLs despite being unable to overload those=20
operators from outside the type.
=20
> And you even do not have ways to ensure least astonishment to=20
> well-educated newbies. Arguably, what is, say, an array-like type? How to=
=20
> make sure a type is like an array *enough*? No doubtfully `std::array` is=
=20
> like an array enough, but what like `std::map`? Why no `const` on its=20
> `operator[]`?
>
It's interesting that you bring up `map`'s `operator[]`, because that was=
=20
on my mind back when I posted that. If we had it to do over again, I rather=
=20
suspect that `map` would *not* have an `operator[]` overload. We've had to=
=20
patch `map`'s design just to address deficiencies in `operator[]`, with=20
`try_emplace` and `insert_or_assign` effectively doing much the job of=20
`operator[]` much better than that function ever could.
If we still had to keep it around, it'd probably be a `const` function.
--=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/5f1f1b92-0c91-43be-bfef-bd3a64e98eb6%40isocpp.or=
g.
------=_Part_386_595840133.1499051509015
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 2, 2017 at 9:40:50 PM UTC-4, FrankHB1989 w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=E5=9C=
=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=
=B8=8A=E5=8D=885:17:59=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, June 23, 2017=
at 3:10:38 PM UTC-4, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jun 23, 2017 =
at 1:50 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@g=
mail.com</a>></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>On Friday, June 23, 2017 at 1:03:38 PM UTC-4, <a>jmo...@alde=
baran.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Hello,<div><br></div><div>This is a proposal to allow operator(), operato=
r[] and operator-> to be defined as non-member functions.</div><div>I do=
not know if this has already been proposed and potential arguments against=
it, so please let me know.</div></div></blockquote></span><div><br>OK, fir=
st question: what's the syntax for <i>preventing people</i> from overri=
ding these things on my types?</div></div></blockquote><div><br>Wanting to =
prevent people from doing things is a bad idea, because the people who want=
to do things are living in the future of the people who want to prevent th=
em from doing things, and the people in the future have better information =
about what they need than people in the past.<br><br>In any case, having th=
ose functions defined as non-members is no different from having any other =
functions or operators that take such objects as parameters.=C2=A0 I don=
9;t see why operator[] should be treated differently than operator+.</div><=
/div></div></div></blockquote><div><br>First, I contest the idea that `oper=
ator()` is no different from the others. You might argue that with `->` =
and `[]`, but not function call. The reason being that `operator()` has no =
parameter restrictions associated with it; you can overload it with any num=
ber of parameters of any type. `operator->` takes no parameters, and `op=
erator[]` takes exactly one parameter. So the damage you can cause by exter=
nal overloads is minimal.<br><br>But `operator()` can take anything; you ca=
n inject entire interfaces into a type through clever use of tag types. Ove=
rloading `operator()` from outside a type is functionally equivalent to all=
owing you to add (non-friend) member functions to a type.<br><br>Second, my=
principle objection is that these operations are fundamentally part of the=
type. If a type is not a pointer-like type, then it has absolutely no busi=
ness overloading `operator->`. If a type is not an array-like type, then=
it has no business overloading `operator[]`. And if a type is not a functi=
on-like type, then it has no business overloading `operator()`. And these a=
re fundamental properties of the type; they're <i>not</i> something you=
can just graft onto any old type you like.<br></div></div></blockquote><di=
v>I don't think so. Overloading as construction of=C2=A0 EDSL (e.g. in =
boost.spirit) relies on violating your principles quite heavily.<br></div><=
/div></blockquote><div><br>My argument is not that you shouldn't be abl=
e to overload <i>any</i> operator from outside the type. My argument is tha=
t you shouldn't be able to overload <i>those</i> operators from outside=
of the type. If the maker of a type didn't give it an `operator[]` ove=
rload, you don't have the right to impose one upon it.<br><br>We've=
been able to make EDSLs despite being unable to overload those operators f=
rom outside the type.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div></div><div></div><div>And you even do not have=
ways to ensure least astonishment to well-educated newbies. Arguably, what=
is, say, an array-like type? How to make sure a type is like an array <i>e=
nough</i>? No doubtfully `std::array` is like an array enough, but what lik=
e `std::map`? Why no `const` on its `operator[]`?<br></div></div></blockquo=
te><div><br>It's interesting that you bring up `map`'s `operator[]`=
, because that was on my mind back when I posted that. If we had it to do o=
ver again, I rather suspect that `map` would <i>not</i> have an `operator[]=
` overload. We've had to patch `map`'s design just to address defic=
iencies in `operator[]`, with `try_emplace` and `insert_or_assign` effectiv=
ely doing much the job of `operator[]` much better than that function ever =
could.<br><br>If we still had to keep it around, it'd probably be a `co=
nst` function.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5f1f1b92-0c91-43be-bfef-bd3a64e98eb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f1f1b92-0c91-43be-bfef-bd3a64e98eb6=
%40isocpp.org</a>.<br />
------=_Part_386_595840133.1499051509015--
------=_Part_385_659003092.1499051509014--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 2 Jul 2017 20:44:50 -0700 (PDT)
Raw View
------=_Part_1549_1092736742.1499053490162
Content-Type: multipart/alternative;
boundary="----=_Part_1550_2119106057.1499053490163"
------=_Part_1550_2119106057.1499053490163
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=887:40:35=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Friday, June 23, 2017 at 6:51:43 PM UTC-4, Hyman Rosen wrote:
>>
>> On Fri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> So the damage you can cause
>>>
>>
>> What makes it "damage"?
>>
>
> You have taken a type which was not a functor and made it a functor. You=
=20
> have taken a type that was not array-like or pointer-like and made it=20
> array/pointer-like.
>
> If those are not the purpose of those types, then you have damaged that=
=20
> type's interface by violating the single responsibility principle.
>
> You are assuming the functionality implemented by overloading as=20
"responsibility". But the language rules does not work like that. There are=
=20
no disciplines enforced by the language to make syntactic forms coming with=
=20
specific semantics restrictions tightly in general (more than special rules=
=20
like C#'s composition of overloaded operators). They are all up to the=20
users. What you suggested is assuming implicit requirements on allowed=20
types, that does not improve readability or productivity by itself. If you=
=20
do need it, propose it to make the spec of the language agree.
Nevertheless, to provide overloading functions by the author of the class=
=20
type or not, is not relevant much here, and I am not strongly against it.
But `operator()` can take anything; you can inject entire interfaces into a=
=20
>>> type through clever use of tag types. Overloading `operator()` from out=
side=20
>>> a type is functionally equivalent to allowing you to add (non-friend)=
=20
>>> member functions to a type.
>>>
>>
>> And that could lead to dancing? What exactly is the problem here? It=
=20
>> makes that much of a difference to deny saying Object(a, b, c) and=20
>> forcing people to say Apply(Object, a, b, c)?
>>
>
> Yes! If I wanted `Object(a, b, c)` to be a meaningful interface in my=20
> class, then *I would have put it there*.
>
> Your logic could be just as easily used to say that we should allow anyon=
e=20
> to inject any member function into any class type we want. If that's what=
=20
> you want, then that is what should be proposed. And if we don't want that=
,=20
> then we definitely don't want `operator()` overloading, which is the=20
> effective equivalent of it.
>
> As is, a type that has a member function template makes even its private=
=20
>> members accessible to everyone, so privacy is dead anyway:
>>
>
> No, privacy is not dead. It is still restricted to just that template.=20
> Sure, users can specialize that template using types that didn't exist wh=
en=20
> you wrote it. But privacy is still restricted to exactly and only those=
=20
> template specializations. It doesn't go everywhere.
>
> And even if it did, your argument is essentially that every class should=
=20
> be open to injection of any member functions that anyone likes.
>
--=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/ad9a6cef-6829-498c-aa7a-04fadafa2685%40isocpp.or=
g.
------=_Part_1550_2119106057.1499053490163
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=887:40:35=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Friday, June 23, 2017 at 6:51:43 PM UTC-4, Hyman Rosen wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Fri, Jun 23, 2017 at 5:17 PM, Nicol Bolas <span dir=3D"ltr=
"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>So the damage you can cause<=
br></div></div></blockquote><div><br>What makes it "damage"?<br><=
/div></div></div></div></blockquote><div><br>You have taken a type which wa=
s not a functor and made it a functor. You have taken a type that was not a=
rray-like or pointer-like and made it array/pointer-like.<br><br>If those a=
re not the purpose of those types, then you have damaged that type's in=
terface by violating the single responsibility principle.<br><br></div></di=
v></blockquote><div>You are assuming the functionality implemented by overl=
oading as "responsibility". But the language rules does not work =
like that. There are no disciplines enforced by the language to make syntac=
tic forms coming with specific semantics restrictions tightly in general (m=
ore than special rules like C#'s composition of overloaded operators). =
They are all up to the users. What you suggested is assuming implicit requi=
rements on allowed types, that does not improve readability or productivity=
by itself. If you do need it, propose it to make the spec of the language =
agree.<br></div><div><br></div><div>Nevertheless, to provide overloading fu=
nctions by the author of the class type or not, is not relevant much here, =
and I am not strongly against it.<br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But `operator(=
)` can take anything; you can inject entire interfaces into a type through =
clever use of tag types. Overloading `operator()` from outside a type is fu=
nctionally equivalent to allowing you to add (non-friend) member functions =
to a type.</div></div></blockquote><div><br>And that could lead to dancing?=
=C2=A0 What exactly is the problem here?=C2=A0 It makes that much of a diff=
erence to deny saying=C2=A0<font face=3D"monospace, monospace">Object(a, b,=
c)</font>=C2=A0and forcing people to say=C2=A0<font face=3D"monospace, mon=
ospace">Apply(Object, a, b, c)</font>?<br></div></div></div></div></blockqu=
ote><div><br>Yes! If I wanted `Object(a, b, c)` to be a meaningful interfac=
e in my class, then <i>I would have put it there</i>.<br><br>Your logic cou=
ld be just as easily used to say that we should allow anyone to inject any =
member function into any class type we want. If that's what you want, t=
hen that is what should be proposed. And if we don't want that, then we=
definitely don't want `operator()` overloading, which is the effective=
equivalent of it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>As is, a type that has a=
member function template makes even its private members accessible to ever=
yone, so privacy is dead anyway:<br></div></div></div></div></blockquote><d=
iv><br>No, privacy is not dead. It is still restricted to just that templat=
e. Sure, users can specialize that template using types that didn't exi=
st when you wrote it. But privacy is still restricted to exactly and only t=
hose template specializations. It doesn't go everywhere.</div><br>And e=
ven if it did, your argument is essentially that every class should be open=
to injection of any member functions that anyone likes.<br></div></blockqu=
ote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ad9a6cef-6829-498c-aa7a-04fadafa2685%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad9a6cef-6829-498c-aa7a-04fadafa2685=
%40isocpp.org</a>.<br />
------=_Part_1550_2119106057.1499053490163--
------=_Part_1549_1092736742.1499053490162--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 2 Jul 2017 21:44:35 -0700 (PDT)
Raw View
------=_Part_492_302660294.1499057076036
Content-Type: multipart/alternative;
boundary="----=_Part_493_1306111468.1499057076037"
------=_Part_493_1306111468.1499057076037
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B47=E6=9C=883=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=8811:11:49=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sunday, July 2, 2017 at 9:40:50 PM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=885:17:59=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Friday, June 23, 2017 at 3:10:38 PM UTC-4, Hyman Rosen wrote:
>>>>
>>>> On Fri, Jun 23, 2017 at 1:50 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>
>>>>> On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com=20
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> This is a proposal to allow operator(), operator[] and operator-> to=
=20
>>>>>> be defined as non-member functions.
>>>>>> I do not know if this has already been proposed and potential=20
>>>>>> arguments against it, so please let me know.
>>>>>>
>>>>>
>>>>> OK, first question: what's the syntax for *preventing people* from=20
>>>>> overriding these things on my types?
>>>>>
>>>>
>>>> Wanting to prevent people from doing things is a bad idea, because the=
=20
>>>> people who want to do things are living in the future of the people wh=
o=20
>>>> want to prevent them from doing things, and the people in the future h=
ave=20
>>>> better information about what they need than people in the past.
>>>>
>>>> In any case, having those functions defined as non-members is no=20
>>>> different from having any other functions or operators that take such=
=20
>>>> objects as parameters. I don't see why operator[] should be treated=
=20
>>>> differently than operator+.
>>>>
>>>
>>> First, I contest the idea that `operator()` is no different from the=20
>>> others. You might argue that with `->` and `[]`, but not function call.=
The=20
>>> reason being that `operator()` has no parameter restrictions associated=
=20
>>> with it; you can overload it with any number of parameters of any type.=
=20
>>> `operator->` takes no parameters, and `operator[]` takes exactly one=20
>>> parameter. So the damage you can cause by external overloads is minimal=
..
>>>
>>> But `operator()` can take anything; you can inject entire interfaces=20
>>> into a type through clever use of tag types. Overloading `operator()` f=
rom=20
>>> outside a type is functionally equivalent to allowing you to add=20
>>> (non-friend) member functions to a type.
>>>
>>> Second, my principle objection is that these operations are=20
>>> fundamentally part of the type. If a type is not a pointer-like type, t=
hen=20
>>> it has absolutely no business overloading `operator->`. If a type is no=
t an=20
>>> array-like type, then it has no business overloading `operator[]`. And =
if a=20
>>> type is not a function-like type, then it has no business overloading=
=20
>>> `operator()`. And these are fundamental properties of the type; they're=
=20
>>> *not* something you can just graft onto any old type you like.
>>>
>> I don't think so. Overloading as construction of EDSL (e.g. in=20
>> boost.spirit) relies on violating your principles quite heavily.
>>
>
> My argument is not that you shouldn't be able to overload *any* operator=
=20
> from outside the type. My argument is that you shouldn't be able to=20
> overload *those* operators from outside of the type. If the maker of a=20
> type didn't give it an `operator[]` overload, you don't have the right to=
=20
> impose one upon it.
>
> Well, that's somewhat OK. But the point has diverged.
We've been able to make EDSLs despite being unable to overload those=20
> operators from outside the type.
> =20
>
>> And you even do not have ways to ensure least astonishment to=20
>> well-educated newbies. Arguably, what is, say, an array-like type? How t=
o=20
>> make sure a type is like an array *enough*? No doubtfully `std::array`=
=20
>> is like an array enough, but what like `std::map`? Why no `const` on its=
=20
>> `operator[]`?
>>
>
> It's interesting that you bring up `map`'s `operator[]`, because that was=
=20
> on my mind back when I posted that. If we had it to do over again, I rath=
er=20
> suspect that `map` would *not* have an `operator[]` overload. We've had=
=20
> to patch `map`'s design just to address deficiencies in `operator[]`, wit=
h=20
> `try_emplace` and `insert_or_assign` effectively doing much the job of=20
> `operator[]` much better than that function ever could.
>
> Yes, interesting. But on this topic I don't follow you. This is because=
=20
you seem to suggest array as C-like (or std::vector-like, providing some=20
assumptions of memory layout among elements) ones, but it need not to be=20
true.
In fact, the built-in [] in C and C++ relies on semantics of pointers,=20
which is not specific to abstraction exposed by the notion "array" (in=20
general) at all, just implementation details of the specific builtin types=
=20
in C and C++. Arguably, I think C's builtin array named badly. Those types=
=20
should better be called "vectors", following the prior art of B language,=
=20
also reducing the confusion with notions from math (despite of Iliffe=20
vector in Java, etc). (And `std::vector` should have better been=20
`std::array`, `std::dynarray` or something else.) On the other hand, `map`=
=20
or `unordered_map` are instances of *associative arrays*, or something=20
*indexable*, which catches the notion behind "array" or [] well among all=
=20
kinds of C-like languages (including those without pointers). Overloading=
=20
of `operator[]` would perfectly make `[]` bind with those types and provide=
=20
the the principal method of element access in a neat way.
If we still had to keep it around, it'd probably be a `const` function.
>
=20
To fix the const qualifier inconsistency is not as important as this=20
abstraction; as long as the const-correctness being well kept, why force=20
`const` on `[]`? Index with `const` is a more detailed capability only=20
supported by some subsets of associative arrays and something supported by=
=20
builtin array types are just not so generic, that's all.
Moreover, similar confusions also exist in the term "function". How do you=
=20
define the term "function"? If you take the builtin ones, lack of=20
first-class function in C has already make the thing in a mess. Since a=20
first-class function (implemented as closures, in general) significantly=20
needs more complicated data structures rather than a wrapper like=20
`std::array`, the terminology divergence has more damage on well-defined=20
notions from history of computer science. Things are even worse because=20
there are more complex problems on functions besides first-classness. For=
=20
example, reference transparency or more aggressively, "purity", which is=20
sensible in the origin of the term "function" (in math). Just because this=
=20
property has widely broken in languages with side effects, you may not care=
=20
it at all when talking with people only with a background of ALGOL-like=20
languages, but it is still a serious problem to draft the specification=20
once you want the language supporting multiple paradigms. Another example,=
=20
the evaluation strategy, which should be a new orthogonal aspect of=20
function of C++. Functions in some other languages support call-by-need and=
=20
even more esoteric ones, and are they allowed to be introduced in a future=
=20
version of C++, despite there are something more similar already called as=
=20
"macros"?
I don't think all of them are interesting and meaningful to C++, but I=20
still don't think to limit extentions of terms as you think is a right way=
=20
to work with the spec of a general-purposed language.
--=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/f26f0d32-756a-422f-a5be-74c0627206f3%40isocpp.or=
g.
------=_Part_493_1306111468.1499057076037
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B47=E6=9C=883=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8811:11:49=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Sunday, July 2, 2017 at 9:40:50 PM UTC-4, FrankHB1989 wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2017=
=E5=B9=B46=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=
=8D=885:17:59=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">On Friday, June 23, 2017 at 3:10:=
38 PM UTC-4, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jun 23, 2017 at 1:50 P=
M, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com<=
/a>></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"><s=
pan>On Friday, June 23, 2017 at 1:03:38 PM UTC-4, <a>jmo...@aldebaran.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">Hello,<di=
v><br></div><div>This is a proposal to allow operator(), operator[] and ope=
rator-> to be defined as non-member functions.</div><div>I do not know i=
f this has already been proposed and potential arguments against it, so ple=
ase let me know.</div></div></blockquote></span><div><br>OK, first question=
: what's the syntax for <i>preventing people</i> from overriding these =
things on my types?</div></div></blockquote><div><br>Wanting to prevent peo=
ple from doing things is a bad idea, because the people who want to do thin=
gs are living in the future of the people who want to prevent them from doi=
ng things, and the people in the future have better information about what =
they need than people in the past.<br><br>In any case, having those functio=
ns defined as non-members is no different from having any other functions o=
r operators that take such objects as parameters.=C2=A0 I don't see why=
operator[] should be treated differently than operator+.</div></div></div>=
</div></blockquote><div><br>First, I contest the idea that `operator()` is =
no different from the others. You might argue that with `->` and `[]`, b=
ut not function call. The reason being that `operator()` has no parameter r=
estrictions associated with it; you can overload it with any number of para=
meters of any type. `operator->` takes no parameters, and `operator[]` t=
akes exactly one parameter. So the damage you can cause by external overloa=
ds is minimal.<br><br>But `operator()` can take anything; you can inject en=
tire interfaces into a type through clever use of tag types. Overloading `o=
perator()` from outside a type is functionally equivalent to allowing you t=
o add (non-friend) member functions to a type.<br><br>Second, my principle =
objection is that these operations are fundamentally part of the type. If a=
type is not a pointer-like type, then it has absolutely no business overlo=
ading `operator->`. If a type is not an array-like type, then it has no =
business overloading `operator[]`. And if a type is not a function-like typ=
e, then it has no business overloading `operator()`. And these are fundamen=
tal properties of the type; they're <i>not</i> something you can just g=
raft onto any old type you like.<br></div></div></blockquote><div>I don'=
;t think so. Overloading as construction of=C2=A0 EDSL (e.g. in boost.spiri=
t) relies on violating your principles quite heavily.<br></div></div></bloc=
kquote><div><br>My argument is not that you shouldn't be able to overlo=
ad <i>any</i> operator from outside the type. My argument is that you shoul=
dn't be able to overload <i>those</i> operators from outside of the typ=
e. If the maker of a type didn't give it an `operator[]` overload, you =
don't have the right to impose one upon it.<br><br></div></div></blockq=
uote><div>Well, that's somewhat OK. But the point has diverged.</div><d=
iv> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>We've been able to make EDSLs despite being unable to overload th=
ose operators from outside the type.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>And you even d=
o not have ways to ensure least astonishment to well-educated newbies. Argu=
ably, what is, say, an array-like type? How to make sure a type is like an =
array <i>enough</i>? No doubtfully `std::array` is like an array enough, bu=
t what like `std::map`? Why no `const` on its `operator[]`?<br></div></div>=
</blockquote><div><br>It's interesting that you bring up `map`'s `o=
perator[]`, because that was on my mind back when I posted that. If we had =
it to do over again, I rather suspect that `map` would <i>not</i> have an `=
operator[]` overload. We've had to patch `map`'s design just to add=
ress deficiencies in `operator[]`, with `try_emplace` and `insert_or_assign=
` effectively doing much the job of `operator[]` much better than that func=
tion ever could.<br><br></div></div></blockquote><div>Yes, interesting. But=
on this topic I don't follow you. This is because you seem to suggest =
array as C-like (or std::vector-like, providing some assumptions of memory =
layout among elements) ones, but it need not to be true.</div><div><br></di=
v><div>In fact, the built-in [] in C and C++ relies on semantics of pointer=
s, which is not specific to abstraction exposed by the notion "array&q=
uot; (in general) at all, just implementation details of the specific built=
in types in C and C++. Arguably, I think C's builtin array named badly.=
Those types should=20
better be called "vectors", following the prior art of B language=
, also=20
reducing the confusion with notions from math (despite of Iliffe vector=20
in Java, etc). (And `std::vector` should have better been `std::array`,=20
`std::dynarray` or something else.) On the other hand, `map` or `unordered_=
map` are instances of <i>associative arrays</i>, or something <i>indexable<=
/i>, which catches the notion behind "array" or [] well among all=
kinds of C-like languages (including those without pointers). Overloading =
of `operator[]` would perfectly make `[]` bind with those types and provide=
the the principal method of element access in a neat way.<br></div><div><b=
r></div><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"><div>=
If we still had to keep it around, it'd probably be a `const` function.=
</div></div></blockquote><div>=C2=A0</div><div>To fix the const qualifier i=
nconsistency is not as important as this=20
abstraction; as long as the const-correctness being well kept, why force
`const` on `[]`? Index with `const` is a more detailed capability only=20
supported by some subsets of associative arrays and something supported=20
by builtin array types are just not so generic, that's all.</div><div><=
br></div><div><div>Moreover, similar confusions also exist in the term &quo=
t;function". How do you=20
define the term "function"? If you take the builtin ones, lack of=
=20
first-class function in C has already make the thing in a mess. Since a=20
first-class function (implemented as closures, in general) significantly
needs more complicated data structures rather than a wrapper like=20
`std::array`, the terminology divergence has more damage on well-defined
notions from history of computer science. Things are even worse because
there are more complex problems on functions besides first-classness.=20
For example, reference transparency or more aggressively, "purity"=
;,=20
which is sensible in the origin of the term "function" (in math).=
Just=20
because this property has widely broken in languages with side effects,=20
you may not care it at all when talking with people only with a=20
background of ALGOL-like languages, but it is still a serious problem to
draft the specification once you want the language supporting multiple=20
paradigms. Another example, the evaluation strategy, which should be a=20
new orthogonal aspect of function of C++. Functions in some other=20
languages support call-by-need and even more esoteric ones, and are they
allowed to be introduced in a future version of C++, despite there are=20
something more similar already called as "macros"?<br></div><div>=
<br></div><div>I
don't think all of them are interesting and meaningful to C++, but I=
=20
still don't think to limit extentions of terms as you think is a right=
=20
way to work with the spec of a general-purposed language.<br></div><div><br=
></div><div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f26f0d32-756a-422f-a5be-74c0627206f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f26f0d32-756a-422f-a5be-74c0627206f3=
%40isocpp.org</a>.<br />
------=_Part_493_1306111468.1499057076037--
------=_Part_492_302660294.1499057076036--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 8 Aug 2017 13:37:46 -0400
Raw View
On 2017-06-25 14:56, jmonnon@aldebaran.com wrote:
> Le dimanche 25 juin 2017 01:18:39 UTC+2, Richard Smith a =C3=A9crit :
>> I think there's also a question of whether you'd apply operator()=20
>> recursively: if we can rewrite f(a, b, c) as operator()(f, a, b, c), do =
we=20
>> then need to check whether we need to rewrite *that* as=20
>> operator()(operator(), f, a, b, c) and so on? Likewise, can a + b be=20
>> interpreted as operator()(operator+, a, b)?
>=20
> I'm not sure to understand: to me we are in the usual overload resolution=
=20
> mechanism (16.3.3).
template <typename... Args>
auto operator()(Args...) { /* code here */ }
f(); // infinite recursion?
--=20
Matthew
--=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/1995b18c-95a5-3d1b-e32c-2204d4c41bc5%40gmail.com=
..
.
Author: olafvdspek@gmail.com
Date: Wed, 9 Aug 2017 05:13:22 -0700 (PDT)
Raw View
------=_Part_2701_1480431007.1502280803202
Content-Type: multipart/alternative;
boundary="----=_Part_2702_693816148.1502280803202"
------=_Part_2702_693816148.1502280803202
Content-Type: text/plain; charset="UTF-8"
I've wanted to use operator[] on some library classes before and couldn't..
until I took over maintenance of the library.
I think allowing those to be defined a free functions would be useful.
--
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/96d1c410-a702-4b9a-b448-f288063920d3%40isocpp.org.
------=_Part_2702_693816148.1502280803202
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've wanted to use operator[] on some library classes =
before and couldn't.. until I took over maintenance of the library.<div=
><br></div><div>I think allowing those to be defined a free functions would=
be useful.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/96d1c410-a702-4b9a-b448-f288063920d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96d1c410-a702-4b9a-b448-f288063920d3=
%40isocpp.org</a>.<br />
------=_Part_2702_693816148.1502280803202--
------=_Part_2701_1480431007.1502280803202--
.
Author: Nasos <steve.rodeen@gmail.com>
Date: Mon, 11 Sep 2017 14:10:38 -0700 (PDT)
Raw View
------=_Part_2749_1488369275.1505164238381
Content-Type: multipart/alternative;
boundary="----=_Part_2750_1295829826.1505164238381"
------=_Part_2750_1295829826.1505164238381
Content-Type: text/plain; charset="UTF-8"
I would find this functionallity very handy. Especially when I want to
provide my library users with the ability to extend relevant operators and
I am not sure why they are currently restricted to member functions only.
I don't share any of the previous rejecting comments, especially because
(as others have mentioned) other operators are allowed to be overloaded
and even deleted. In addition the compiler can easily detect an ambiguous
overload if one is attempted by mistake, so I don't see a problem there.
-Nasos
On Friday, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:
>
> Hello,
>
> This is a proposal to allow operator(), operator[] and operator-> to be
> defined as non-member functions.
> I do not know if this has already been proposed and potential arguments
> against it, so please let me know.
>
> The main motivation for this proposal is consistency. It makes also easier
> to externally adapt existing types for use with generic algorithms, as show
> examples.
>
> Thank you in advance for your reviews and comments.
>
--
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/bd2e939b-ad4f-438a-aa41-f8e37060c1b5%40isocpp.org.
------=_Part_2750_1295829826.1505164238381
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would find this functionallity very handy. Especially wh=
en I want to provide my library users with the ability to extend relevant o=
perators and I am not sure why they are currently restricted to member func=
tions only.<br><br>I don't share any of the previous rejecting comments=
, especially=C2=A0 because (as others have mentioned)=C2=A0=C2=A0 other ope=
rators are allowed to be overloaded and even deleted. In addition the compi=
ler can easily detect an ambiguous overload if one is attempted by mistake,=
so I don't see a problem there.<br><br>-Nasos<br><br><br><br>On Friday=
, June 23, 2017 at 1:03:38 PM UTC-4, jmo...@aldebaran.com wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hello,<div><br></div><di=
v>This is a proposal to allow operator(), operator[] and operator-> to b=
e defined as non-member functions.</div><div>I do not know if this has alre=
ady been proposed and potential arguments against it, so please let me know=
..</div><div><br></div><div>The main motivation for this proposal is consist=
ency. It makes also easier to externally adapt existing types for use with =
generic algorithms, as show examples.</div><div><br></div><div>Thank you in=
advance for your reviews and comments.</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/bd2e939b-ad4f-438a-aa41-f8e37060c1b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bd2e939b-ad4f-438a-aa41-f8e37060c1b5=
%40isocpp.org</a>.<br />
------=_Part_2750_1295829826.1505164238381--
------=_Part_2749_1488369275.1505164238381--
.