Topic: paper: Defaulted comparison operators
Author: oleg.smolsky@gmail.com
Date: Thu, 26 Dec 2013 18:35:39 -0800 (PST)
Raw View
------=_Part_4267_27657409.1388111739061
Content-Type: multipart/alternative;
boundary="----=_Part_4268_8528884.1388111739061"
------=_Part_4268_8528884.1388111739061
Content-Type: text/plain; charset=ISO-8859-1
Hi all, I've written up the discussion into a paper, attempted to provide
the minimal standardese and implemented a prototype in Clang. The draft is
attached and I had asked Alisdair Meredith for a proposal number.
I realize that operator!=(), operator>=(), operator>() and operator<=() are
contentious as people may choose to derive them in weird ways... So, I'll
treat them as secondary goals. The primary goal is to generate the
following member functions:
bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4268_8528884.1388111739061
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><font size="2"><span style="font-family: arial,sans-serif;">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=(), operator>=(), operator>() and operator<=()
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary goal is to generate the following member functions:<br><br>
</span></font><pre><font size="2"><span style="font-family: arial,sans-serif;"> bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b<br><br></span></font></pre><font size="2"><span style="font-family: arial,sans-serif;">
Oleg.</span></font></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_4268_8528884.1388111739061--
------=_Part_4267_27657409.1388111739061
Content-Type: text/html; charset=US-ASCII; name=equality.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=equality.html
X-Attachment-Id: 90af9ed5-f086-4f5d-ac99-1349a1a0280e
Content-ID: <90af9ed5-f086-4f5d-ac99-1349a1a0280e>
<html><head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Defaulted comparison operators</title>
<style type="text/css">
..addition {
background-color: #66FF99;
}
..removal {
text-decoration: line-through;
}
</style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="619">
<tr>
<td width="167" align="left" valign="top">Document number:</td>
<td width="452"><i>Nnnnn=yy-nnnn</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Date:</td>
<td width="452"><i>2013-12-21</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Project:</td>
<td width="452">Programming Language C++, Language Evolution Working Group</td>
</tr>
<tr>
<td width="167" align="left" valign="top">Reply-to:</td>
<td width="452">Oleg Smolsky <a href="mailto:oleg.smolsky@gmail.com">oleg.smolsky@gmail.com</a></td>
</tr>
</table>
<h1>I. Introduction</h1>
<p>Provide means of generating default equality, inequality and comparison member operators
for user-defined types. This is strictly
an "opt in" feature so that semantics of existing code remain intact.
<h1>II. Motivation and scope</h1>
<p>This feature would be useful for modern C++ code that operates with types
composed of "regular" members. The definition of equality is trivial in such cases -
member-wise comparison. Inequality can then be generated as an inverse.
<p>This proposal is based on the notion of "regular" types that naturally compose. Such
cases are becoming more prevalent as people program more with value types and writing
(in)equality manually becomes tiresome. This is especially true when trying to
lexicographically compare members.
<h1>III. Design decisions</h1>
<h3>The proposed syntax</h3>
Member-wise generation of special functions is already present in the Standard (see secion 12),
so it seems naturation to extend the syntax to cover comparison member functions.
The proposed syntax for generating the new "defaulted" member functions is as follows:
<pre>
struct Thing {
int a, b, c, d;
bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b
bool operator!=(const Thing &) const = default; // 2
bool operator>=(const Thing &) const = default; // 3a
bool operator>(const Thing &) const = default; // 3b
bool operator<=(const Thing &) const = default; // 3c
};</pre>
<p>Aformentioned should generate definitions compatible to the following example:
<pre>
bool Thing::operator==(const Thing &r) const {
return a == r.a && b == r.b && c == r.c && d == r.d;
}
bool Thing::operator<(const Thing &r) const {
return std::tie(a, b, c, d) < std::tie(r.a, r.b, r.c, r.d);
}
bool Thing::operator!=(const Thing &r) const {
return !(*this == r);
}
bool Thing::operator>=(const Thing &r) const {
return !(*this < r);
}
bool Thing::operator>(const Thing &r) const {
return r < *this;
}
bool Thing::operator<=(const Thing &r) const {
return !(*this > r);
}</pre>
<p>I feel this is a natural choice because:
<ul>
<li>C++11 already has member function specifiers such as "default" and "delete"
<li>Users must "opt in" to get the new behavior
<li>Member functions must be declared and are, hence, seen in the source code
</ul>
<h3>Other points of consideration</h3>
<p>It is possible to mandate that <code>operator!=()</code> is to be implemented in a member-wise
fashion and it would we consistent with copy construction, assignment and equality. However:
<ul>
<li>Such an implementation is not useful
<li>The most logical choice for inequality is the boolean inverse of equality
<li>Users are free to implement their own behavior any way the see fit
</ul>
<h1>IV. Implementation</h1>
<p>I have a working prototype implementation using Clang that does the following:
<ul>
<li>parses the proposed syntax
<li>declares and defines the new member functions for an arbitrary number of built-in and
composite members
<li>Equality is generated in a member-wise fashion. Both built-in and user-defined types
are supported.
<li><code>opertator<()</code> is implemented via a call to <code>std::tie()</code>
<li>performs minimal semantic checks
</ul>
<p> The following additional work is needed:
<ul>
<li>support for base classes
<li>enhanced diagnostics pertinent to non-regular members
<li>careful review by language and compiler experts
</ul>
<h1>V. Technical specifications</h1>
<h3>Correction for "12 Special member function [special]" </h3>
<p>The default constructor (12.1), copy constructor and copy assignment operator (12.8),
move constructor and move assignment operator (12.8)
<span class="addition">, equality operators (12.10), comparison operator (12.11)</span>
and destructor (12.4) are special member functions.
<h3>Additional section</h3>
<p><b>12.10 Comparing equality [class.equality]</b>
<p>Composite types can provide overloaded equality and inequality operators. The implementation
can be instructed to generate a default implementation via the <i>= default</i> notation
as these member functions are considered special as per [special].
<p>Example:
<pre>
struct Thing {
int a, b, c, d;
bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b
bool operator!=(const Thing &) const = default; // 2
bool operator>=(const Thing &) const = default; // 3a
bool operator>(const Thing &) const = default; // 3b
bool operator<=(const Thing &) const = default; // 3c
};</pre>
<ul>
<li>The implementation will generate a member-wise comparison for (1a) that will cover trivial
types as well as composite types that provide an overloaded equality operator.
<li>The implementation will generate a lexicographical comparison of member values
compatible to <code>std::tie()</code> for (1b)
<li>The implementation will generate a logical inverse of equality for (2)
<li>The implementation will generate a logical inverse of <code>operator<()</code> for (3a)
<li>The implementation will generate a "reverse" comparison for (3b)
<li>The implementation will generate a logical inverse of <code>operator>()</code> for (3c)
</ul>
<h1>VI. Acknowledgments</h1>
<p>The fundamental idea comes from Alex Stepanov as his work revolves around
"regular" types. Such types should be automatically copied, assigned and compared.
The first two points have been in the C++ language from the beginning and this
proposal attempts to address the last one.
</body></html>
------=_Part_4267_27657409.1388111739061--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Thu, 26 Dec 2013 18:29:37 -0800
Raw View
This is a multi-part message in MIME format.
--------------060008060709060309050605
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=(), </font><font face="Calibri"><font
face="Calibri">operator>=(), </font></font><font
face="Calibri"><font face="Calibri"><font face="Calibri"><font
face="Calibri"><font face="Calibri"><font face="Calibri"><font
face="Calibri">operator>() and </font></font></font></font></font></font></font><font
face="Calibri"><font face="Calibri"><font face="Calibri"><font
face="Calibri"><font face="Calibri"><font face="Calibri"><font
face="Calibri"><font face="Calibri"><font
face="Calibri">operator<=()</font></font></font></font></font></font></font>
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary
points are about generating </font></font><br>
<pre> bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b</pre>
<font face="Calibri">Oleg.<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------060008060709060309050605
Content-Type: text/html; charset=ISO-8859-1;
name="equality.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="equality.html"
PGh0bWw+PGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtTGFuZ3VhZ2UiIGNvbnRl
bnQ9ImVuLXVzIj4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0
ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+Cjx0aXRsZT5EZWZhdWx0ZWQgY29tcGFy
aXNvbiBvcGVyYXRvcnM8L3RpdGxlPgo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgouYWRkaXRp
b24gewogICAgYmFja2dyb3VuZC1jb2xvcjogIzY2RkY5OTsKfQoucmVtb3ZhbCB7CiAgICB0
ZXh0LWRlY29yYXRpb246IGxpbmUtdGhyb3VnaDsKfQo8L3N0eWxlPgo8L2hlYWQ+Cgo8Ym9k
eT4KCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw
IiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSIgYm9yZGVyY29sb3I9IiMxMTEx
MTEiIHdpZHRoPSI2MTkiPgogICAgPHRyPgogICAgICA8dGQgd2lkdGg9IjE2NyIgYWxpZ249
ImxlZnQiIHZhbGlnbj0idG9wIj5Eb2N1bWVudCBudW1iZXI6PC90ZD4KICAgICAgPHRkIHdp
ZHRoPSI0NTIiPjxpPk5ubm5uPXl5LW5ubm48L2k+PC90ZD4KICAgIDwvdHI+CiAgICA8dHI+
CiAgICAgIDx0ZCB3aWR0aD0iMTY3IiBhbGlnbj0ibGVmdCIgdmFsaWduPSJ0b3AiPkRhdGU6
PC90ZD4KICAgICAgPHRkIHdpZHRoPSI0NTIiPjxpPjIwMTMtMTItMjE8L2k+PC90ZD4KICAg
IDwvdHI+CiAgICA8dHI+CiAgICAgIDx0ZCB3aWR0aD0iMTY3IiBhbGlnbj0ibGVmdCIgdmFs
aWduPSJ0b3AiPlByb2plY3Q6PC90ZD4KICAgICAgPHRkIHdpZHRoPSI0NTIiPlByb2dyYW1t
aW5nIExhbmd1YWdlIEMrKywgTGFuZ3VhZ2UgRXZvbHV0aW9uIFdvcmtpbmcgR3JvdXA8L3Rk
PgogICAgPC90cj4KICAgIDx0cj4KICAgICAgPHRkIHdpZHRoPSIxNjciIGFsaWduPSJsZWZ0
IiB2YWxpZ249InRvcCI+UmVwbHktdG86PC90ZD4KICAgICAgPHRkIHdpZHRoPSI0NTIiPk9s
ZWcgU21vbHNreSA8YSBocmVmPSJtYWlsdG86b2xlZy5zbW9sc2t5QGdtYWlsLmNvbSI+b2xl
Zy5zbW9sc2t5QGdtYWlsLmNvbTwvYT48L3RkPgogICAgPC90cj4KICA8L3RhYmxlPgoKICAg
IDxoMT5JLiBJbnRyb2R1Y3Rpb248L2gxPgogICAgPHA+UHJvdmlkZSBtZWFucyBvZiBnZW5l
cmF0aW5nIGRlZmF1bHQgZXF1YWxpdHksIGluZXF1YWxpdHkgYW5kIGNvbXBhcmlzb24gbWVt
YmVyIG9wZXJhdG9ycwogICAgICAgIGZvciB1c2VyLWRlZmluZWQgdHlwZXMuIFRoaXMgaXMg
c3RyaWN0bHkKICAgICAgIGFuICJvcHQgaW4iIGZlYXR1cmUgc28gdGhhdCBzZW1hbnRpY3Mg
b2YgZXhpc3RpbmcgY29kZSByZW1haW4gaW50YWN0LgogICAgPGgxPklJLiBNb3RpdmF0aW9u
IGFuZCBzY29wZTwvaDE+CiAgICA8cD5UaGlzIGZlYXR1cmUgd291bGQgYmUgdXNlZnVsIGZv
ciBtb2Rlcm4gQysrIGNvZGUgdGhhdCBvcGVyYXRlcyB3aXRoIHR5cGVzCiAgICAgICBjb21w
b3NlZCBvZiAicmVndWxhciIgbWVtYmVycy4gVGhlIGRlZmluaXRpb24gb2YgZXF1YWxpdHkg
aXMgdHJpdmlhbCBpbiBzdWNoIGNhc2VzIC0KICAgICAgIG1lbWJlci13aXNlIGNvbXBhcmlz
b24uIEluZXF1YWxpdHkgY2FuIHRoZW4gYmUgZ2VuZXJhdGVkIGFzIGFuIGludmVyc2UuCiAg
ICA8cD5UaGlzIHByb3Bvc2FsIGlzIGJhc2VkIG9uIHRoZSBub3Rpb24gb2YgInJlZ3VsYXIi
IHR5cGVzIHRoYXQgbmF0dXJhbGx5IGNvbXBvc2UuIFN1Y2gKICAgICAgIGNhc2VzIGFyZSBi
ZWNvbWluZyBtb3JlIHByZXZhbGVudCBhcyBwZW9wbGUgcHJvZ3JhbSBtb3JlIHdpdGggdmFs
dWUgdHlwZXMgYW5kIHdyaXRpbmcKICAgICAgIChpbillcXVhbGl0eSBtYW51YWxseSBiZWNv
bWVzIHRpcmVzb21lLiBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aGVuIHRyeWluZyB0bwog
ICAgICAgbGV4aWNvZ3JhcGhpY2FsbHkgY29tcGFyZSBtZW1iZXJzLgoKICAgIDxoMT5JSUku
IERlc2lnbiBkZWNpc2lvbnM8L2gxPgogICAgPGgzPlRoZSBwcm9wb3NlZCBzeW50YXg8L2gz
PgogICAgICAgIE1lbWJlci13aXNlIGdlbmVyYXRpb24gb2Ygc3BlY2lhbCBmdW5jdGlvbnMg
aXMgYWxyZWFkeSBwcmVzZW50IGluIHRoZSBTdGFuZGFyZCAoc2VlIHNlY2lvbiAxMiksCiAg
ICAgICAgc28gaXQgc2VlbXMgbmF0dXJhdGlvbiB0byBleHRlbmQgdGhlIHN5bnRheCB0byBj
b3ZlciBjb21wYXJpc29uIG1lbWJlciBmdW5jdGlvbnMuCgogICAgVGhlIHByb3Bvc2VkIHN5
bnRheCBmb3IgZ2VuZXJhdGluZyB0aGUgbmV3ICJkZWZhdWx0ZWQiIG1lbWJlciBmdW5jdGlv
bnMgaXMgYXMgZm9sbG93czoKICAgIDxwcmU+CiAgICAgICAgc3RydWN0IFRoaW5nIHsKICAg
ICAgICAgICAgaW50IGEsIGIsIGMsIGQ7CgogICAgICAgICAgICBib29sIG9wZXJhdG9yPT0o
Y29uc3QgVGhpbmcgJmFtcDspIGNvbnN0ID0gZGVmYXVsdDsgICAgICAvLyAxYQogICAgICAg
ICAgICBib29sIG9wZXJhdG9yJmx0Oyhjb25zdCBUaGluZyAmYW1wOykgY29uc3QgPSBkZWZh
dWx0OyAgICAgICAvLyAxYgoKICAgICAgICAgICAgYm9vbCBvcGVyYXRvciE9KGNvbnN0IFRo
aW5nICZhbXA7KSBjb25zdCA9IGRlZmF1bHQ7ICAgICAgLy8gMgoKICAgICAgICAgICAgYm9v
bCBvcGVyYXRvciZndDs9KGNvbnN0IFRoaW5nICZhbXA7KSBjb25zdCA9IGRlZmF1bHQ7ICAg
ICAgLy8gM2EKICAgICAgICAgICAgYm9vbCBvcGVyYXRvciZndDsoY29uc3QgVGhpbmcgJmFt
cDspIGNvbnN0ID0gZGVmYXVsdDsgICAgICAgLy8gM2IKICAgICAgICAgICAgYm9vbCBvcGVy
YXRvciZsdDs9KGNvbnN0IFRoaW5nICZhbXA7KSBjb25zdCA9IGRlZmF1bHQ7ICAgICAgLy8g
M2MKICAgICAgICB9OzwvcHJlPgogICAgPHA+QWZvcm1lbnRpb25lZCBzaG91bGQgZ2VuZXJh
dGUgZGVmaW5pdGlvbnMgY29tcGF0aWJsZSB0byB0aGUgZm9sbG93aW5nIGV4YW1wbGU6CiAg
ICA8cHJlPgogICAgICAgIGJvb2wgVGhpbmc6Om9wZXJhdG9yPT0oY29uc3QgVGhpbmcgJmFt
cDtyKSBjb25zdCB7CiAgICAgICAgICAgIHJldHVybiBhID09IHIuYSAmYW1wOyZhbXA7IGIg
PT0gci5iICZhbXA7JmFtcDsgYyA9PSByLmMgJmFtcDsmYW1wOyBkID09IHIuZDsKICAgICAg
ICB9CiAgICAgICAgYm9vbCBUaGluZzo6b3BlcmF0b3ImbHQ7KGNvbnN0IFRoaW5nICZhbXA7
cikgY29uc3QgewogICAgICAgICAgICByZXR1cm4gc3RkOjp0aWUoYSwgYiwgYywgZCkgJmx0
OyBzdGQ6OnRpZShyLmEsIHIuYiwgci5jLCByLmQpOwogICAgICAgIH0KCiAgICAgICAgYm9v
bCBUaGluZzo6b3BlcmF0b3IhPShjb25zdCBUaGluZyAmYW1wO3IpIGNvbnN0IHsKICAgICAg
ICAgICAgcmV0dXJuICEoKnRoaXMgPT0gcik7CiAgICAgICAgfQoKICAgICAgICBib29sIFRo
aW5nOjpvcGVyYXRvciZndDs9KGNvbnN0IFRoaW5nICZhbXA7cikgY29uc3QgewogICAgICAg
ICAgICByZXR1cm4gISgqdGhpcyAmbHQ7IHIpOwogICAgICAgIH0KICAgICAgICBib29sIFRo
aW5nOjpvcGVyYXRvciZndDsoY29uc3QgVGhpbmcgJmFtcDtyKSBjb25zdCB7CiAgICAgICAg
ICAgIHJldHVybiByICZsdDsgKnRoaXM7CiAgICAgICAgfQogICAgICAgIGJvb2wgVGhpbmc6
Om9wZXJhdG9yJmx0Oz0oY29uc3QgVGhpbmcgJmFtcDtyKSBjb25zdCB7CiAgICAgICAgICAg
IHJldHVybiAhKCp0aGlzICZndDsgcik7CiAgICAgICAgfTwvcHJlPgogICAgPHA+SSBmZWVs
IHRoaXMgaXMgYSBuYXR1cmFsIGNob2ljZSBiZWNhdXNlOgogICAgICAgPHVsPgogICAgICAg
ICAgICA8bGk+QysrMTEgYWxyZWFkeSBoYXMgbWVtYmVyIGZ1bmN0aW9uIHNwZWNpZmllcnMg
c3VjaCBhcyAiZGVmYXVsdCIgYW5kICJkZWxldGUiCiAgICAgICAgICAgIDxsaT5Vc2VycyBt
dXN0ICJvcHQgaW4iIHRvIGdldCB0aGUgbmV3IGJlaGF2aW9yCiAgICAgICAgICAgIDxsaT5N
ZW1iZXIgZnVuY3Rpb25zIG11c3QgYmUgZGVjbGFyZWQgYW5kIGFyZSwgaGVuY2UsIHNlZW4g
aW4gdGhlIHNvdXJjZSBjb2RlCiAgICAgICA8L3VsPgoKICAgIDxoMz5PdGhlciBwb2ludHMg
b2YgY29uc2lkZXJhdGlvbjwvaDM+CiAgICA8cD5JdCBpcyBwb3NzaWJsZSB0byBtYW5kYXRl
IHRoYXQgPGNvZGU+b3BlcmF0b3IhPSgpPC9jb2RlPiBpcyB0byBiZSBpbXBsZW1lbnRlZCBp
biBhIG1lbWJlci13aXNlCiAgICAgICAgZmFzaGlvbiBhbmQgaXQgd291bGQgd2UgY29uc2lz
dGVudCB3aXRoIGNvcHkgY29uc3RydWN0aW9uLCBhc3NpZ25tZW50IGFuZCBlcXVhbGl0eS4g
SG93ZXZlcjoKICAgICAgICA8dWw+CiAgICAgICAgICAgIDxsaT5TdWNoIGFuIGltcGxlbWVu
dGF0aW9uIGlzIG5vdCB1c2VmdWwKICAgICAgICAgICAgPGxpPlRoZSBtb3N0IGxvZ2ljYWwg
Y2hvaWNlIGZvciBpbmVxdWFsaXR5IGlzIHRoZSBib29sZWFuIGludmVyc2Ugb2YgZXF1YWxp
dHkKICAgICAgICAgICAgPGxpPlVzZXJzIGFyZSBmcmVlIHRvIGltcGxlbWVudCB0aGVpciBv
d24gYmVoYXZpb3IgYW55IHdheSB0aGUgc2VlIGZpdAogICAgICAgIDwvdWw+CgogICAgPGgx
PklWLiBJbXBsZW1lbnRhdGlvbjwvaDE+CiAgICAgICAgPHA+SSBoYXZlIGEgd29ya2luZyBw
cm90b3R5cGUgaW1wbGVtZW50YXRpb24gdXNpbmcgQ2xhbmcgdGhhdCBkb2VzIHRoZSBmb2xs
b3dpbmc6CiAgICAgICAgPHVsPgogICAgICAgICAgICA8bGk+cGFyc2VzIHRoZSBwcm9wb3Nl
ZCBzeW50YXgKICAgICAgICAgICAgPGxpPmRlY2xhcmVzIGFuZCBkZWZpbmVzIHRoZSBuZXcg
bWVtYmVyIGZ1bmN0aW9ucyBmb3IgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiBidWlsdC1pbiBh
bmQgICAKICAgICAgICAgICAgICAgIGNvbXBvc2l0ZSBtZW1iZXJzCiAgICAgICAgICAgIDxs
aT5FcXVhbGl0eSBpcyBnZW5lcmF0ZWQgaW4gYSBtZW1iZXItd2lzZSBmYXNoaW9uLiBCb3Ro
IGJ1aWx0LWluIGFuZCB1c2VyLWRlZmluZWQgdHlwZXMgCiAgICAgICAgICAgICAgICBhcmUg
c3VwcG9ydGVkLgogICAgICAgICAgICA8bGk+PGNvZGU+b3BlcnRhdG9yJmx0OygpPC9jb2Rl
PiBpcyBpbXBsZW1lbnRlZCB2aWEgYSBjYWxsIHRvIDxjb2RlPnN0ZDo6dGllKCk8L2NvZGU+
CiAgICAgICAgICAgIDxsaT5wZXJmb3JtcyBtaW5pbWFsIHNlbWFudGljIGNoZWNrcwogICAg
ICAgIDwvdWw+CgogICAgICAgIDxwPiBUaGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgd29yayBp
cyBuZWVkZWQ6CiAgICAgICAgPHVsPgogICAgICAgICAgICA8bGk+c3VwcG9ydCBmb3IgYmFz
ZSBjbGFzc2VzCiAgICAgICAgICAgIDxsaT5lbmhhbmNlZCBkaWFnbm9zdGljcyBwZXJ0aW5l
bnQgdG8gbm9uLXJlZ3VsYXIgbWVtYmVycwogICAgICAgICAgICA8bGk+Y2FyZWZ1bCByZXZp
ZXcgYnkgbGFuZ3VhZ2UgYW5kIGNvbXBpbGVyIGV4cGVydHMKICAgICAgICA8L3VsPgoKICAg
IDxoMT5WLiBUZWNobmljYWwgc3BlY2lmaWNhdGlvbnM8L2gxPgogICAgPGgzPkNvcnJlY3Rp
b24gZm9yICIxMiBTcGVjaWFsIG1lbWJlciBmdW5jdGlvbiBbc3BlY2lhbF0iIDwvaDM+CiAg
ICA8cD5UaGUgZGVmYXVsdCBjb25zdHJ1Y3RvciAoMTIuMSksIGNvcHkgY29uc3RydWN0b3Ig
YW5kIGNvcHkgYXNzaWdubWVudCBvcGVyYXRvciAoMTIuOCksIAogICAgICAgIG1vdmUgY29u
c3RydWN0b3IgYW5kIG1vdmUgYXNzaWdubWVudCBvcGVyYXRvciAoMTIuOCkKICAgICAgICA8
c3BhbiBjbGFzcz0iYWRkaXRpb24iPiwgZXF1YWxpdHkgb3BlcmF0b3JzICgxMi4xMCksIGNv
bXBhcmlzb24gb3BlcmF0b3IgKDEyLjExKTwvc3Bhbj4KICAgICAgICBhbmQgZGVzdHJ1Y3Rv
ciAoMTIuNCkgYXJlIHNwZWNpYWwgbWVtYmVyIGZ1bmN0aW9ucy4KICAgIDxoMz5BZGRpdGlv
bmFsIHNlY3Rpb248L2gzPgogICAgPHA+PGI+MTIuMTAgQ29tcGFyaW5nIGVxdWFsaXR5IFtj
bGFzcy5lcXVhbGl0eV08L2I+CiAgICA8cD5Db21wb3NpdGUgdHlwZXMgY2FuIHByb3ZpZGUg
b3ZlcmxvYWRlZCBlcXVhbGl0eSBhbmQgaW5lcXVhbGl0eSBvcGVyYXRvcnMuIFRoZSBpbXBs
ZW1lbnRhdGlvbgogICAgICAgY2FuIGJlIGluc3RydWN0ZWQgdG8gZ2VuZXJhdGUgYSBkZWZh
dWx0IGltcGxlbWVudGF0aW9uIHZpYSB0aGUgPGk+PSBkZWZhdWx0PC9pPiBub3RhdGlvbgog
ICAgICAgYXMgdGhlc2UgbWVtYmVyIGZ1bmN0aW9ucyBhcmUgY29uc2lkZXJlZCBzcGVjaWFs
IGFzIHBlciBbc3BlY2lhbF0uCgogICAgPHA+RXhhbXBsZToKICAgIDxwcmU+CiAgICAgICAg
c3RydWN0IFRoaW5nIHsKICAgICAgICAgICAgaW50IGEsIGIsIGMsIGQ7CgogICAgICAgICAg
ICBib29sIG9wZXJhdG9yPT0oY29uc3QgVGhpbmcgJmFtcDspIGNvbnN0ID0gZGVmYXVsdDsg
ICAgICAvLyAxYQogICAgICAgICAgICBib29sIG9wZXJhdG9yJmx0Oyhjb25zdCBUaGluZyAm
YW1wOykgY29uc3QgPSBkZWZhdWx0OyAgICAgICAvLyAxYgoKICAgICAgICAgICAgYm9vbCBv
cGVyYXRvciE9KGNvbnN0IFRoaW5nICZhbXA7KSBjb25zdCA9IGRlZmF1bHQ7ICAgICAgLy8g
MgoKICAgICAgICAgICAgYm9vbCBvcGVyYXRvciZndDs9KGNvbnN0IFRoaW5nICZhbXA7KSBj
b25zdCA9IGRlZmF1bHQ7ICAgICAgLy8gM2EKICAgICAgICAgICAgYm9vbCBvcGVyYXRvciZn
dDsoY29uc3QgVGhpbmcgJmFtcDspIGNvbnN0ID0gZGVmYXVsdDsgICAgICAgLy8gM2IKICAg
ICAgICAgICAgYm9vbCBvcGVyYXRvciZsdDs9KGNvbnN0IFRoaW5nICZhbXA7KSBjb25zdCA9
IGRlZmF1bHQ7ICAgICAgLy8gM2MKICAgICAgICB9OzwvcHJlPgogICAKICAgIDx1bD4KICAg
ICAgICA8bGk+VGhlIGltcGxlbWVudGF0aW9uIHdpbGwgZ2VuZXJhdGUgYSBtZW1iZXItd2lz
ZSBjb21wYXJpc29uIGZvciAoMWEpIHRoYXQgd2lsbCBjb3ZlciB0cml2aWFsCiAgICAgICAg
ICAgdHlwZXMgYXMgd2VsbCBhcyBjb21wb3NpdGUgdHlwZXMgdGhhdCBwcm92aWRlIGFuIG92
ZXJsb2FkZWQgZXF1YWxpdHkgb3BlcmF0b3IuCiAgICAgICAgPGxpPlRoZSBpbXBsZW1lbnRh
dGlvbiB3aWxsIGdlbmVyYXRlIGEgbGV4aWNvZ3JhcGhpY2FsIGNvbXBhcmlzb24gb2YgbWVt
YmVyIHZhbHVlcwogICAgICAgICAgICBjb21wYXRpYmxlIHRvIDxjb2RlPnN0ZDo6dGllKCk8
L2NvZGU+IGZvciAoMWIpCiAgICAgICAgPGxpPlRoZSBpbXBsZW1lbnRhdGlvbiB3aWxsIGdl
bmVyYXRlIGEgbG9naWNhbCBpbnZlcnNlIG9mIGVxdWFsaXR5IGZvciAoMikKICAgICAgICA8
bGk+VGhlIGltcGxlbWVudGF0aW9uIHdpbGwgZ2VuZXJhdGUgYSBsb2dpY2FsIGludmVyc2Ug
b2YgPGNvZGU+b3BlcmF0b3ImbHQ7KCk8L2NvZGU+IGZvciAoM2EpCiAgICAgICAgPGxpPlRo
ZSBpbXBsZW1lbnRhdGlvbiB3aWxsIGdlbmVyYXRlIGEgInJldmVyc2UiIGNvbXBhcmlzb24g
Zm9yICgzYikKICAgICAgICA8bGk+VGhlIGltcGxlbWVudGF0aW9uIHdpbGwgZ2VuZXJhdGUg
YSBsb2dpY2FsIGludmVyc2Ugb2YgPGNvZGU+b3BlcmF0b3ImZ3Q7KCk8L2NvZGU+IGZvciAo
M2MpCiAgICA8L3VsPgoKICAgIDxoMT5WSS4gQWNrbm93bGVkZ21lbnRzPC9oMT4KICAgICAg
ICA8cD5UaGUgZnVuZGFtZW50YWwgaWRlYSBjb21lcyBmcm9tIEFsZXggU3RlcGFub3YgYXMg
aGlzIHdvcmsgcmV2b2x2ZXMgYXJvdW5kIAogICAgICAgICJyZWd1bGFyIiB0eXBlcy4gU3Vj
aCB0eXBlcyBzaG91bGQgYmUgYXV0b21hdGljYWxseSBjb3BpZWQsIGFzc2lnbmVkIGFuZCBj
b21wYXJlZC4gCiAgICAgICAgVGhlIGZpcnN0IHR3byBwb2ludHMgaGF2ZSBiZWVuIGluIHRo
ZSBDKysgbGFuZ3VhZ2UgZnJvbSB0aGUgYmVnaW5uaW5nIGFuZCB0aGlzIAogICAgICAgIHBy
b3Bvc2FsIGF0dGVtcHRzIHRvIGFkZHJlc3MgdGhlIGxhc3Qgb25lLgoKPC9ib2R5PjwvaHRt
bD4K
--------------060008060709060309050605--
.
Author: oleg.smolsky@gmail.com
Date: Sun, 29 Dec 2013 18:04:39 -0800 (PST)
Raw View
------=_Part_6197_19081750.1388369079702
Content-Type: multipart/alternative;
boundary="----=_Part_6198_27270239.1388369079703"
------=_Part_6198_27270239.1388369079703
Content-Type: text/plain; charset=ISO-8859-1
Here is a much refined paper, with a developed "specification" section.
Oleg.
On Thursday, December 26, 2013 6:29:37 PM UTC-8, Oleg Smolsky wrote:
>
> Hi all, I've written up the discussion into a paper, attempted to
> provide the minimal standardese and implemented a prototype in Clang. The
> draft is attached and I had asked Alisdair Meredith for a proposal number.
>
> I realize that operator!=(), operator>=(), operator>() and operator<=()are contentious as people may choose to derive them in weird ways... So,
> I'll treat them as secondary goals. The primary points are about generating
>
> bool operator==(const Thing &) const = default; // 1a
> bool operator<(const Thing &) const = default; // 1b
>
> Oleg.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6198_27270239.1388369079703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here is a much refined paper, with a developed "specificat=
ion" section.<br><br>Oleg.<br><br>On Thursday, December 26, 2013 6:29:37 PM=
UTC-8, Oleg Smolsky wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font face=3D"Calibri">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), </font><font face=3D"Calibri"><font fa=
ce=3D"Calibri">operator>=3D(), </font></font><font face=3D"Calibri"><fon=
t face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font face=
=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri">operator>() a=
nd </font></font></font></font></font></font></font><font face=3D"Calibri">=
<font face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font =
face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font face=
=3D"Calibri"><font face=3D"Calibri">operator<=3D()</font></font></font><=
/font></font></font></font>
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary
points are about generating </font></font><br>
<pre> bool operator=3D=3D(const Thing &) const =3D defau=
lt; // 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b</pre>
<font face=3D"Calibri">Oleg.<br>
</font>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6198_27270239.1388369079703--
------=_Part_6197_19081750.1388369079702
Content-Type: text/html; charset=US-ASCII; name=equality.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=equality.html
X-Attachment-Id: c5dec00b-e19f-480a-a27d-2572d739457f
Content-ID: <c5dec00b-e19f-480a-a27d-2572d739457f>
<html><head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Defaulted comparison operators</title>
<style type="text/css">
..addition {
background-color: #66FF99;
}
..removal {
text-decoration: line-through;
}
li {
padding-bottom: 0.3em;
}
</style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="619">
<tr>
<td width="167" align="left" valign="top">Document number:</td>
<td width="452"><i>Nnnnn=yy-nnnn</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Date:</td>
<td width="452"><i>2013-12-29</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Project:</td>
<td width="452">Programming Language C++, Language Evolution Working Group</td>
</tr>
<tr>
<td width="167" align="left" valign="top">Reply-to:</td>
<td width="452">Oleg Smolsky <a href="mailto:oleg.smolsky@gmail.com">oleg.smolsky@gmail.com</a></td>
</tr>
</table>
<h1>I. Introduction</h1>
<p>Provide means of generating default equality, inequality and comparison member operators
for user-defined types. This is strictly
an "opt in" feature so that semantics of existing code remain intact.
<h1>II. Motivation and scope</h1>
<p>This feature would be useful for modern C++ code that operates with types
composed of "regular" members. The definition of equality is trivial in such cases -
member-wise comparison. Inequality can then be generated as an inverse.
<p>This proposal is based on the notion of "regular" types that naturally compose. Such
cases are becoming more prevalent as people program more with value types and writing
(in)equality manually becomes tiresome. This is especially true when trying to
lexicographically compare members.
<h1>III. Design decisions</h1>
<h3>The proposed syntax</h3>
Member-wise generation of special functions is already present in the Standard (see secion 12),
so it seems naturation to extend the syntax to cover comparison member functions.
The proposed syntax for generating the new "defaulted" member functions is as follows:
<pre>
struct Thing {
int a, b, c, d;
bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b
bool operator!=(const Thing &) const = default; // 2
bool operator>=(const Thing &) const = default; // 3a
bool operator>(const Thing &) const = default; // 3b
bool operator<=(const Thing &) const = default; // 3c
};</pre>
<p>Aformentioned should generate definitions compatible to the following example:
<pre>
bool Thing::operator==(const Thing &r) const {
return a == r.a && b == r.b && c == r.c && d == r.d;
}
bool Thing::operator<(const Thing &r) const {
return std::tie(a, b, c, d) < std::tie(r.a, r.b, r.c, r.d);
}
bool Thing::operator!=(const Thing &r) const {
return !(*this == r);
}
bool Thing::operator>=(const Thing &r) const {
return !(*this < r);
}
bool Thing::operator>(const Thing &r) const {
return r < *this;
}
bool Thing::operator<=(const Thing &r) const {
return !(*this > r);
}</pre>
<p>I feel this is a natural choice because:
<ul>
<li>C++11 already has member function specifiers such as "default" and "delete"
<li>Users must "opt in" to get the new behavior
<li>Member functions must be declared and are, hence, seen in the source code
</ul>
<h3>Other points of consideration</h3>
<p>It is possible to mandate that <code>operator!=()</code> is to be implemented in a member-wise
fashion and it would we consistent with copy construction, assignment and equality. However:
<ul>
<li>Such an implementation is not useful
<li>The most logical choice for inequality is the boolean inverse of equality
<li>Users are free to implement their own behavior any way the see fit
</ul>
<h1>IV. Implementation</h1>
<p>I have a working prototype implementation using Clang that does the following:
<ul>
<li>parses the proposed syntax
<li>declares and defines the new member functions for an arbitrary number of built-in and
composite members
<li>Equality is generated in a member-wise fashion. Both built-in and user-defined types
are supported.
<li><code>opertator<()</code> is implemented via a call to <code>std::tie()</code>
<li>performs minimal semantic checks
</ul>
<p> The following additional work is needed:
<ul>
<li>support for base classes
<li>enhanced diagnostics pertinent to non-regular members
<li>careful review by language and compiler experts
</ul>
<h1>V. Technical specifications</h1>
<h3>Correction for "12 Special member function [special]" </h3>
<p>The default constructor (12.1), copy constructor and copy assignment operator (12.8),
move constructor and move assignment operator (12.8)
<span class="addition">, equality operators (12.10), comparison operators (12.11)</span>
and destructor (12.4) are special member functions.
<h3>Additional section</h3>
<p><b>12.10 Equality operators [class.equality]</b>
<ol>
<li>A non-union class can provide overloaded equality and inequality operators as per
[over.oper]. The implementation can generate a default implementation via the
<code>= default</code> notation as these member functions are considered special as
per [special].
<li>The defaulted <code>operator==()</code> is generated if and only if all
sub-objects and base classes satisfy the requirements of the <i>EqualityComparable</i>
concept (17.6.3.1).
<li>The implicitly-defined equality operator for a non-union class X performs
memberwise equality checks of its subobjects. Direct base classes of X
are compared first, in the order of their declaration in the base-specifier-list,
and then the immediate non-static data members of X are compared, in
the order in which they were declared in the class definition.<br>
Let x be either the parameter of the function or, for the move operator, an xvalue
referring to the parameter. Each subobject is compared in the manner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <code>operator==()</code> with
the subobject as the object expression and the corresponding subobject of x as a
single function argument (as if by explicit qualification; that is, ignoring any
possible virtual overriding functions in more derived classes);
<li>if the subobject is an array, each element is compared, in the manner appropriate
to the element type;
<li>if the subobject is of trivial type, the built-in "equality" operator is used.
</ul>
<li>The implicitly-defined inequality operator for a non-union class X performs a call
to <code>operator==()</code> and returns a boolean negation of the result
</ol>
<p><b>12.11 Comparison operators [class.comparison]</b>
<ol>
<li>A non-union class can provide overloaded comparison operators as per [over.oper].
The implementation can generate a default implementation via the
<code>= default</code> notation as these member functions are considered special as
per [special].
<li>The defaulted <code>operator<()</code> is generated if and only if all
sub-objects and base classes satisfy the requirements of the <i>LessThanComparable</i>
concept (17.6.3.1).
<li>The implicitly-defined <code>operator<()</code> for a non-union class X performs
lexicographical comparison of member values in a manner compatible to
<code>std::tie()</code>.
Direct base classes of X are compared first, in the order of their declaration in the
base-specifier-list, and then the immediate non-static data members of X are compared,
in the order in which they were declared in the class definition.<br>
Let x be either the parameter of the function or, for the move operator, an xvalue
referring to the parameter. Each subobject is compared in the manner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <code>operator<()</code> with
the subobject as the object expression and the corresponding subobject of x as a
single function argument (as if by explicit qualification; that is, ignoring any
possible virtual overriding functions in more derived classes);
<li>if the subobject is an array, each element is compared, in the manner appropriate
to the element type;
<li>if the subobject is of trivial type, the built-in "less than" operator is used.
</ul>
<li>The implicitly-defined <code>operator>=()</code> for a non-union class X performs a call
to <code>operator<()</code> and returns a boolean negation of the result
<li>The implicitly-defined <code>operator>()</code> for a non-union class X performs a call
to <code>operator<()</code> but reverses the arguments
<li>The implicitly-defined <code>operator<=()</code> for a non-union class X performs a call
to <code>operator>()</code> and returns a boolean negation of the result
</ol>
<h1>VI. Pending work</h1>
<p>The following points need to be worked into the specification:
<ul>
<li>Handle deleted <code>operator==()</code> - the program must be ill-formed
<li>Check whether it is meaningful to handle trivial types with <code>memcmp()</code>.
Eg arrays of built-ins.
<li>What about POD structures? These explicitly generated member functions would
be useful as they do not violate the layout.
</ul>
<h1>VII. Related ideas and discussion</h1>
The following related ideas need consideration for the future:
<ol>
<li>It is possible to generate definitions in terms of the operators being used,
instead of the "key" operator? Would it make sense? Such specification introduces
even more variance into the generated code.
<li>Is it possible to generate these <code>operator==()</code> implicitly? How do we
deal with previously defined non-member operators? (Perhaps we can allow non-member
operators to hide implicitly generated member ones?).
</ol>
<h1>VIII. Acknowledgments</h1>
<p>The fundamental idea comes from Alex Stepanov as his work revolves around
"regular" types. Such types should be automatically copied, assigned and compared.
The first two points have been in the C++ language from the beginning and this
proposal attempts to address the last one.
<p>I want to thank Andrew Sutton for early feedback and guidance.
</body></html>
------=_Part_6197_19081750.1388369079702--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 30 Dec 2013 11:40:44 -0500
Raw View
--001a11c3b4ace7424e04eec31a0d
Content-Type: text/plain; charset=ISO-8859-1
I would try to think if there is a 'natural' way to transform that proposal
so that the operators are not necessarily defined as member functions.
While member functions map more naturally to the current uses of ' =
default', free function operators are more natural to use, allowing the
same conversions on both arguments. With the current wording, this code
would fail to compile:
struct T {
int value;
T(int v) : value(v) {} // implicit!
bool operator==(T const &) = default;
};
int main() {
return 1 == T(1);
}
While if we swap the order of the equality check it would compile. I find
that asymmetry slightly disturbing. Maybe we could consider extending ' =
default' to anything that is defined inside the class definition and allow:
struct T {
// ...
friend bool operator==(T const&, T const&) = default;
};
Additionally, I would like to have the wording explicitly mention that the
operators can only be defaulted when they apply to exactly the same type
that is being defined.
I have the feeling that I really want something more like:
struct T {
operator== = default;
};
Or some other mechanism by which the type is not present in the signature
and thus removes the potential for attempts to default cross-type
comparisons... But this would require mayor changes in the grammar and is
better avoided.
David
On Thu, Dec 26, 2013 at 9:35 PM, <oleg.smolsky@gmail.com> wrote:
> Hi all, I've written up the discussion into a paper, attempted to provide
> the minimal standardese and implemented a prototype in Clang. The draft is
> attached and I had asked Alisdair Meredith for a proposal number.
>
> I realize that operator!=(), operator>=(), operator>() and operator<=()
> are contentious as people may choose to derive them in weird ways... So,
> I'll treat them as secondary goals. The primary goal is to generate the
> following member functions:
>
> bool operator==(const Thing &) const = default; // 1a
> bool operator<(const Thing &) const = default; // 1b
>
> Oleg.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3b4ace7424e04eec31a0d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would try to think if there is a 'natural' way t=
o transform that proposal so that the operators are not necessarily defined=
as member functions. While member functions map more naturally to the curr=
ent uses of ' =3D default', free function operators are more natura=
l to use, allowing the same conversions on both arguments. With the current=
wording, this code would fail to compile:<br>
<br>struct T {<br>=A0 =A0int value;<br>=A0 =A0T(int v) : value(v) {} =A0 =
=A0 =A0 =A0 =A0 =A0 // implicit!<br>=A0 =A0bool operator=3D=3D(T const &=
;) =3D default;<br>};<br>int main() {<br>=A0 =A0return 1 =3D=3D T(1);<br>}<=
br><br>While if we swap the order of the equality check it would compile. I=
find that asymmetry slightly disturbing. Maybe we could consider extending=
' =3D default' to anything that is defined inside the class defini=
tion and allow:<br>
<br>struct T {<br>=A0 =A0// ...<br>=A0 =A0friend bool operator=3D=3D(T cons=
t&, T const&) =3D default;<br>};<br><br>Additionally, I would like =
to have the wording explicitly mention that the operators can only be defau=
lted when they apply to exactly the same type that is being defined. <br>
<br>I have the feeling that I really want something more like:<br><br>struc=
t T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or some other mech=
anism by which the type is not present in the signature and thus removes th=
e potential for attempts to default cross-type comparisons... But this woul=
d require mayor changes in the grammar and is better avoided.<div>
<br>David</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Dec 26, 2013 at 9:35 PM, <span dir=3D"ltr"><<a href=3D"=
mailto:oleg.smolsky@gmail.com" target=3D"_blank">oleg.smolsky@gmail.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font><span style=3D"font-f=
amily:arial,sans-serif">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), operator>=3D(), operator>() and =
operator<=3D()
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary goa=
l is to generate the following member functions:<br><br>
</span></font><pre><font><span style=3D"font-family:arial,sans-serif"> =
bool operator=3D=3D(const Thing &) const =3D default; /=
/ 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b<br><br></span></font></pre><font><span style=3D"font-family:arial,sans=
-serif">
Oleg.</span></font></div><span class=3D"HOEnZb"><font color=3D"#888888"=
>
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3b4ace7424e04eec31a0d--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 30 Dec 2013 11:53:13 -0500
Raw View
--001a11337c688ff70404eec347eb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Another thought,
Has there been any advances in SG7? Has there been any document
produced?
Once/if we get at least compile time reflection for member variables this
could be implemented at the library level. The standard library could
provide templates inside 'rel_ops' that did the work. The following open
question would be how to pull those operators so that lookup would find
them.
One solution would be adding a tag type to the namespace and let users opt
into those operators by means of inheritance from that tag (which would add
the 'rel_ops' to ADL), which brings up the question of why that has not
been done when ::std::rel_ops operators where added?
David
On Mon, Dec 30, 2013 at 11:40 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>=
wrote:
> I would try to think if there is a 'natural' way to transform that
> proposal so that the operators are not necessarily defined as member
> functions. While member functions map more naturally to the current uses =
of
> ' =3D default', free function operators are more natural to use, allowing=
the
> same conversions on both arguments. With the current wording, this code
> would fail to compile:
>
> struct T {
> int value;
> T(int v) : value(v) {} // implicit!
> bool operator=3D=3D(T const &) =3D default;
> };
> int main() {
> return 1 =3D=3D T(1);
> }
>
> While if we swap the order of the equality check it would compile. I find
> that asymmetry slightly disturbing. Maybe we could consider extending ' =
=3D
> default' to anything that is defined inside the class definition and allo=
w:
>
> struct T {
> // ...
> friend bool operator=3D=3D(T const&, T const&) =3D default;
> };
>
> Additionally, I would like to have the wording explicitly mention that th=
e
> operators can only be defaulted when they apply to exactly the same type
> that is being defined.
>
> I have the feeling that I really want something more like:
>
> struct T {
> operator=3D=3D =3D default;
> };
>
> Or some other mechanism by which the type is not present in the signature
> and thus removes the potential for attempts to default cross-type
> comparisons... But this would require mayor changes in the grammar and is
> better avoided.
>
> David
>
>
> On Thu, Dec 26, 2013 at 9:35 PM, <oleg.smolsky@gmail.com> wrote:
>
>> Hi all, I've written up the discussion into a paper, attempted to provid=
e
>> the minimal standardese and implemented a prototype in Clang. The draft =
is
>> attached and I had asked Alisdair Meredith for a proposal number.
>>
>> I realize that operator!=3D(), operator>=3D(), operator>() and operator<=
=3D()
>> are contentious as people may choose to derive them in weird ways... So,
>> I'll treat them as secondary goals. The primary goal is to generate the
>> following member functions:
>>
>> bool operator=3D=3D(const Thing &) const =3D default; /=
/ 1a
>> bool operator<(const Thing &) const =3D default; // 1b
>>
>> Oleg.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11337c688ff70404eec347eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another thought,<br><br>=A0 =A0 Has there been any advance=
s in SG7? Has there been any document produced? <br><br>Once/if we get at l=
east compile time reflection for member variables this could be implemented=
at the library level. The standard library could provide templates inside =
'rel_ops' that did the work. The following open question would be h=
ow to pull those operators so that lookup would find them. <br>
<br>One solution would be adding a tag type to the namespace and let users =
opt into those operators by means of inheritance from that tag (which would=
add the 'rel_ops' to ADL), which brings up the question of why tha=
t has not been done when ::std::rel_ops operators where added?<br>
<br>David<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Mon, Dec 30, 2013 at 11:40 AM, David Rodr=EDguez Ibeas =
<span dir=3D"ltr"><<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">=
dibeas@ieee.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I would try to think if the=
re is a 'natural' way to transform that proposal so that the operat=
ors are not necessarily defined as member functions. While member functions=
map more naturally to the current uses of ' =3D default', free fun=
ction operators are more natural to use, allowing the same conversions on b=
oth arguments. With the current wording, this code would fail to compile:<b=
r>
<br>struct T {<br>=A0 =A0int value;<br>=A0 =A0T(int v) : value(v) {} =A0 =
=A0 =A0 =A0 =A0 =A0 // implicit!<br>=A0 =A0bool operator=3D=3D(T const &=
;) =3D default;<br>};<br>int main() {<br>=A0 =A0return 1 =3D=3D T(1);<br>}<=
br><br>While if we swap the order of the equality check it would compile. I=
find that asymmetry slightly disturbing. Maybe we could consider extending=
' =3D default' to anything that is defined inside the class defini=
tion and allow:<br>
<br>struct T {<br>=A0 =A0// ...<br>=A0 =A0friend bool operator=3D=3D(T cons=
t&, T const&) =3D default;<br>};<br><br>Additionally, I would like =
to have the wording explicitly mention that the operators can only be defau=
lted when they apply to exactly the same type that is being defined. <br>
<br>I have the feeling that I really want something more like:<br><br>struc=
t T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or some other mech=
anism by which the type is not present in the signature and thus removes th=
e potential for attempts to default cross-type comparisons... But this woul=
d require mayor changes in the grammar and is better avoided.<span class=3D=
"HOEnZb"><font color=3D"#888888"><div>
<br>David</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5">=
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Dec 2=
6, 2013 at 9:35 PM, <span dir=3D"ltr"><<a href=3D"mailto:oleg.smolsky@g=
mail.com" target=3D"_blank">oleg.smolsky@gmail.com</a>></span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font><span style=3D"font-f=
amily:arial,sans-serif">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), operator>=3D(), operator>() and =
operator<=3D()
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary goa=
l is to generate the following member functions:<br><br>
</span></font><pre><font><span style=3D"font-family:arial,sans-serif"> =
bool operator=3D=3D(const Thing &) const =3D default; /=
/ 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b<br><br></span></font></pre><font><span style=3D"font-family:arial,sans=
-serif">
Oleg.</span></font></div><span><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11337c688ff70404eec347eb--
.
Author: Remo Remotion <remotion4d@googlemail.com>
Date: Mon, 30 Dec 2013 10:21:59 -0800 (PST)
Raw View
------=_Part_7360_32520312.1388427719726
Content-Type: text/plain; charset=ISO-8859-1
Hi.
There is another way to solve this problem, using compile-time reflection.
Here is how it could looks like by converting any class to the std::tuple.
bool operator < (const S& l, const S& r) {
return meta::as_ref_tuple(l) < meta::as_ref_tuple(r); }
This code is already working and can be compiled using experimental Clang
implementation available here:
https://bitbucket.org/remotion/c-reflection
By using bases_trait it should be possible to add support for base classes
too.
Of course it is also possible to use static_assert for custom compiler time
diagnostics.
Remo
On Friday, December 27, 2013 3:35:39 AM UTC+1, oleg.s...@gmail.com wrote:
>
> Hi all, I've written up the discussion into a paper, attempted to provide
> the minimal standardese and implemented a prototype in Clang. The draft is
> attached and I had asked Alisdair Meredith for a proposal number.
>
> I realize that operator!=(), operator>=(), operator>() and operator<=()
> are contentious as people may choose to derive them in weird ways... So,
> I'll treat them as secondary goals. The primary goal is to generate the
> following member functions:
>
> bool operator==(const Thing &) const = default; // 1a
> bool operator<(const Thing &) const = default; // 1b
>
> Oleg.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7360_32520312.1388427719726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Hi.<br><br>There is another way to solve this problem,=
using compile-time reflection.<br><br>Here is how it could looks like by c=
onverting any class to the std::tuple.<br><pre> b<span class=3D"kt">ool<=
/span> <span class=3D"k">operator</span> <span class=3D"o"><</span> <spa=
n class=3D"p">(</span><span class=3D"k">const</span> <span class=3D"n">S</s=
pan><span class=3D"o">&</span> <span class=3D"n">l</span><span class=3D=
"p">,</span> <span class=3D"k">const</span> <span class=3D"n">S</span><span=
class=3D"o">&</span> <span class=3D"n">r</span><span class=3D"p">)</sp=
an> <span class=3D"p">{</span>
<span class=3D"k">return</span> <span class=3D"n">meta</span><span =
class=3D"o">::</span><span class=3D"n">as_ref_tuple</span><span class=3D"p"=
>(</span><span class=3D"n">l</span><span class=3D"p">)</span> <span class=
=3D"o"><</span> <span class=3D"n">meta</span><span class=3D"o">::</span>=
<span class=3D"n">as_ref_tuple</span><span class=3D"p">(</span><span class=
=3D"n">r</span><span class=3D"p">);</span>
<span class=3D"p"> }<br><br></span></pre>This code is already working an=
d can be compiled using experimental Clang implementation available here:<b=
r>https://bitbucket.org/remotion/c-reflection<br><br>By using bases_trait i=
t should be possible to add support for base classes
too.<br>Of course it is also possible to use static_assert for =
custom compiler time diagnostics. <br><br>Remo<br><br><br><br>On Friday, De=
cember 27, 2013 3:35:39 AM UTC+1, oleg.s...@gmail.com wrote:<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"><font size=3D"2"><span style=
=3D"font-family:arial,sans-serif">Hi all, I've written up the discussion in=
to a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), operator>=3D(), operator>() and =
operator<=3D()
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary goal is=
to generate the following member functions:<br><br>
</span></font><pre><font size=3D"2"><span style=3D"font-family:arial,sa=
ns-serif"> bool operator=3D=3D(const Thing &) const =3D defa=
ult; // 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b<br><br></span></font></pre><font size=3D"2"><span style=3D"font-family=
:arial,sans-serif">
Oleg.</span></font></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7360_32520312.1388427719726--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 30 Dec 2013 20:28:10 +0200
Raw View
On 30 December 2013 20:21, Remo Remotion <remotion4d@googlemail.com> wrote:
>
> Hi.
>
> There is another way to solve this problem, using compile-time reflection.
>
> Here is how it could looks like by converting any class to the std::tuple.
>
> bool operator < (const S& l, const S& r) {
> return meta::as_ref_tuple(l) < meta::as_ref_tuple(r);
> }
>
> This code is already working and can be compiled using experimental Clang
> implementation available here:
> https://bitbucket.org/remotion/c-reflection
>
> By using bases_trait it should be possible to add support for base classes
> too.
> Of course it is also possible to use static_assert for custom compiler time
> diagnostics.
Looks seriously interesting. Do you have any plans to tell SG7 (aka
the Reflection
Study Group of the standards committee) about this
work?
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Philipp Maximilian Stephani <p.stephani2@gmail.com>
Date: Mon, 30 Dec 2013 22:11:48 +0000
Raw View
--001a11c1af34ea766d04eec7ba6d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <dibeas@ieee.org>
wrote:
> I have the feeling that I really want something more like:
>
> struct T {
> operator=3D=3D =3D default;
> };
>
> Or some other mechanism by which the type is not present in the signature
> and thus removes the potential for attempts to default cross-type
> comparisons... But this would require mayor changes in the grammar and is
> better avoided.
>
>
Something that looks somewhat natural and probably requires only localized
grammar modifications could be:
using default operator=3D=3D;
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c1af34ea766d04eec7ba6d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div>On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <<a=
href=3D"mailto:dibeas@ieee.org">dibeas@ieee.org</a>> wrote:</div><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">I have the feeling that I really want something more like:=
<br><br>struct T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or so=
me other mechanism by which the type is not present in the signature and th=
us removes the potential for attempts to default cross-type comparisons... =
But this would require mayor changes in the grammar and is better avoided.<=
/div>
<div dir=3D"ltr"><div>
</div></div><br></blockquote><div><br></div><div>Something that looks somew=
hat natural and probably requires only localized grammar modifications coul=
d be:</div><div><br></div><div>using default operator=3D=3D;=A0</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c1af34ea766d04eec7ba6d--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 30 Dec 2013 14:31:19 -0800
Raw View
--001a11c2c48427054b04eec80358
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
But the =3D default syntax matches the existing =3Ddefault syntax for
constructors and company.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 30, 2013 at 2:11 PM, Philipp Maximilian Stephani <
p.stephani2@gmail.com> wrote:
>
>
> On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <dibeas@ieee.org>
> wrote:
>
>> I have the feeling that I really want something more like:
>>
>> struct T {
>> operator=3D=3D =3D default;
>> };
>>
>> Or some other mechanism by which the type is not present in the signatur=
e
>> and thus removes the potential for attempts to default cross-type
>> comparisons... But this would require mayor changes in the grammar and i=
s
>> better avoided.
>>
>>
> Something that looks somewhat natural and probably requires only localize=
d
> grammar modifications could be:
>
> using default operator=3D=3D;
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2c48427054b04eec80358
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">But the =3D default syntax matches the existing =3Ddefault=
syntax for constructors and company.</div><div class=3D"gmail_extra"><br c=
lear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=
=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com=
/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 30, 2013 at 2:11 PM, Philipp=
Maximilian Stephani <span dir=3D"ltr"><<a href=3D"mailto:p.stephani2@gm=
ail.com" target=3D"_blank">p.stephani2@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">
<br><br><div>On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <<a=
href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>> =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I have the feeling that I really want something more like:=
<br><br>struct T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or so=
me other mechanism by which the type is not present in the signature and th=
us removes the potential for attempts to default cross-type comparisons... =
But this would require mayor changes in the grammar and is better avoided.<=
/div>
<div dir=3D"ltr"><div>
</div></div><br></blockquote><div><br></div><div>Something that looks somew=
hat natural and probably requires only localized grammar modifications coul=
d be:</div><div><br></div><div>using default operator=3D=3D;=A0</div><span =
class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2c48427054b04eec80358--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 31 Dec 2013 09:46:10 -0500
Raw View
--bcaec51b9d17111c0e04eed59f05
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Maybe:
using operator=3D=3D =3D default;
A bit awkward to read the sequence of equal signs, but that would match a
bit closer the existing using declaration syntax (although the '=3D default=
'
means that it is no longer a declaration but also a definition...) Ignoring
the exact details (bikesheding?), the more important point I was trying to
get through is that I believe that operators should be implemented as free
functions rather than member functions.
David
On Mon, Dec 30, 2013 at 5:31 PM, Billy O'Neal <billy.oneal@gmail.com> wrote=
:
> But the =3D default syntax matches the existing =3Ddefault syntax for
> constructors and company.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 30, 2013 at 2:11 PM, Philipp Maximilian Stephani <
> p.stephani2@gmail.com> wrote:
>
>>
>>
>> On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <dibeas@ieee.org=
>
>> wrote:
>>
>>> I have the feeling that I really want something more like:
>>>
>>> struct T {
>>> operator=3D=3D =3D default;
>>> };
>>>
>>> Or some other mechanism by which the type is not present in the
>>> signature and thus removes the potential for attempts to default cross-=
type
>>> comparisons... But this would require mayor changes in the grammar and =
is
>>> better avoided.
>>>
>>>
>> Something that looks somewhat natural and probably requires only
>> localized grammar modifications could be:
>>
>> using default operator=3D=3D;
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec51b9d17111c0e04eed59f05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Maybe:<br><br>using operator=3D=3D =3D default;=A0<br><br>=
A bit awkward to read the sequence of equal signs, but that would match a b=
it closer the existing using declaration syntax (although the '=3D defa=
ult' means that it is no longer a declaration but also a definition...)=
Ignoring the exact details (bikesheding?), the more important point I was =
trying to get through is that I believe that operators should be implemente=
d as free functions rather than member functions.<br>
<br>David</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Mon, Dec 30, 2013 at 5:31 PM, Billy O'Neal <span dir=3D"ltr"><<=
a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail=
..com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">But the =3D default syntax =
matches the existing =3Ddefault syntax for constructors and company.</div><=
div class=3D"gmail_extra">
<span class=3D"HOEnZb"><font color=3D"#888888"><br clear=3D"all"><div><div =
dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.or=
g/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div></font></s=
pan><div>
<div class=3D"h5">
<br><br><div class=3D"gmail_quote">On Mon, Dec 30, 2013 at 2:11 PM, Philipp=
Maximilian Stephani <span dir=3D"ltr"><<a href=3D"mailto:p.stephani2@gm=
ail.com" target=3D"_blank">p.stephani2@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">
<br><br><div>On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <<a=
href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>> =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I have the feeling that I really want something more like:=
<br><br>struct T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or so=
me other mechanism by which the type is not present in the signature and th=
us removes the potential for attempts to default cross-type comparisons... =
But this would require mayor changes in the grammar and is better avoided.<=
/div>
<div dir=3D"ltr"><div>
</div></div><br></blockquote><div><br></div><div>Something that looks somew=
hat natural and probably requires only localized grammar modifications coul=
d be:</div><div><br></div><div>using default operator=3D=3D;=A0</div><span>=
<font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div></div><div class=3D"HOEnZb=
"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec51b9d17111c0e04eed59f05--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Tue, 31 Dec 2013 10:20:01 -0800
Raw View
--001a1134c94c3cdd6d04eed89ef4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Why? I fully understand that argument when you're comparing something to
something else (e.g. std::string to char const* or similar), but there's no
practical difference between a member and nonmember in this case (all the
objects in question are of the class type).
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Tue, Dec 31, 2013 at 6:46 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>w=
rote:
> Maybe:
>
> using operator=3D=3D =3D default;
>
> A bit awkward to read the sequence of equal signs, but that would match a
> bit closer the existing using declaration syntax (although the '=3D defau=
lt'
> means that it is no longer a declaration but also a definition...) Ignori=
ng
> the exact details (bikesheding?), the more important point I was trying t=
o
> get through is that I believe that operators should be implemented as fre=
e
> functions rather than member functions.
>
> David
>
>
> On Mon, Dec 30, 2013 at 5:31 PM, Billy O'Neal <billy.oneal@gmail.com>wrot=
e:
>
>> But the =3D default syntax matches the existing =3Ddefault syntax for
>> constructors and company.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 30, 2013 at 2:11 PM, Philipp Maximilian Stephani <
>> p.stephani2@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <dibeas@ieee.or=
g>
>>> wrote:
>>>
>>>> I have the feeling that I really want something more like:
>>>>
>>>> struct T {
>>>> operator=3D=3D =3D default;
>>>> };
>>>>
>>>> Or some other mechanism by which the type is not present in the
>>>> signature and thus removes the potential for attempts to default cross=
-type
>>>> comparisons... But this would require mayor changes in the grammar and=
is
>>>> better avoided.
>>>>
>>>>
>>> Something that looks somewhat natural and probably requires only
>>> localized grammar modifications could be:
>>>
>>> using default operator=3D=3D;
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1134c94c3cdd6d04eed89ef4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why? I fully understand that argument when you're comp=
aring something to something else (e.g. std::string to char const* or simil=
ar), but there's no practical difference between a member and nonmember=
in this case (all the objects in question are of the class type).</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 6:46 AM, David R=
odr=EDguez Ibeas <span dir=3D"ltr"><<a href=3D"mailto:dibeas@ieee.org" t=
arget=3D"_blank">dibeas@ieee.org</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">Maybe:<br><br>using operator=3D=3D =3D default;=A0<br><br>=
A bit awkward to read the sequence of equal signs, but that would match a b=
it closer the existing using declaration syntax (although the '=3D defa=
ult' means that it is no longer a declaration but also a definition...)=
Ignoring the exact details (bikesheding?), the more important point I was =
trying to get through is that I believe that operators should be implemente=
d as free functions rather than member functions.<span class=3D"HOEnZb"><fo=
nt color=3D"#888888"><br>
<br>David</font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div c=
lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Dec 30, 201=
3 at 5:31 PM, Billy O'Neal <span dir=3D"ltr"><<a href=3D"mailto:bill=
y.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">But the =3D default syntax =
matches the existing =3Ddefault syntax for constructors and company.</div><=
div class=3D"gmail_extra">
<span><font color=3D"#888888"><br clear=3D"all"><div><div dir=3D"ltr"><div>=
Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div></font></s=
pan><div>
<div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 30, 2013 at 2:11 PM, Philipp=
Maximilian Stephani <span dir=3D"ltr"><<a href=3D"mailto:p.stephani2@gm=
ail.com" target=3D"_blank">p.stephani2@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">
<br><br><div>On Mon Dec 30 2013 at 17:40:45, David Rodr=EDguez Ibeas <<a=
href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>> =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I have the feeling that I really want something more like:=
<br><br>struct T {<br>=A0 =A0operator=3D=3D =3D default;<br>};<br><br>Or so=
me other mechanism by which the type is not present in the signature and th=
us removes the potential for attempts to default cross-type comparisons... =
But this would require mayor changes in the grammar and is better avoided.<=
/div>
<div dir=3D"ltr"><div>
</div></div><br></blockquote><div><br></div><div>Something that looks somew=
hat natural and probably requires only localized grammar modifications coul=
d be:</div><div><br></div><div>using default operator=3D=3D;=A0</div><span>=
<font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div></div><div><div>
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134c94c3cdd6d04eed89ef4--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Tue, 31 Dec 2013 13:55:34 -0500
Raw View
--001a11c24820f0902204eed91a86
Content-Type: text/plain; charset=ISO-8859-1
[Response inline]
On Tue, Dec 31, 2013 at 1:20 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> Why? I fully understand that argument when you're comparing something to
> something else (e.g. std::string to char const* or similar), but there's no
> practical difference between a member and nonmember in this case (all the
> objects in question are of the class type).
>
>
I already provided an example in a previous message in this thread.
Basically if the type allows for implicit conversions, then the free
function implementation is symmetric with respect to types (as it should
also be with respect to values), while the member function implementation
will only allow the implicit conversion on the right hand side.
Quoting the previous example:
struct T {
int value;
T(int v) : value(v) {} // implicit!
bool operator==(T const &) = default;
};
int main() {
return 1 == T(1);
}
If 'operator==' is implemented as a member function that code will fail,
but 'T(1) == 1' will compile creating an asymmetry. If the operator is
implemented as a free function both will compile, providing symmetry with
respect to types in the expression.
David
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c24820f0902204eed91a86
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">[Response inline]<br><br><div c=
lass=3D"gmail_quote">On Tue, Dec 31, 2013 at 1:20 PM, Billy O'Neal <spa=
n dir=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank=
">billy.oneal@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Why? I fully understand that argument whe=
n you're comparing something to something else (e.g. std::string to cha=
r const* or similar), but there's no practical difference between a mem=
ber and nonmember in this case (all the objects in question are of the clas=
s type).</div>
<div class=3D"gmail_extra"><div class=3D"im"><br></div></div></blockquote><=
div><br>I already provided an example in a previous message in this thread.=
Basically if the type allows for implicit conversions, then the free funct=
ion implementation is symmetric with respect to types (as it should also be=
with respect to values), while the member function implementation will onl=
y allow the implicit conversion on the right hand side.<br>
<br>Quoting the previous example:<br><br><span style=3D"font-family:arial,s=
ans-serif;font-size:13px">struct T {</span><br style=3D"font-family:arial,s=
ans-serif;font-size:13px"><span style=3D"font-family:arial,sans-serif;font-=
size:13px">=A0 =A0int value;</span><br style=3D"font-family:arial,sans-seri=
f;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0T(int v)=
: value(v) {} =A0 =A0 =A0 =A0 =A0 =A0 // implicit!</span><br style=3D"font=
-family:arial,sans-serif;font-size:13px"><span style=3D"font-family:arial,s=
ans-serif;font-size:13px">=A0 =A0bool operator=3D=3D(T const &) =3D def=
ault;</span><br style=3D"font-family:arial,sans-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">};</span><br st=
yle=3D"font-family:arial,sans-serif;font-size:13px"><span style=3D"font-fam=
ily:arial,sans-serif;font-size:13px">int main() {</span><br style=3D"font-f=
amily:arial,sans-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0return 1=
=3D=3D T(1);</span><br style=3D"font-family:arial,sans-serif;font-size:13p=
x"><span style=3D"font-family:arial,sans-serif;font-size:13px">}<br></span>=
<br>If 'operator=3D=3D' is implemented as a member function that co=
de will fail, but 'T(1) =3D=3D 1' will compile creating an asymmetr=
y. If the operator is implemented as a free function both will compile, pro=
viding symmetry with respect to types in the expression.<br>
<br>David</div></div></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c24820f0902204eed91a86--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 31 Dec 2013 12:13:32 -0800 (PST)
Raw View
------=_Part_304_21430743.1388520812362
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You can use syntax like this:
struct T {
int value;
T(int v) : value(v) {}
friend bool operator=3D=3D(T const &, T const &) =3D default; //free fun=
ction
};
On Tuesday, December 31, 2013 7:55:34 PM UTC+1, David Rodr=EDguez Ibeas wro=
te:
>
> [Response inline]
>
> On Tue, Dec 31, 2013 at 1:20 PM, Billy O'Neal <billy...@gmail.com<javascr=
ipt:>
> > wrote:
>
>> Why? I fully understand that argument when you're comparing something to=
=20
>> something else (e.g. std::string to char const* or similar), but there's=
no=20
>> practical difference between a member and nonmember in this case (all th=
e=20
>> objects in question are of the class type).
>>
>>
> I already provided an example in a previous message in this thread.=20
> Basically if the type allows for implicit conversions, then the free=20
> function implementation is symmetric with respect to types (as it should=
=20
> also be with respect to values), while the member function implementation=
=20
> will only allow the implicit conversion on the right hand side.
>
> Quoting the previous example:
>
> struct T {
> int value;
> T(int v) : value(v) {} // implicit!
> bool operator=3D=3D(T const &) =3D default;
> };
> int main() {
> return 1 =3D=3D T(1);
> }
>
> If 'operator=3D=3D' is implemented as a member function that code will fa=
il,=20
> but 'T(1) =3D=3D 1' will compile creating an asymmetry. If the operator i=
s=20
> implemented as a free function both will compile, providing symmetry with=
=20
> respect to types in the expression.
>
> David
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_304_21430743.1388520812362
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can use syntax like this:<br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> value</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br> T</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> value</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
friend</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> T </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">default</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">//free function</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">};</span><span style=3D"font-family:arial,sans-ser=
if;font-size:13px"></span></div></code></div><br><br><br>On Tuesday, Decemb=
er 31, 2013 7:55:34 PM UTC+1, David Rodr=EDguez Ibeas wrote:<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"><div>[Response inline]<br><b=
r><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 1:20 PM, Billy O'Neal =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"TmIWPlxCCNgJ" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">billy...@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Why? I fully understand that argument whe=
n you're comparing something to something else (e.g. std::string to char co=
nst* or similar), but there's no practical difference between a member and =
nonmember in this case (all the objects in question are of the class type).=
</div>
<div><div><br></div></div></blockquote><div><br>I already provided an examp=
le in a previous message in this thread. Basically if the type allows for i=
mplicit conversions, then the free function implementation is symmetric wit=
h respect to types (as it should also be with respect to values), while the=
member function implementation will only allow the implicit conversion on =
the right hand side.<br>
<br>Quoting the previous example:<br><br><span style=3D"font-family:arial,s=
ans-serif;font-size:13px">struct T {</span><br style=3D"font-family:arial,s=
ans-serif;font-size:13px"><span style=3D"font-family:arial,sans-serif;font-=
size:13px"> int value;</span><br style=3D"font-family:arial,san=
s-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px"> T(=
int v) : value(v) {} // implicit!=
</span><br style=3D"font-family:arial,sans-serif;font-size:13px"><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px"> bool operato=
r=3D=3D(T const &) =3D default;</span><br style=3D"font-family:arial,sa=
ns-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">};</span><br st=
yle=3D"font-family:arial,sans-serif;font-size:13px"><span style=3D"font-fam=
ily:arial,sans-serif;font-size:13px">int main() {</span><br style=3D"font-f=
amily:arial,sans-serif;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px"> re=
turn 1 =3D=3D T(1);</span><br style=3D"font-family:arial,sans-serif;font-si=
ze:13px"><span style=3D"font-family:arial,sans-serif;font-size:13px">}<br><=
/span><br>If 'operator=3D=3D' is implemented as a member function that code=
will fail, but 'T(1) =3D=3D 1' will compile creating an asymmetry. If the =
operator is implemented as a free function both will compile, providing sym=
metry with respect to types in the expression.<br>
<br>David</div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_304_21430743.1388520812362--
.
Author: Remotion <remotion4d@googlemail.com>
Date: Wed, 1 Jan 2014 08:00:11 -0800 (PST)
Raw View
------=_Part_214_26624011.1388592011849
Content-Type: text/plain; charset=ISO-8859-1
Yes once it is a bit more mature.
This project is very new so I will need resolve most serious problems fist.
Any help is welcome.
Remo
On Monday, December 30, 2013 7:28:10 PM UTC+1, Ville Voutilainen wrote:
>
>
> Looks seriously interesting. Do you have any plans to tell SG7 (aka
> the Reflection
> Study Group of the standards committee) about this
> work?
>
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_214_26624011.1388592011849
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Yes once it is a bit more mature.<br>This project is v=
ery new so I will need resolve most serious problems fist.<br>Any help is w=
elcome.<br><br>Remo<br><br>On Monday, December 30, 2013 7:28:10 PM UTC+1, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Looks seriously interesting. Do you have any plans to tell SG7 (aka
<br>the Reflection
<br>Study Group of the standards committee) about this
<br>work?
<br>
<br><a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgroups#!fo=
rum/reflection" target=3D"_blank" onmousedown=3D"this.href=3D'https://group=
s.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection';return true;=
" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/?fro=
mgroups#!forum/reflection';return true;">https://groups.google.com/a/<wbr>i=
socpp.org/forum/?fromgroups#!<wbr>forum/reflection</a>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_214_26624011.1388592011849--
.
Author: oleg.smolsky@gmail.com
Date: Sun, 5 Jan 2014 21:20:06 -0800 (PST)
Raw View
------=_Part_210_14271734.1388985606309
Content-Type: multipart/alternative;
boundary="----=_Part_211_17964805.1388985606309"
------=_Part_211_17964805.1388985606309
Content-Type: text/plain; charset=ISO-8859-1
Here is the updated paper with (I hope) a fully developed "Technical
specifications" section.
P.S. I can publish a Clang patch that implements this proposal, if there is
any interest.
Kind regards,
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_211_17964805.1388985606309
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr">Here is the updated paper with (I hope) a fully developed "Technical specifications" section.<br><br>P.S. I can publish a Clang patch that implements this proposal, if there is any interest.<br><br>Kind regards,<br>Oleg.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_211_17964805.1388985606309--
------=_Part_210_14271734.1388985606309
Content-Type: text/html; charset=US-ASCII; name=equality.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=equality.html
X-Attachment-Id: 149556a8-90ad-4d35-a8cc-46f0ee069743
Content-ID: <149556a8-90ad-4d35-a8cc-46f0ee069743>
<html><head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Defaulted comparison operators</title>
<style type="text/css">
..addition {
background-color: #66FF99;
}
..removal {
text-decoration: line-through;
}
li {
padding-bottom: 0.3em;
}
</style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="619">
<tr>
<td width="167" align="left" valign="top">Document number:</td>
<td width="452"><i>Nnnnn=yy-nnnn</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Date:</td>
<td width="452"><i>2013-12-29</i></td>
</tr>
<tr>
<td width="167" align="left" valign="top">Project:</td>
<td width="452">Programming Language C++, Language Evolution Working Group</td>
</tr>
<tr>
<td width="167" align="left" valign="top">Reply-to:</td>
<td width="452">Oleg Smolsky <a href="mailto:oleg.smolsky@gmail.com">oleg.smolsky@gmail.com</a></td>
</tr>
</table>
<h1>I. Introduction</h1>
<p>Provide means of generating default equality, inequality and comparison member operators
for user-defined types. This is strictly
an "opt in" feature so that semantics of existing code remain intact.
<h1>II. Motivation and scope</h1>
<p>This feature would be useful for modern C++ code that operates with types
composed of "regular" members. The definition of equality is trivial in such cases -
member-wise comparison. Inequality can then be generated as an inverse.
<p>This proposal is based on the notion of "regular" types that naturally compose. Such
cases are becoming more prevalent as people program more with value types and writing
(in)equality manually becomes tiresome. This is especially true when trying to
lexicographically compare members.
<h1>III. Design decisions</h1>
<h3>The proposed syntax</h3>
Member-wise generation of special functions is already present in the Standard (see secion 12),
so it seems naturation to extend the syntax to cover comparison member functions.
The proposed syntax for generating the new "defaulted" member functions is as follows:
<pre>
struct Thing {
int a, b, c, d;
bool operator==(const Thing &) const = default; // 1a
bool operator<(const Thing &) const = default; // 1b
bool operator!=(const Thing &) const = default; // 2
bool operator>=(const Thing &) const = default; // 3a
bool operator>(const Thing &) const = default; // 3b
bool operator<=(const Thing &) const = default; // 3c
};</pre>
<p>Aformentioned should generate definitions compatible to the following example:
<pre>
bool Thing::operator==(const Thing &r) const {
return a == r.a && b == r.b && c == r.c && d == r.d;
}
bool Thing::operator<(const Thing &r) const {
return std::tie(a, b, c, d) < std::tie(r.a, r.b, r.c, r.d);
}
bool Thing::operator!=(const Thing &r) const {
return !(*this == r);
}
bool Thing::operator>=(const Thing &r) const {
return !(*this < r);
}
bool Thing::operator>(const Thing &r) const {
return r < *this;
}
bool Thing::operator<=(const Thing &r) const {
return !(*this > r);
}</pre>
<p>I feel this is a natural choice because:
<ul>
<li>C++11 already has member function specifiers such as "default" and "delete"
<li>Users must "opt in" to get the new behavior
<li>Member functions must be declared and are, hence, seen in the source code
</ul>
<h3>Other points of consideration</h3>
<p>It is possible to mandate that <code>operator!=()</code> is to be implemented in a member-wise
fashion and it would we consistent with copy construction, assignment and equality. However:
<ul>
<li>Such an implementation is not useful
<li>The most logical choice for inequality is the boolean inverse of equality
<li>Users are free to implement their own behavior any way the see fit
</ul>
<h1>IV. Implementation</h1>
<p>I have a working prototype implementation using Clang that does the following:
<ul>
<li>parses the proposed syntax
<li>declares and defines the new member functions for an arbitrary number of built-in and
composite members
<li>Equality is generated in a member-wise fashion. Both built-in and user-defined types
are supported.
<li><code>opertator<()</code> is implemented via a call to <code>std::tie()</code>
<li>performs minimal semantic checks
</ul>
<p> The following additional work is needed:
<ul>
<li>support for base classes
<li>enhanced diagnostics pertinent to non-regular members
<li>careful review by language and compiler experts
</ul>
<h1>V. Technical specifications</h1>
<h3>Correction for "12 Special member function [special]" </h3>
<p>The default constructor (12.1), copy constructor and copy assignment operator (12.8),
move constructor and move assignment operator (12.8)
<span class="addition">, equality operators (12.10), comparison operators (12.11)</span>
and destructor (12.4) are special member functions.
<h3>Additional section</h3>
<p><b>12.10 Equality operators [class.equality]</b>
<ol>
<li>A non-union class can provide overloaded equality and inequality operators as per
[over.oper]. The implementation can generate a default implementation via the
<code>= default</code> notation as these member functions are considered special as
per [special].
<li>The defaulted <code>operator==()</code> is generated if and only if all
sub-objects and base classes satisfy the requirements of the <i>EqualityComparable</i>
concept (17.6.3.1).
<li>The implicitly-defined equality operator for a non-union class X performs
memberwise equality checks of its subobjects. Direct base classes of X
are compared first, in the order of their declaration in the base-specifier-list,
and then the immediate non-static data members of X are compared, in
the order in which they were declared in the class definition.<br>
Let x be either the parameter of the function or, for the move operator, an xvalue
referring to the parameter. Each subobject is compared in the manner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <code>operator==()</code> with
the subobject as the object expression and the corresponding subobject of x as a
single function argument (as if by explicit qualification; that is, ignoring any
possible virtual overriding functions in more derived classes);
<li>if the subobject is an array, each element is compared, in the manner appropriate
to the element type;
<li>if the subobject is of trivial type, the built-in "equality" operator is used.
</ul>
<li>The implicitly-defined inequality operator for a non-union class X performs a call
to <code>operator==()</code> and returns a boolean negation of the result
</ol>
<p><b>12.11 Comparison operators [class.comparison]</b>
<ol>
<li>A non-union class can provide overloaded comparison operators as per [over.oper].
The implementation can generate a default implementation via the
<code>= default</code> notation as these member functions are considered special as
per [special].
<li>The defaulted <code>operator<()</code> is generated if and only if all
sub-objects and base classes satisfy the requirements of the <i>LessThanComparable</i>
concept (17.6.3.1).
<li>The implicitly-defined <code>operator<()</code> for a non-union class X performs
lexicographical comparison of member values in a manner compatible to
<code>std::tie()</code>.
Direct base classes of X are compared first, in the order of their declaration in the
base-specifier-list, and then the immediate non-static data members of X are compared,
in the order in which they were declared in the class definition.<br>
Let x be either the parameter of the function or, for the move operator, an xvalue
referring to the parameter. Each subobject is compared in the manner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <code>operator<()</code> with
the subobject as the object expression and the corresponding subobject of x as a
single function argument (as if by explicit qualification; that is, ignoring any
possible virtual overriding functions in more derived classes);
<li>if the subobject is an array, each element is compared, in the manner appropriate
to the element type;
<li>if the subobject is of trivial type, the built-in "less than" operator is used.
</ul>
<li>The implicitly-defined <code>operator>=()</code> for a non-union class X performs a call
to <code>operator<()</code> and returns a boolean negation of the result
<li>The implicitly-defined <code>operator>()</code> for a non-union class X performs a call
to <code>operator<()</code> but reverses the arguments
<li>The implicitly-defined <code>operator<=()</code> for a non-union class X performs a call
to <code>operator>()</code> and returns a boolean negation of the result
</ol>
<h1>VI. Pending work</h1>
<p>The following points need to be worked into the specification:
<ul>
<li>Handle deleted <code>operator==()</code> - the program must be ill-formed
<li>Check whether it is meaningful to handle trivial types with <code>memcmp()</code>.
Eg arrays of built-ins.
<li>What about POD structures? These explicitly generated member functions would
be useful as they do not violate the layout.
</ul>
<h1>VII. Related ideas and discussion</h1>
The following related ideas need consideration for the future:
<ol>
<li>It is possible to generate definitions in terms of the operators being used,
instead of the "key" operator? Would it make sense? Such specification introduces
even more variance into the generated code.
<li>Is it possible to generate these <code>operator==()</code> implicitly? How do we
deal with previously defined non-member operators? (Perhaps we can allow non-member
operators to hide implicitly generated member ones?).
</ol>
<h1>VIII. Acknowledgments</h1>
<p>The fundamental idea comes from Alex Stepanov as his work revolves around
"regular" types. Such types should be automatically copied, assigned and compared.
The first two points have been in the C++ language from the beginning and this
proposal attempts to address the last one.
<p>I want to thank Andrew Sutton for early feedback and guidance.
</body></html>
------=_Part_210_14271734.1388985606309--
.
Author: oleg.smolsky@gmail.com
Date: Wed, 15 Jan 2014 09:53:01 -0800 (PST)
Raw View
------=_Part_4911_30054026.1389808381315
Content-Type: multipart/alternative;
boundary="----=_Part_4912_23162401.1389808381315"
------=_Part_4912_23162401.1389808381315
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Here is another revision made after receiving a detailed feedback from Dani=
el=20
Kr=C3=BCgler. The biggest change is to do with "special function" treatment=
=20
(which is a good thing to remove) yet the standard's references and wording=
=20
have regressed in quality (not a good thing).
I would appreciate any help with wording, if anyone is interested in=20
word-smithing and cross-references.
Thanks in advance!
Oleg.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4912_23162401.1389808381315
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font size=3D"2">Here is another revision made after recei=
ving a detailed feedback from </font>Daniel Kr=C3=BCgler. The biggest chang=
e is to do with "special function" treatment (which is a good thing to remo=
ve) yet the standard's references and wording have regressed in quality (no=
t a good thing).<br><br>I would appreciate any help with wording, if anyone=
is interested in word-smithing and cross-references.<br><br>Thanks in adva=
nce!<br>Oleg.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4912_23162401.1389808381315--
------=_Part_4911_30054026.1389808381315
Content-Type: text/html; charset=UTF-8; name=equality.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=equality.html
X-Attachment-Id: d4a2fe28-67e3-4afa-bf0a-4bac9dcc419c
Content-ID: <d4a2fe28-67e3-4afa-bf0a-4bac9dcc419c>
<html><head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8">
<title>Defaulted comparison operators</title>
<style type=3D"text/css">
..addition {
background-color: #66FF99;
}
..removal {
text-decoration: line-through;
}
li {
padding-bottom: 0.3em;
}
</style>
</head>
<body>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-c=
ollapse: collapse" bordercolor=3D"#111111" width=3D"619">
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Document number:</td>
<td width=3D"452"><i>Nnnnn=3Dyy-nnnn</i></td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Date:</td>
<td width=3D"452"><i>2014-01-13</i></td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Project:</td>
<td width=3D"452">Programming Language C++, Language Evolution Workin=
g Group</td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Reply-to:</td>
<td width=3D"452">Oleg Smolsky <a href=3D"mailto:oleg.smolsky@gmail.c=
om">oleg.smolsky@gmail.com</a></td>
</tr>
</table>
<h1>I. Introduction</h1>
<p>Provide means of generating default equality, inequality and compari=
son member operators
for user-defined types. This is strictly
an "opt in" feature so that semantics of existing code remain intact=
..
<h1>II. Motivation and scope</h1>
<p>This feature would be useful for modern C++ code that operates with =
types
composed of "regular" members. The definition of equality is trivial=
in such cases -
member-wise comparison. Inequality can then be generated as an inver=
se.
<p>This proposal is based on the notion of "regular" types that natural=
ly compose. Such
cases are becoming more prevalent as people program more with value =
types and writing
(in)equality manually becomes tiresome. This is especially true when=
trying to
lexicographically compare members.
<p>Consider the following trivial example where a C++ <code>struct</cod=
e> represents a user
of the system.
<pre>
struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator=3D=3D(const user &) const;
bool operator!=3D(const user &) const;
bool operator<(const user &) const;
bool operator>=3D(const user &) const;
};</pre>
<h3>Verbosity</h3>
The structure consists of regular members and the implementation of=
the equality operator=20
is trivial yet verbose:
<pre>
bool user::operator=3D=3D(const user &r) const {
return id =3D=3D r.id &&
rank =3D=3D r.rank &&
position =3D r.position &&
address1 =3D=3D r.address1 &&
address2 =3D=3D r.address2 &&
city =3D=3D r.city &&
state =3D=3D r.state &&
country =3D=3D r.country &&
us_zip_code =3D=3D r.us_zip_code;
}
bool user::operator<(const user &r) const {
// Can implement a full lexicographical comparison of members, =
but can=20
// also cheat by using standard libraries
return std::tie(id, rank, position, address1, address2, city, s=
tate, country, us_zip_code)
<
std::tie(r.id, r.rank, r.position, r.address1, r.address=
2, r.city, r.state, r.country, r.us_zip_code);
}</pre>
Specifically, this code, while technically required, suffers from t=
he following issues:
<ul>
<li>needlessly verbose - every member is already equality comparabl=
e
<li>error prone - the author could miss a member, or the implementa=
tion may become stale=20
when a new member is added
<li>not in the spirit of "making simple and correct things simple"
</ul>
<h3>Correctness</h3>
<p>It is vital that equal/unequal, less/more-or-equals and more/les=
s-or-equal pairs
behave as boolean negations of each other. After all, the world wou=
ld make no sense
if both <code>operator=3D=3D()</code> and <code>operator!=3D()</cod=
e> returned <i>false</i>!
As such, it is common to implement these operators in terms of each=
other:
<pre>
bool user::operator!=3D(const user &r) const {
return !(*this =3D=3D r);
}
bool user::operator!=3D(const user &r) const {
return !(*this =3D=3D r);
}
bool user::operator>=3D(const user &r) const {
return !(*this < r);
}
bool user::operator>(const user &r) const {
return r < *this;
}
bool user::operator<=3D(const user &r) const {
return !(*this > r);
}
</pre>
Specifically:
<ul>
<li>Based on my experience, this is a useful template that is appli=
cable to the vast
majority of code that looks to define comparison operators
<li>The users should have "short hand" for stating what is common, =
correct and simple
<li>These relations are algebraic in nature and must be considered =
carefully. For example,
<code>operator<()</code> must remain transitive in its natur=
e.
</ul>
<h1>III. Design decisions</h1>
<h3>The proposed syntax</h3>
<p>Member-wise generation of special functions is already present i=
n the Standard=20
(see Section 12), so it seems natural to extend the scope of genera=
tion and reuse
the existing syntax.
<p>The proposed syntax for generating the new "explicitly defaulted=
" member functions
is as follows:
<pre>
struct Thing {
int a, b, c;
std::string d;
bool operator=3D=3D(const Thing &) const =3D default;
bool operator<(const Thing &) const =3D default;
bool operator!=3D(const Thing &) const =3D default;=20
bool operator>=3D(const Thing &) const =3D default;=20
bool operator>(const Thing &) const =3D default;=20
bool operator<=3D(const Thing &) const =3D default;
};</pre>
=20
<p>I feel this is a natural choice because:
<ul>
<li>C++11 already has member function specifiers such as "defau=
lt" and "delete"
<li>Users must "opt in" to get the new behavior
<li>Member functions must be declared and are, hence, seen in t=
he source code
</ul>
<h3>Other points of consideration</h3>
<p>It is possible to mandate that every explicitly defaulted operator i=
s to be implemented
in a member-wise fashion. In fact, it would we consistent with copy =
construction,
assignment and equality. However:
<ul>
<li>Such an implementation is not useful
<li>The most logical choice for inequality is the boolean inver=
se of equality. The
same applies to the other operators - they can all be deriv=
ed.
<li>Users are still free to implement the operators in any way =
the see fit
</ul>
<h1>IV. Implementation</h1>
<p>I have a working prototype implementation using Clang that does =
the following:
<ul>
<li>parses the proposed syntax
<li>declares and defines the new member functions for an arbitr=
ary number of built-in and =20
composite members
<li>Equality is generated in a member-wise fashion. Both built-=
in and user-defined types=20
are supported.
<li><code>operator<()</code> is implemented via a call to <c=
ode>std::tie()</code>
<li>performs minimal semantic checks
</ul>
<p> The following additional work is needed:
<ul>
<li>support for base classes
<li>enhanced diagnostics pertinent to non-regular members
<li>careful review by language and compiler experts
</ul>
<h1>V. Technical specifications</h1>
<h3>Correction for 8.4.2 "Explicitly-defaulted functions [dcl.fct.def.d=
efault]" </h3>
<p>... A function that is explicitly defaulted shall<br>
=E2=80=94 be a special member function, or <span class=3D"addition">=
an explicitly defaulted operator
member function</span>
<h3>Explicitly defaulted operator member functions</h3>
<p>The following operator member functions can be explicitly defaulted:
<ol>
<li>Equality operators: <code>operator=3D=3D()</code> and <code>ope=
rator!=3D()</code> [class.equality]
<li>Comparison operators: <code>operator<()</code>, <code>operat=
or>()</code>,
<code>operator<=3D()</code> and <code>operator>=3D()</cod=
e> [class.comparison]
</ol>
<h3>Correction for "12 Special member function [special]" </h3>
<p>The default constructor (12.1), copy constructor and copy assignment=
operator (12.8),=20
move constructor and move assignment operator (12.8) and destructor=
(12.4) are special
member functions.=20
<span class=3D"addition">These, together with equality operators (1=
2.10) and
comparison operators (12.11) can be explicitly defaulted as per=20
[dcl.fct.def.default]</span>
<h3>Additional sections</h3>
<p><b>12.10 Equality operators [class.equality]</b>
<ol>
<li>A non-union class can provide overloaded equality and inequalit=
y operators as per=20
[over.oper]. A default implementation can be generated via the
<code>=3D default</code> notation as these member functions can=
be explicitly
defalted as per [dcl.fct.def.default].
<li>The defaulted <code>operator=3D=3D()</code> is generated if and=
only if all=20
sub-objects and base classes satisfy the requirements of the <i=
>EqualityComparable</i>
concept (17.6.3.1).
<li>The implicitly-defined equality operator for a non-union class =
X performs=20
memberwise equality comparison of its subobjects. Direct base c=
lasses of X
are compared first, in the order of their declaration in the ba=
se-specifier-list,
and then the immediate non-static data members of X are compare=
d, in
the order in which they were declared in the class definition.<=
br>
Let x be either the parameter of the function or, for the move =
operator, an xvalue=20
referring to the parameter. Each subobject is compared in the m=
anner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <=
code>operator=3D=3D()</code> with
the subobject as the object expression and the correspo=
nding subobject of x as a
single function argument (as if by explicit qualificati=
on; that is, ignoring any=20
possible virtual overriding functions in more derived c=
lasses);
<li>if the subobject is an array, each element is compared,=
in the manner appropriate=20
to the element type;
<li>if the subobject is of trivial type, the built-in "equa=
lity" operator is used.
</ul>
<li>The implicitly-defined inequality operator for a non-union clas=
s X performs a call
to <code>operator=3D=3D()</code> and returns a boolean negation=
of the result
</ol>
<p><b>12.11 Comparison operators [class.comparison]</b>
<ol>
<li>A non-union class can provide overloaded comparison operators a=
s per [over.oper].=20
A a default implementation via the
<code>=3D default</code> notation as these member functions can=
be explicitly defaulted
as per [dcl.fct.def.default].
<li>The defaulted <code>operator<()</code> is generated if and o=
nly if all=20
sub-objects and base classes satisfy the requirements of the <i=
>LessThanComparable</i>=20
concept (17.6.3.1).
<li>The implicitly-defined <code>operator<()</code> for a non-un=
ion class X performs
lexicographical comparison of member values in a manner compati=
ble to
<code>std::tie()</code>.
Direct base classes of X are compared first, in the order of th=
eir declaration in the=20
base-specifier-list, and then the immediate non-static data mem=
bers of X are compared,
in the order in which they were declared in the class definitio=
n.<br>
Let x be either the parameter of the function or, for the move =
operator, an xvalue=20
referring to the parameter. Each subobject is compared in the m=
anner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <=
code>operator<()</code> with
the subobject as the object expression and the correspo=
nding subobject of x as a
single function argument (as if by explicit qualificati=
on; that is, ignoring any=20
possible virtual overriding functions in more derived c=
lasses);
<li>if the subobject is an array, each element is compared,=
in the manner appropriate=20
to the element type;
<li>if the subobject is of trivial type, the built-in "less=
than" operator is used.
</ul>
<li>The implicitly-defined <code>operator>=3D()</code> for a non=
-union class X performs a call
to <code>operator<()</code> and returns a boolean negation o=
f the result
<li>The implicitly-defined <code>operator>()</code> for a non-un=
ion class X performs a call
to <code>operator<()</code> but reverses the arguments
<li>The implicitly-defined <code>operator<=3D()</code> for a non=
-union class X performs a call
to <code>operator>()</code> and returns a boolean negation o=
f the result
</ol>
<h1>VI. Related ideas and discussion</h1>
The following related ideas need consideration for the future:
<ol>
<li>It is possible to generate definitions in terms of the operator=
s being used,=20
instead of the "key" operator? Would it make sense? Such specif=
ication introduces=20
even more variance into the generated code.
<li>Is it possible to generate these <code>operator=3D=3D()</code> =
implicitly? How do we=20
deal with previously defined non-member operators? (Perhaps we =
can allow non-member=20
operators to hide implicitly generated member ones?).
<li>Is it useful to support non-member comparison functions? This i=
s not technically
hard, but introduces additional (somewhat unusual) syntax.
<li>The current specification states that <code>operator<()</cod=
e> performs=20
member comparisons in a manner compatible to <code>std::tie()</=
code>. Such a=20
statement is easy to write and prototype, but, if taken literar=
ily, puts an
unusual dependency between the core language and the standard l=
ibrary. It may be
better to spell out what a "lexicographical comparison" is.
</ol>
<h1>VII. Acknowledgments</h1>
<p>The fundamental idea comes from Alex Stepanov as his work revolv=
es around=20
"regular" types. Such types should be automatically copied, assigne=
d and compared.=20
The first two points have been in the C++ language from the beginni=
ng and this=20
proposal attempts to address the last one.
<p>I want to thank Andrew Sutton for early feedback and guidance as=
well as
Daniel Kr=C3=BCgler for detailed corrections and suggestions.
</body></html>
------=_Part_4911_30054026.1389808381315--
.
Author: Oleg Smolsky <oleg.smolsky@gmail.com>
Date: Sat, 22 Feb 2014 23:11:20 -0800 (PST)
Raw View
------=_Part_2091_33184828.1393139480891
Content-Type: multipart/alternative;
boundary="----=_Part_2092_29200950.1393139480891"
------=_Part_2092_29200950.1393139480891
Content-Type: text/plain; charset=UTF-8
Here is the first official draft: N3950: Defaulted comparison operators.
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2092_29200950.1393139480891
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Here is the first official draft: N3950: Defaulted comparison operators.<br><br>Oleg.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_2092_29200950.1393139480891--
------=_Part_2091_33184828.1393139480891
Content-Type: text/html; charset=UTF-8; name=N3950.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=N3950.html
X-Attachment-Id: 0584d12b-652c-4780-a2bc-91d864c3816c
Content-ID: <0584d12b-652c-4780-a2bc-91d864c3816c>
<html><head>
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8">
<title>Defaulted comparison operators</title>
<style type=3D"text/css">
..addition {
background-color: #66FF99;
}
..removal {
text-decoration: line-through;
}
li {
padding-bottom: 0.3em;
}
pre {
background-color: #F7F6dc;
margin-left: 3em;
margin-right: 3em;
padding: 1em 1em 1em 1em;
font-size: 90%;
}
</style>
</head>
<body>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=3D"border-c=
ollapse: collapse" bordercolor=3D"#111111" width=3D"619">
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Document number:</td>
<td width=3D"452"><i>N3950</i></td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Date:</td>
<td width=3D"452"><i>2014-02-19</i></td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Project:</td>
<td width=3D"452">Programming Language C++, Language Evolution Workin=
g Group</td>
</tr>
<tr>
<td width=3D"167" align=3D"left" valign=3D"top">Reply-to:</td>
<td width=3D"452">Oleg Smolsky <a href=3D"mailto:oleg.smolsky@gmail.c=
om">oleg.smolsky@gmail.com</a></td>
</tr>
</table>
<h1>Defaulted comparison operators</h1>
<h2>I. Introduction</h2>
<p>Provide means of generating default equality, inequality and compari=
son member operators
for user-defined types. This is strictly
an "opt in" feature so that semantics of existing code remain intact=
..
<h2>II. Motivation and scope</h2>
<p>This feature would be useful for modern C++ code that operates with =
types
composed of "regular" members. The definition of equality is trivial=
in such cases -
member-wise comparison. Inequality can then be generated as an inver=
se.
<p>This proposal is based on the notion of "regular" types that natural=
ly compose. Such
cases are becoming more prevalent as people program more with value =
types and writing
(in)equality manually becomes tiresome. This is especially true when=
trying to
lexicographically compare members.
<p>Consider the following trivial example where a C++ type represents s=
ome kind of a user
record:
<pre>
struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator=3D=3D(const user &) const;
bool operator!=3D(const user &) const;
bool operator<(const user &) const;
bool operator>=3D(const user &) const;
};</pre>
<h3>Verbosity</h3>
The structure consists of regular members and the implementation of=
the equality operator=20
is trivial yet verbose:
<pre>
bool user::operator=3D=3D(const user &r) const {
return id =3D=3D r.id &&
rank =3D=3D r.rank &&
position =3D r.position &&
address1 =3D=3D r.address1 &&
address2 =3D=3D r.address2 &&
city =3D=3D r.city &&
state =3D=3D r.state &&
country =3D=3D r.country &&
us_zip_code =3D=3D r.us_zip_code;
}
bool user::operator<(const user &r) const {
// Can implement a full lexicographical comparison of members, but can=
=20
// also cheat by using standard libraries
return std::tie(id, rank, position,
address1, address2, city, state, country,=20
us_zip_code)
<
std::tie(r.id, r.rank, r.position,=20
r.address1, r.address2, r.city, r.state, r.country,
r.us_zip_code);
}</pre>
Specifically, this code, while technically required, suffers from t=
he following issues:
<ul>
<li>needlessly verbose - every member is already equality comparabl=
e
<li>error prone - the author could miss a member, or the implementa=
tion may become stale=20
when a new member is added
<li>not in the spirit of Modern C++: correct things should be intui=
tive and easy
</ul>
<h3>Correctness</h3>
<p>It is vital that equal/unequal, less/more-or-equals and more/les=
s-or-equal pairs
behave as boolean negations of each other. After all, the world wou=
ld make no sense
if both <code>operator=3D=3D()</code> and <code>operator!=3D()</cod=
e> returned <i>false</i>!
As such, it is common to implement these operators in terms of each=
other:
<pre>
bool user::operator!=3D(const user &r) const {
return !(*this =3D=3D r);
}
bool user::operator!=3D(const user &r) const {
return !(*this =3D=3D r);
}
bool user::operator>=3D(const user &r) const {
return !(*this < r);
}
bool user::operator>(const user &r) const {
return r < *this;
}
bool user::operator<=3D(const user &r) const {
return !(*this > r);
}
</pre>
Specifically:
<ul>
<li>Based on my experience, this template is applicable to the vast
majority of types that define comparison operators
<li>The users should have "short hand" for stating what is common, =
correct and simple
<li>These relations are algebraic in nature and must be considered =
carefully. For example,
<code>operator<()</code> must remain transitive in its natur=
e.
</ul>
<h2>III. Design decisions</h2>
<h3>The proposed syntax</h3>
<p>Member-wise generation of special functions is already present i=
n the Standard=20
(see Section 12), so it seems natural to extend the scope of genera=
tion and reuse
the existing syntax.
<p>The proposed syntax for generating the new "explicitly defaulted=
" member functions
is as follows:
<pre class=3D"code">
struct Thing {
int a, b, c;
std::string d;
bool operator=3D=3D(const Thing &) const =3D default;
bool operator<(const Thing &) const =3D default;
bool operator!=3D(const Thing &) const =3D default;=20
bool operator>=3D(const Thing &) const =3D default;=20
bool operator>(const Thing &) const =3D default;=20
bool operator<=3D(const Thing &) const =3D default;
};</pre>
=20
<p>I feel this is a natural choice because:
<ul>
<li>C++11 already has member function specifiers such as "defau=
lt" and "delete"
<li>Users can "opt in" to get the new behavior
<li>Member functions are explicitly declared and are, hence, vi=
sible in the source
code. This is generally helpful when humans read the code.
</ul>
<h3>Other points of consideration</h3>
<p>It is possible to mandate that every explicitly defaulted operator i=
s to be implemented
in a member-wise fashion. In fact, it would we consistent with copy =
construction,
assignment and equality. However:
<ul>
<li>Such an implementation is not useful. It would generate use=
lss code which
may be sizeable due to the number of members.
<li>The most logical choice for inequality is the boolean inver=
se of equality. The
same applies to the other operators - they can all be deriv=
ed.
<li>Users are still free to implement the operators in any way =
the see fit
</ul>
<h2>IV. Implementation</h2>
<p>I have a working prototype implementation using Clang that does =
the following:
<ul>
<li>parses the proposed syntax
<li>declares and defines the new member functions for an arbitr=
ary number of built-in and =20
composite members
<li>Equality is generated in a member-wise fashion. Both built-=
in and user-defined types=20
are supported.
<li><code>operator<()</code> is implemented via a call to <c=
ode>std::tie()</code>
</ul>
<p> The following additional work is needed to get closer to produc=
tion quality:
<ul>
<li>add support for base classes
<li>enhance diagnostics pertinent to non-regular members
<li>test against a large body of code
</ul>
<h2>V. Technical specifications</h2>
<h3>Correction for 8.4.2 "Explicitly-defaulted functions [dcl.fct.def.d=
efault]" </h3>
<ol>
<li>A function definition of the form:<br>
<i>attribute-specifier-seq<sub>opt</sub> decl-specifier-seq<sub>opt=
</sub> declarator virt-specifier-seq<sub>opt</sub></i> =3D <b>default</b> ;=
<br>
is called an explicitly-defaulted definition. A function that is ex=
plicitly defaulted shall<br>
=E2=80=94 be a special member function, or <span class=3D"addition"=
>an explicitly defaultable operator
member function. See [defaultable]</span>
</ol>
<h3>New section in 8.4</h3>
<b>8.4.4 Explicitly defaultable operator member functions [defaultable]=
</b>
<p>The following operator member functions can be explicitly defaulted:
<ol>
<li>Equality operators: <code>operator=3D=3D()</code> and <code>ope=
rator!=3D()</code> [class.equality]
<li>Comparison operators: <code>operator<()</code>, <code>operat=
or>()</code>,
<code>operator<=3D()</code> and <code>operator>=3D()</cod=
e> [class.comparison]
</ol>
<h3>Correction for "12 Special member function [special]" </h3>
<p>The default constructor (12.1), copy constructor and copy assignment=
operator (12.8),=20
move constructor and move assignment operator (12.8) and destructor=
(12.4) are special
member functions.=20
<span class=3D"addition">These, together with equality operators (1=
2.10) and
comparison operators (12.11) can be explicitly defaulted as per=20
[dcl.fct.def.default]</span>
<h3>New section in 12</h3>
<p><b>12.10 Equality operators [class.equality]</b>
<ol>
<li>A non-union class can provide overloaded equality and inequalit=
y operators as per=20
[over.oper]. A default implementation can be generated via the
<code>=3D default</code> notation as these member functions can=
be explicitly
defalted as per [dcl.fct.def.default].
<li>The defaulted <code>operator=3D=3D()</code> is generated if and=
only if all=20
sub-objects and base classes are intergal types or provide <cod=
e>operator=3D=3D()</code>
<br><br>
<small><i>Alternative: IFF they all satisfy the requirements of=
the <i>EqualityComparable</i>
concept (17.6.3.1).</i></small>
<li>The implicitly-defined equality operator for a non-union class =
X performs=20
memberwise equality comparison of its subobjects. Direct base c=
lasses of X
are compared first, in the order of their declaration in the ba=
se-specifier-list,
and then the immediate non-static data members of X are compare=
d, in
the order in which they were declared in the class definition.<=
br>
Let x be either the parameter of the function or, for the move =
operator, an xvalue=20
referring to the parameter. Each subobject is compared in the m=
anner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <=
code>operator=3D=3D()</code> with
the subobject as the object expression and the correspo=
nding subobject of x as a
single function argument (as if by explicit qualificati=
on; that is, ignoring any=20
possible virtual overriding functions in more derived c=
lasses);
<li>if the subobject is an array, each element is compared,=
in the manner appropriate=20
to the element type;
<li>if the subobject is of trivial type, the built-in "equa=
lity" operator is used.
</ul>
<li>The implicitly-defined inequality operator for a non-union clas=
s X performs a call
to <code>operator=3D=3D()</code> and returns a boolean negation=
of the result
</ol>
<p><b>12.11 Comparison operators [class.comparison]</b>
<ol>
<li>A non-union class can provide overloaded comparison operators a=
s per [over.oper].=20
A a default implementation via the
<code>=3D default</code> notation as these member functions can=
be explicitly defaulted
as per [dcl.fct.def.default].
<li>The defaulted <code>operator<()</code> is generated if and o=
nly if all=20
sub-objects and base classes are integral types or provide <cod=
e>operator<()</code>
<br><br>
<small><i>Alternative: IFF they all satisfy the requirements of=
the <i>LessThanComparable</i>=20
concept (17.6.3.1).</i></small>
<li>The implicitly-defined <code>operator<()</code> for a non-un=
ion class X performs
lexicographical comparison of member values in a manner compati=
ble to
<code>std::tie()</code>.
Direct base classes of X are compared first, in the order of th=
eir declaration in the=20
base-specifier-list, and then the immediate non-static data mem=
bers of X are compared,
in the order in which they were declared in the class definitio=
n.<br>
Let x be either the parameter of the function or, for the move =
operator, an xvalue=20
referring to the parameter. Each subobject is compared in the m=
anner appropriate to its type:
<ul>
<li>if the subobject is of class type, as if by a call to <=
code>operator<()</code> with
the subobject as the object expression and the correspo=
nding subobject of x as a
single function argument (as if by explicit qualificati=
on; that is, ignoring any=20
possible virtual overriding functions in more derived c=
lasses);
<li>if the subobject is an array, each element is compared,=
in the manner appropriate=20
to the element type;
<li>if the subobject is of trivial type, the built-in "less=
than" operator is used.
</ul>
<li>The implicitly-defined <code>operator>=3D()</code> for a non=
-union class X performs a call
to <code>operator<()</code> and returns a boolean negation o=
f the result
<li>The implicitly-defined <code>operator>()</code> for a non-un=
ion class X performs a call
to <code>operator<()</code> but reverses the arguments
<li>The implicitly-defined <code>operator<=3D()</code> for a non=
-union class X performs a call
to <code>operator>()</code> and returns a boolean negation o=
f the result
</ol>
<h2>VI. Related ideas and discussion</h2>
The following related ideas need consideration for the future:
<ol>
<li>It is possible to generate definitions in terms of the operator=
s being used,=20
instead of the "key" operator? Would it make sense? Such specif=
ication introduces=20
even more variance into the generated code.
<li>Is it possible to generate these <code>operator=3D=3D()</code> =
implicitly? How do we=20
deal with previously defined non-member operators? (Perhaps we =
can allow non-member=20
operators to hide implicitly generated member ones?).
<li>Is it useful to support non-member comparison functions? This i=
s not technically
hard, but introduces additional (somewhat unusual) syntax.
<li>The current specification states that <code>operator<()</cod=
e> performs=20
member comparisons in a manner compatible to <code>std::tie()</=
code>. Such a=20
statement is easy to write and prototype, but, if taken literar=
ily, puts an
unusual dependency between the core language and the standard l=
ibrary. It may be
better to spell out what a "lexicographical comparison" is.
</ol>
<h2>VII. Acknowledgments</h2>
<p>The fundamental idea comes from Alex Stepanov as his work revolv=
es around=20
"regular" types. Such types should be automatically copied, assigne=
d and compared.=20
The first two points have been in the C++ language from the beginni=
ng and this=20
proposal attempts to address the last one.
<p>I want to thank Andrew Sutton for early feedback and guidance as=
well as
Daniel Kr=C3=BCgler for detailed corrections and suggestions.
</body></html>
------=_Part_2091_33184828.1393139480891--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 23 Feb 2014 01:53:40 -0800 (PST)
Raw View
------=_Part_22_14044030.1393149220966
Content-Type: text/plain; charset=UTF-8
Hi Oleg,
I'm for your proposal, but just fyi, I'm currently working on a
specification for Class Member List Property Queries as an incremental
addition to Type Traits and part of the general SG7 reflection initiative
(see N3814 and N3815), that will enable you to implement a pure library
template function memberwise_equal or memberwise_less so that you can do:
struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator==(const user& that) const { return memberwise_equal<user>(*this, that); }
bool operator!=(const user &) const { return !memberwise_equal<user>(*this, that); }
bool operator<(const user &) const { return memberwise_less<user>(*this, that); }
bool operator>=(const user &) const { return !memberwise_less<user>(*this, that); };
};
The property queries will allow you to enumerate pointer-to-members to each
non-static class member of a class T. You should be able to imagine how to
get from such a list to implementing memberwise_equal and memberwise_less.
Whether the overlap is an issue or not I leave to your good judgement.
Thanks,
Andrew.
On Sunday, February 23, 2014 8:11:20 AM UTC+1, Oleg Smolsky wrote:
>
> Here is the first official draft: N3950: Defaulted comparison operators.
>
> Oleg.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_22_14044030.1393149220966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Oleg,<div><br></div><div>I'm for your proposal, but jus=
t fyi, I'm currently working on a specification for Class Member List Prope=
rty Queries as an incremental addition to Type Traits and part of the gener=
al SG7 reflection initiative (see N3814 and N3815), that will enable you to=
implement a pure library template function <font face=3D"courier new, mono=
space">memberwise_equal</font> or <font face=3D"courier new, monospace">mem=
berwise_less</font> so that you can do:</div><div><br></div><div><pre style=
=3D"background-color: rgb(247, 246, 220); margin-left: 3em; margin-right: 3=
em; padding: 1em; font-size: 12px; color: rgb(0, 0, 0);"><font face=3D"cour=
ier new, monospace">struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator=3D=3D(const user& that) const { return memberwise_equ=
al<user>(*this, that); }
bool operator!=3D(const user &) const { return !memberwise_equal<=
;user>(*this, that); }
bool operator<(const user &) const { return memberwise_less<u=
ser>(*this, that); }
bool operator>=3D(const user &) const { return !memberwise_=
less<user>(*this, that); };</font></pre><pre style=3D"background-colo=
r: rgb(247, 246, 220); margin-left: 3em; margin-right: 3em; padding: 1em; f=
ont-size: 12px; color: rgb(0, 0, 0);"><font face=3D"courier new, monospace"=
>};</font></pre></div><div><br></div><div>The property queries will allow y=
ou to enumerate pointer-to-members to each non-static class member of a cla=
ss T. You should be able to imagine how to get from such a list to im=
plementing <font face=3D"courier new, monospace">memberwise_equal</font> an=
d <font face=3D"courier new, monospace">memberwise_less</font>.</div><div><=
br></div><div>Whether the overlap is an issue or not I leave to your good j=
udgement.</div><div><br></div><div>Thanks,</div><div>Andrew.</div><div><br>=
</div><div><br>On Sunday, February 23, 2014 8:11:20 AM UTC+1, Oleg Smolsky =
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">Here is=
the first official draft: N3950: Defaulted comparison operators.<br><br>Ol=
eg.<br></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_22_14044030.1393149220966--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 23 Feb 2014 12:25:44 +0200
Raw View
On 23 February 2014 11:53, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Hi Oleg,
>
> I'm for your proposal, but just fyi, I'm currently working on a
> specification for Class Member List Property Queries as an incremental
> addition to Type Traits and part of the general SG7 reflection initiative
> (see N3814 and N3815), that will enable you to implement a pure library
> template function memberwise_equal or memberwise_less so that you can do:
>
> struct user {
> uint32_t id, rank, position;
>
> std::string first_name, last_name;
>
> std::string address1, address2, city, state, country;
> uint32_t us_zip_code;
>
> bool operator==(const user& that) const { return
> memberwise_equal<user>(*this, that); }
> bool operator!=(const user &) const { return
> !memberwise_equal<user>(*this, that); }
> bool operator<(const user &) const { return memberwise_less<user>(*this,
> that); }
> bool operator>=(const user &) const { return
> !memberwise_less<user>(*this, that); };
>
> };
>
>
> The property queries will allow you to enumerate pointer-to-members to each
> non-static class member of a class T. You should be able to imagine how to
> get from such a list to implementing memberwise_equal and memberwise_less.
>
> Whether the overlap is an issue or not I leave to your good judgement.
It seems to me the class-property-query approach is superior. With =default,
the generated signature must (?) use the types of the enclosing class. With
the property-query, I can write a CRTP base that does the right thing for
the derived class, so taking the operators into use should just be a matter
of opting in with
struct my_type : operator_base<my_type> {....};
// assume that operator_base<T> defines
// bool friend operator==(const T& a, const T& b) { return
memberwise_equal<T>(a,b);}
// and other such operators
whereas with the =default, I need to write at least two defaults into
all of my class
definitions, the operator== and operator<. Unless, of course, we make further
language changes so that it's possible to inherit the operators.
This happens to be one of the main use cases I have envisioned for reflection,
so I think you're certainly on the right path! ;)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 23 Feb 2014 13:00:44 +0100
Raw View
2014-02-23 8:11 GMT+01:00 Oleg Smolsky <oleg.smolsky@gmail.com>:
> Here is the first official draft: N3950: Defaulted comparison operators.
Please don't describe it as "first official draft" if you have
submitted a document and have an assigned document number for this.
You cannot change this document anymore.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Sun, 23 Feb 2014 09:34:54 -0800
Raw View
This is a multi-part message in MIME format.
--------------010007000905020508000307
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2014-02-23 01:53, Andrew Tomazos wrote:
> Hi Oleg,
>
> I'm for your proposal, but just fyi, I'm currently working on a
> specification for Class Member List Property Queries as an incremental
> addition to Type Traits and part of the general SG7 reflection
> initiative (see N3814 and N3815), that will enable you to implement a
> pure library template function memberwise_equal or memberwise_less so
> that you can do:
>
> struct user {
> uint32_t id, rank, position;
>
> std::string first_name, last_name;
>
> std::string address1, address2, city, state, country;
> uint32_t us_zip_code;
>
> bool operator==(const user& that) const { return memberwise_equal<user>(*this, that); }
> bool operator!=(const user &) const { return !memberwise_equal<user>(*this, that); }
> bool operator<(const user &) const { return memberwise_less<user>(*this, that); }
> bool operator>=(const user &) const { return !memberwise_less<user>(*this, that); };
> };
>
> The property queries will allow you to enumerate pointer-to-members to
> each non-static class member of a class T. You should be able to
> imagine how to get from such a list to implementing memberwise_equal
> and memberwise_less.
>
Hi Andew, this is very cool! It is a huge improvement over C++11, yet, I
feel, these four member function implementations should be baked into
the Core language. IE there is a spectrum of solutions here:
1) manual code
2) std::tie(m1, m2, m3, ...)
3) memberwise_less<T>
4) baked-in defaults
(3) certainly works, yet there is a certain amount boiler plate code
that would be carried over from one class, to another and anther. Plus
the STD headers. This particular usecase, I think, is very well
understood and we can do even better with a very narrow, well pointed
tool :)
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------010007000905020508000307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2014-02-23 01:53, Andrew Tomazos
wrote:<br>
</div>
<blockquote
cite=3D"mid:26103375-dcca-4a14-9535-e4ba2d9b6261@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hi Oleg,
<div><br>
</div>
<div>I'm for your proposal, but just fyi, I'm currently working
on a specification for Class Member List Property Queries as
an incremental addition to Type Traits and part of the general
SG7 reflection initiative (see N3814 and N3815), that will
enable you to implement a pure library template function <font
face=3D"courier new, monospace">memberwise_equal</font> or <fon=
t
face=3D"courier new, monospace">memberwise_less</font> so that
you can do:</div>
<div><br>
</div>
<div>
<pre style=3D"background-color: rgb(247, 246, 220); margin-left: =
3em; margin-right: 3em; padding: 1em; font-size: 12px; color: rgb(0, 0, 0);=
"><font face=3D"courier new, monospace">struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator=3D=3D(const user& that) const { return memberwise_equ=
al<user>(*this, that); }
bool operator!=3D(const user &) const { return !memberwise_equal<=
;user>(*this, that); }
bool operator<(const user &) const { return memberwise_less<u=
ser>(*this, that); }
bool operator>=3D(const user &) const=C2=A0{ return !memberwise_=
less<user>(*this, that); };</font></pre>
<pre style=3D"background-color: rgb(247, 246, 220); margin-left: =
3em; margin-right: 3em; padding: 1em; font-size: 12px; color: rgb(0, 0, 0);=
"><font face=3D"courier new, monospace">};</font></pre>
</div>
<div><br>
</div>
<div>The property queries will allow you to enumerate
pointer-to-members to each non-static class member of a class
T. =C2=A0You should be able to imagine how to get from such a lis=
t
to implementing <font face=3D"courier new, monospace">memberwise_=
equal</font>
and <font face=3D"courier new, monospace">memberwise_less</font>.=
</div>
<br>
</div>
</blockquote>
Hi Andew, this is very cool! It is a huge improvement over C++11,
yet, I feel, these four member function implementations should be
baked into the Core language. IE there is a spectrum of solutions
here: <br>
<br>
=C2=A0=C2=A0=C2=A0 1) manual code<br>
=C2=A0=C2=A0=C2=A0 2) std::tie(m1, m2, m3, ...) <br>
=C2=A0=C2=A0=C2=A0 3) memberwise_less<T> <br>
=C2=A0=C2=A0=C2=A0 4) baked-in defaults<br>
<br>
(3) certainly works, yet there is a certain amount boiler plate code
that would be carried over from one class, to another and anther.
Plus the STD headers. This particular usecase, I think, is very well
understood and we can do even better with a very narrow, well
pointed tool :)<br>
<br>
Oleg.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010007000905020508000307--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Sun, 23 Feb 2014 09:53:17 -0800
Raw View
This is a multi-part message in MIME format.
--------------050707010003090601070104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2014-02-23 09:34, Oleg Smolsky wrote:
> On 2014-02-23 01:53, Andrew Tomazos wrote:
>> Hi Oleg,
>>
>> I'm for your proposal, but just fyi, I'm currently working on a
>> specification for Class Member List Property Queries as an
>> incremental addition to Type Traits and part of the general SG7
>> reflection initiative (see N3814 and N3815), that will enable you to
>> implement a pure library template function memberwise_equal or
>> memberwise_less so that you can do:
>>
>> struct user {
>> uint32_t id, rank, position;
>>
>> std::string first_name, last_name;
>>
>> std::string address1, address2, city, state, country;
>> uint32_t us_zip_code;
>>
>> bool operator==(const user& that) const { return memberwise_equal<user>(*this, that); }
>> bool operator!=(const user &) const { return !memberwise_equal<user>(*this, that); }
>> bool operator<(const user &) const { return memberwise_less<user>(*this, that); }
>> bool operator>=(const user &) const { return !memberwise_less<user>(*this, that); };
>> };
>>
>> The property queries will allow you to enumerate pointer-to-members
>> to each non-static class member of a class T. You should be able to
>> imagine how to get from such a list to implementing memberwise_equal
>> and memberwise_less.
>>
> Hi Andew, this is very cool! It is a huge improvement over C++11, yet,
> I feel, these four member function implementations should be baked
> into the Core language. IE there is a spectrum of solutions here:
>
> 1) manual code
> 2) std::tie(m1, m2, m3, ...)
> 3) memberwise_less<T>
> 4) baked-in defaults
>
> (3) certainly works, yet there is a certain amount boiler plate code
> that would be carried over from one class, to another and anther. Plus
> the STD headers. This particular usecase, I think, is very well
> understood and we can do even better with a very narrow, well pointed
> tool :)
Actually, it just occurred to me, that there is no conflict between
these proposals. The nature of mine is short-hand notation for solving a
common narrow issue. The implementation can choose to generate
operator<() by emitting the full lexicographical comparison of members,
can #include STD headers and call std::tie() or even memberwise_less()
once it is available.
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------050707010003090601070104
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014-02-23 09:34, Oleg Smolsky
wrote:<br>
</div>
<blockquote cite="mid:530A313E.7040308@smolsky.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 2014-02-23 01:53, Andrew Tomazos
wrote:<br>
</div>
<blockquote
cite="mid:26103375-dcca-4a14-9535-e4ba2d9b6261@isocpp.org"
type="cite">
<div dir="ltr">Hi Oleg,
<div><br>
</div>
<div>I'm for your proposal, but just fyi, I'm currently
working on a specification for Class Member List Property
Queries as an incremental addition to Type Traits and part
of the general SG7 reflection initiative (see N3814 and
N3815), that will enable you to implement a pure library
template function <font face="courier new, monospace">memberwise_equal</font>
or <font face="courier new, monospace">memberwise_less</font>
so that you can do:</div>
<div><br>
</div>
<div>
<pre style="background-color: rgb(247, 246, 220); margin-left: 3em; margin-right: 3em; padding: 1em; font-size: 12px; color: rgb(0, 0, 0);"><font face="courier new, monospace">struct user {
uint32_t id, rank, position;
std::string first_name, last_name;
std::string address1, address2, city, state, country;
uint32_t us_zip_code;
bool operator==(const user& that) const { return memberwise_equal<user>(*this, that); }
bool operator!=(const user &) const { return !memberwise_equal<user>(*this, that); }
bool operator<(const user &) const { return memberwise_less<user>(*this, that); }
bool operator>=(const user &) const { return !memberwise_less<user>(*this, that); };</font></pre>
<pre style="background-color: rgb(247, 246, 220); margin-left: 3em; margin-right: 3em; padding: 1em; font-size: 12px; color: rgb(0, 0, 0);"><font face="courier new, monospace">};</font></pre>
</div>
<div><br>
</div>
<div>The property queries will allow you to enumerate
pointer-to-members to each non-static class member of a
class T. You should be able to imagine how to get from such
a list to implementing <font face="courier new, monospace">memberwise_equal</font>
and <font face="courier new, monospace">memberwise_less</font>.</div>
<br>
</div>
</blockquote>
Hi Andew, this is very cool! It is a huge improvement over C++11,
yet, I feel, these four member function implementations should be
baked into the Core language. IE there is a spectrum of solutions
here: <br>
<br>
1) manual code<br>
2) std::tie(m1, m2, m3, ...) <br>
3) memberwise_less<T> <br>
4) baked-in defaults<br>
<br>
(3) certainly works, yet there is a certain amount boiler plate
code that would be carried over from one class, to another and
anther. Plus the STD headers. This particular usecase, I think, is
very well understood and we can do even better with a very narrow,
well pointed tool :)<br>
</blockquote>
Actually, it just occurred to me, that there is no conflict between
these proposals. The nature of mine is short-hand notation for
solving a common narrow issue. The implementation can choose to
generate operator<() by emitting the full lexicographical
comparison of members, can #include STD headers and call std::tie()
or even memberwise_less() once it is available.<br>
<br>
Oleg.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------050707010003090601070104--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 24 Feb 2014 11:42:07 -0500
Raw View
On 2014-02-23 02:11, Oleg Smolsky wrote:
> Correctness
>
> It is vital that equal/unequal, less/more-or-equals and more/less-or-equal pairs
> behave as boolean negations of each other. After all, the world would make no
> sense if both|operator==()| and|operator!=()| returned/false/!
NaN. All comparisons against NaN are false:
'Nan == NaN' -> false
'Nan != NaN' -> false
Also, I would expect/desire that comparison operators for e.g.
optional<int> would similarly, i.e. compare the engaged value but return
false for any comparison involving a disengaged optional. (At least the
ordering comparisons; I could accept operator== on two disengaged
optionals returning true.)
I've written classes with similar behavior for similar reasons, i.e.
when there exists a "not valid" representation, all comparisons
involving such a value return false.
(That said, if I implement operator== and operator<, I would certainly
like to be able to implement the other operators in terms of those as
you go on to describe. Though std::rel_ops seems more convenient (will
that be modified to use '= default'? Should it?). But OTOH, this would
allow me to define a macro, say 'ORDERED', that would expand to these '=
default' declarations, which is even more convenient than std::rel_ops
as it doesn't require repeating the class name.)
TBH what I would really like to see is e.g.:
class Foo
{
protected:
... members ...
public:
[[comparable]] // implement operator==, operator!=
private:
operator<(...); // custom implementation
[[ordered]] // implement >, <=, >=; skip < as it is already declared
}
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 24 Feb 2014 18:53:35 +0200
Raw View
On 24 February 2014 18:42, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2014-02-23 02:11, Oleg Smolsky wrote:
>>
>> Correctness
>>
>> It is vital that equal/unequal, less/more-or-equals and more/less-or-equal
>> pairs
>> behave as boolean negations of each other. After all, the world would make
>> no
>> sense if both|operator==()| and|operator!=()| returned/false/!
>
>
> NaN. All comparisons against NaN are false:
>
> 'Nan == NaN' -> false
> 'Nan != NaN' -> false
>
> Also, I would expect/desire that comparison operators for e.g. optional<int>
> would similarly, i.e. compare the engaged value but return false for any
> comparison involving a disengaged optional. (At least the ordering
> comparisons; I could accept operator== on two disengaged optionals returning
> true.)
I'm sure glad the committee decided otherwise. I don't see why operator<
should return false for two optionals. I also don't see why anyone or anything
should follow the insane example of NaN.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 24 Feb 2014 18:55:59 +0200
Raw View
On 24 February 2014 18:53, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>> Also, I would expect/desire that comparison operators for e.g. optional<int>
>> would similarly, i.e. compare the engaged value but return false for any
>> comparison involving a disengaged optional. (At least the ordering
>> comparisons; I could accept operator== on two disengaged optionals returning
>> true.)
>
>
> I'm sure glad the committee decided otherwise. I don't see why operator<
> should return false for two optionals. I also don't see why anyone or anything
Too brief, that should be "return false for any comparison involving a
disengaged
optional, whichever the comparison order", I guess.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Mon, 24 Feb 2014 09:00:24 -0800
Raw View
On 2014-02-24 08:42, Matthew Woehlke wrote:
> On 2014-02-23 02:11, Oleg Smolsky wrote:
>> Correctness
>>
>> It is vital that equal/unequal, less/more-or-equals and
>> more/less-or-equal pairs
>> behave as boolean negations of each other. After all, the world would
>> make no
>> sense if both|operator==()| and|operator!=()| returned/false/!
>
> NaN. All comparisons against NaN are false:
>
> 'Nan == NaN' -> false
> 'Nan != NaN' -> false
>
> Also, I would expect/desire that comparison operators for e.g.
> optional<int> would similarly, i.e. compare the engaged value but
> return false for any comparison involving a disengaged optional. (At
> least the ordering comparisons; I could accept operator== on two
> disengaged optionals returning true.)
It looks to me that your points on NaN and optional<int> are quite
opposite to the simple, sane world of regular types that I like dealing
with. These types are common and should easy to implement. This is what
the proposal is about.
So, yes, there are semi-regular types for which the equality is not
defined. The proposal is not about those.
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 24 Feb 2014 11:10:46 -0600
Raw View
--001a1134d69cd968a704f32a0f32
Content-Type: text/plain; charset=ISO-8859-1
On 24 February 2014 11:00, Oleg Smolsky <oleg@smolsky.net> wrote:
> On 24 February 2014 10:42, Matthew Woehlke <mw_triad@users.sourceforge.net
> > wrote:
>>
>> Also, I would expect/desire that comparison operators for e.g.
>> optional<int> would similarly, i.e. compare the engaged value but return
>> false for any comparison involving a disengaged optional. (At least the
>> ordering comparisons; I could accept operator== on two disengaged optionals
>> returning true.)
>>
> It looks to me that your points on NaN and optional<int> are quite
> opposite to the simple, sane world of regular types that I like dealing
> with.
Note: as Ville pointed out, if T is a regular type, optional<T> is a
regular type. A disengaged optional is a singular value which is smaller
than all engaged values.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1134d69cd968a704f32a0f32
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 24 February 2014 11:00, Oleg Smolsky <span dir=3D"ltr">=
<<a href=3D"mailto:oleg@smolsky.net" target=3D"_blank">oleg@smolsky.net<=
/a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"">On 24 February 2014 10:42, Matthew Woehlke <span dir=3D"ltr=
"><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">m=
w_triad@users.sourceforge.net</a>></span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
Also, I would expect/desire that comparison operators for e.g. optional<=
int> would similarly, i.e. compare the engaged value but return false fo=
r any comparison involving a disengaged optional. (At least the ordering co=
mparisons; I could accept operator=3D=3D on two disengaged optionals return=
ing true.)<br>
</blockquote></div>
It looks to me that your points on NaN and optional<int> are quite op=
posite to the simple, sane world of regular types that I like dealing with.=
</blockquote><div><br></div><div>Note:=A0 as Ville pointed out, if T is a =
regular type, optional<T> is a regular type.=A0 A disengaged optional=
is a singular value which is smaller than all engaged values.<br clear=3D"=
all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134d69cd968a704f32a0f32--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 24 Feb 2014 09:13:56 -0800
Raw View
Em seg 24 fev 2014, =C3=A0s 09:00:24, Oleg Smolsky escreveu:
> On 2014-02-24 08:42, Matthew Woehlke wrote:
> > On 2014-02-23 02:11, Oleg Smolsky wrote:
> >> Correctness
> >>=20
> >> It is vital that equal/unequal, less/more-or-equals and
> >> more/less-or-equal pairs
> >> behave as boolean negations of each other. After all, the world would
> >> make no
> >> sense if both|operator=3D=3D()| and|operator!=3D()| returned/false/!
> >=20
> > NaN. All comparisons against NaN are false:
> >=20
> > 'Nan =3D=3D NaN' -> false
> > 'Nan !=3D NaN' -> false
> >=20
> > Also, I would expect/desire that comparison operators for e.g.
> > optional<int> would similarly, i.e. compare the engaged value but
> > return false for any comparison involving a disengaged optional. (At
> > least the ordering comparisons; I could accept operator=3D=3D on two
> > disengaged optionals returning true.)
>=20
> It looks to me that your points on NaN and optional<int> are quite
> opposite to the simple, sane world of regular types that I like dealing
> with. These types are common and should easy to implement. This is what
> the proposal is about.
>=20
> So, yes, there are semi-regular types for which the equality is not
> defined. The proposal is not about those.
I'd recommend defining a more sane sorting order for disengaged optionals:
op{} =3D=3D op{}
op{} !=3D engaged
op{} < engaged
From there, build the other relationship operators:
operator!=3D: !(a =3D=3D b)
operator<=3D: a < b || a =3D=3D b =E2=86=92 op{} <=3D engaged
operator>: !(a <=3D b)
operator>=3D: !(a < b) =E2=86=92 engaged >=3D op{}
etc.
This would allow a sorted list containing an optional<T> where T is orderab=
le=20
to also have full ordering and searching.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 24 Feb 2014 11:21:36 -0600
Raw View
--f46d0444ecaf95c14204f32a3625
Content-Type: text/plain; charset=ISO-8859-1
On 24 February 2014 11:13, Thiago Macieira <thiago@macieira.org> wrote:
> I'd recommend defining a more sane sorting order for disengaged optionals:
>
I'd recommend just reading <
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3848.html#optional> to
see what is proposed for optional in the Library Fundamentals TS.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d0444ecaf95c14204f32a3625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 24 February 2014 11:13, Thiago Macieira <span dir=3D"lt=
r"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maci=
eira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">I'd recommend definin=
g a more sane sorting order for disengaged optionals:<br></blockquote><div>
<br></div><div>I'd recommend just reading <<a href=3D"http://open-st=
d.org/JTC1/SC22/WG21/docs/papers/2014/n3848.html#optional">http://open-std.=
org/JTC1/SC22/WG21/docs/papers/2014/n3848.html#optional</a>> to see what=
is proposed for optional in the Library Fundamentals TS.<br clear=3D"all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d0444ecaf95c14204f32a3625--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 24 Feb 2014 12:32:28 -0500
Raw View
On 2014-02-24 12:00, Oleg Smolsky wrote:
> On 2014-02-24 08:42, Matthew Woehlke wrote:
>> On 2014-02-23 02:11, Oleg Smolsky wrote:
>>> Correctness
>>>
>>> It is vital that equal/unequal, less/more-or-equals and
>>> more/less-or-equal pairs
>>> behave as boolean negations of each other. After all, the world would
>>> make no
>>> sense if both|operator==()| and|operator!=()| returned/false/!
>>
>> NaN. [snip]
>
> It looks to me that your points on NaN and optional<int> are quite
> opposite to the simple, sane world of regular types that I like dealing
> with.
Exactly. The examples I was given are definitely outliers.
> These types are common and should easy to implement. This is what
> the proposal is about.
>
> So, yes, there are semi-regular types for which the equality is not
> defined. The proposal is not about those.
Sure :-). I was mostly reacting to the stringent phrasing of the above
"correctness" quote. (Which probably isn't important in the grand scheme
of things...)
To be clear, I don't feel that any change is required to the intent of
your proposal.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 24 Feb 2014 12:34:46 -0500
Raw View
On 2014-02-24 11:53, Ville Voutilainen wrote:
> On 24 February 2014 18:42, Matthew Woehlke
> <mw_triad@users.sourceforge.net> wrote:
>> On 2014-02-23 02:11, Oleg Smolsky wrote:
>>>
>>> Correctness
>>>
>>> It is vital that equal/unequal, less/more-or-equals and more/less-or-equal
>>> pairs
>>> behave as boolean negations of each other. After all, the world would make
>>> no
>>> sense if both|operator==()| and|operator!=()| returned/false/!
>>
>>
>> NaN. All comparisons against NaN are false:
>>
>> 'Nan == NaN' -> false
>> 'Nan != NaN' -> false
Actually I misspoke; != is the only operator that *does* return true
(always, in fact, even e.g. 'n != n' for some 'n' that has a NaN value).
Sorry.
>> Also, I would expect/desire that comparison operators for e.g. optional<int>
>> would similarly, i.e. compare the engaged value but return false for any
>> comparison involving a disengaged optional. (At least the ordering
>> comparisons; I could accept operator== on two disengaged optionals returning
>> true.)
>
> I'm sure glad the committee decided otherwise. I don't see why operator<
> should return false for two optionals. I also don't see why anyone or anything
> should follow the insane example of NaN.
What *else* would you do... throw an exception? There *is no order*
between NaN and anything else (or between an engaged and disengaged
optional, or any similar situation). To suggest otherwise would be
mathematically incorrect.
See also e.g. http://stackoverflow.com/questions/1565164/.
Unordered values (and partially ordered types) exist in the real world
and need to be handled.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 25 Feb 2014 06:39:39 +0200
Raw View
On 24 February 2014 19:34, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
>> I'm sure glad the committee decided otherwise. I don't see why operator<
>> should return false for two optionals. I also don't see why anyone or
>> anything
>> should follow the insane example of NaN.
> What *else* would you do... throw an exception? There *is no order* between
> NaN and anything else (or between an engaged and disengaged optional, or any
> similar situation). To suggest otherwise would be mathematically incorrect.
> See also e.g. http://stackoverflow.com/questions/1565164/.
> Unordered values (and partially ordered types) exist in the real world and
> need to be handled.
I would do what optional as currently proposed does. If you want to handle
optional<floating point type> and NaN, don't use optional's relational
operators,
look through the optional into its underlying type and handle NaN yourself.
And, as currently proposed, there _is_ an order between an engaged and
a disengaged optional. That seems fine to me.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 25 Feb 2014 12:07:18 -0500
Raw View
On 2014-02-24 23:39, Ville Voutilainen wrote:
> On 24 February 2014 19:34, Matthew Woehlke wrote:
>>> I'm sure glad the committee decided otherwise. I don't see why operator<
>>> should return false for two optionals. I also don't see why anyone or
>>> anything
>>> should follow the insane example of NaN.
>> What *else* would you do... throw an exception? There *is no order* between
>> NaN and anything else (or between an engaged and disengaged optional, or any
>> similar situation). To suggest otherwise would be mathematically incorrect.
>> See also e.g. http://stackoverflow.com/questions/1565164/.
>> Unordered values (and partially ordered types) exist in the real world and
>> need to be handled.
>
> as currently proposed, there _is_ an order between an engaged and
> a disengaged optional. That seems fine to me.
I guess another way to look at it is that you can have either
lexicographical total ordering, or mathematically correct ordering. The
former allows for introduction of special rules and exceptions in order
to provide for total ordering (e.g. NaN < -inf).
So while I suppose going the lexicographical route is tolerable for
std::optional, I'm sure glad IEEE didn't apply such nonsense to the
numeric floating point types. And there are other types for which
mathematically correct ordering sane, desired, and *correct* (any other
ordering would be broken).
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 25 Feb 2014 11:22:59 -0600
Raw View
--047d7bd90246689aa204f33e59bd
Content-Type: text/plain; charset=ISO-8859-1
On 25 February 2014 11:07, Matthew Woehlke
<mw_triad@users.sourceforge.net>wrote:
> On 2014-02-24 23:39, Ville Voutilainen wrote:
>
>> On 24 February 2014 19:34, Matthew Woehlke wrote:
>>
>>> I'm sure glad the committee decided otherwise. I don't see why operator<
>>>> should return false for two optionals. I also don't see why anyone or
>>>> anything
>>>> should follow the insane example of NaN.
>>>>
>>> What *else* would you do... throw an exception? There *is no order*
>>> between
>>> NaN and anything else (or between an engaged and disengaged optional, or
>>> any
>>> similar situation). To suggest otherwise would be mathematically
>>> incorrect.
>>> See also e.g. http://stackoverflow.com/questions/1565164/.
>>> Unordered values (and partially ordered types) exist in the real world
>>> and
>>> need to be handled.
>>>
>>
>> as currently proposed, there _is_ an order between an engaged and
>> a disengaged optional. That seems fine to me.
>>
>
> I guess another way to look at it is that you can have either
> lexicographical total ordering, or mathematically correct ordering. The
> former allows for introduction of special rules and exceptions in order to
> provide for total ordering (e.g. NaN < -inf).
>
Could you elaborate? How can you turn a type like double into a type with
a total ordering? Sure, you can create your own comparison function and
use that, but that would also allow you to turn a regular type into a
non-regular type as well, so I don't see why your implication that starting
with a non-regular type is any better.
> So while I suppose going the lexicographical route is tolerable for
> std::optional, I'm sure glad IEEE didn't apply such nonsense to the numeric
> floating point types. And there are other types for which mathematically
> correct ordering sane, desired, and *correct* (any other ordering would be
> broken).
>
Why is the ability to compare NaNs *at all* mathematically correct?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd90246689aa204f33e59bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 25 February 2014 11:07, Matthew Woehlke <span dir=3D"lt=
r"><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">=
mw_triad@users.sourceforge.net</a>></span> wrote:<br><div class=3D"gmail=
_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-02-24 23:=
39, Ville Voutilainen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">
On 24 February 2014 19:34, Matthew Woehlke wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sure glad the committee decided otherwise. I don't see why oper=
ator<<br>
should return false for two optionals. I also don't see why anyone or<b=
r>
anything<br>
should follow the insane example of NaN.<br>
</blockquote>
What *else* would you do... throw an exception? There *is no order* between=
<br>
NaN and anything else (or between an engaged and disengaged optional, or an=
y<br>
similar situation). To suggest otherwise would be mathematically incorrect.=
<br>
See also e.g. <a href=3D"http://stackoverflow.com/questions/1565164/" targe=
t=3D"_blank">http://stackoverflow.com/<u></u>questions/1565164/</a>.<br>
Unordered values (and partially ordered types) exist in the real world and<=
br>
need to be handled.<br>
</blockquote>
<br></div><div class=3D"">
as currently proposed, there _is_ an order between an engaged and<br>
a disengaged optional. That seems fine to me.<br>
</div></blockquote>
<br>
I guess another way to look at it is that you can have either lexicographic=
al total ordering, or mathematically correct ordering. The former allows fo=
r introduction of special rules and exceptions in order to provide for tota=
l ordering (e.g. NaN < -inf).<br>
</blockquote><div><br></div><div>Could you elaborate?=A0 How can you turn a=
type like double into a type with a total ordering?=A0 Sure, you can creat=
e your own comparison function and use that, but that would also allow you =
to turn a regular type into a non-regular type as well, so I don't see =
why your implication that starting with a non-regular type is any better.<b=
r>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
So while I suppose going the lexicographical route is tolerable for std::op=
tional, I'm sure glad IEEE didn't apply such nonsense to the numeri=
c floating point types. And there are other types for which mathematically =
correct ordering sane, desired, and *correct* (any other ordering would be =
broken).<span class=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></blockquote><div><br></div><div>Why is the ability to compar=
e NaNs *at all* mathematically correct?<br></div></div>-- <br>=A0Nevin &quo=
t;:-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd90246689aa204f33e59bd--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 25 Feb 2014 13:02:53 -0500
Raw View
On 2014-02-25 12:22, Nevin Liber wrote:
> On 25 February 2014 11:07, Matthew Woehlke wrote:
>> I guess another way to look at it is that you can have either
>> lexicographical total ordering, or mathematically correct ordering. The
>> former allows for introduction of special rules and exceptions in order to
>> provide for total ordering (e.g. NaN < -inf).
>
> Could you elaborate? How can you turn a type like double into a type with
> a total ordering?
By adding exceptions to handle cases where ordering is not otherwise
possible, such as the example above.
I'm not talking about how to implement code to do such a thing. The
above is a general statement; for a given type, an implementation of
ordering operators must choose either a lexicographical total order, or
a mathematically correct order. In some cases (e.g. floating point,
std::optional of numeric types), the two are mutually exclusive.
> Why is the ability to compare NaNs *at all* mathematically correct?
What *should* it do?
- Throw an exception? (That's roughly what signaling NaN *does*.)
- Change the return type of operator<, etc. to std::optional<bool>?
IMHO the behavior of QNaN is the most reasonable answer possible to a
problem which has no perfect solution.
One could argue that in such cases code should always ask "are these
values comparable" before attempting to compare them, but that's not
especially practical, nor is it always necessary if your comparisons are
expressed in a way that takes the possibility of NaN into account.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 25 Feb 2014 15:15:00 -0500
Raw View
--001a1133a8182d202d04f340be82
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Feb 25, 2014 at 1:02 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-02-25 12:22, Nevin Liber wrote:
>
> On 25 February 2014 11:07, Matthew Woehlke wrote:
>>
>>> I guess another way to look at it is that you can have either
>>> lexicographical total ordering, or mathematically correct ordering. The
>>> former allows for introduction of special rules and exceptions in order
>>> to
>>> provide for total ordering (e.g. NaN < -inf).
>>>
>>
>> Could you elaborate? How can you turn a type like double into a type with
>> a total ordering?
>>
>
> By adding exceptions to handle cases where ordering is not otherwise
> possible, such as the example above.
>
> I'm not talking about how to implement code to do such a thing. The above
> is a general statement; for a given type, an implementation of ordering
> operators must choose either a lexicographical total order, or a
> mathematically correct order. In some cases (e.g. floating point,
> std::optional of numeric types), the two are mutually exclusive.
>
>
If you have rules and you follow those rules, then you are doing math, and
whatever you are doing is "mathematically correct".
If you want to order NaN, by saying it is the least of all floats or the
greatest of all floats, or just bigger than 0 but less that all positive
floats, all of those would be "mathematically correct".
The problem is that the type 'float' (or double) is NOT a type representing
numbers. It is a type that represents a large (but finite) set of numbers,
and a few non-numbers.
So whatever rules you want to put on that type make it into a, well,
whatever the rules you pick make it into - a Ring or Field or Commutative
Group or non-of-the-above or whatever.
Unsigned integers are the only "mathematically correct" type that we have,
in the sense that it is closed under its operations modulo 2**N.
Tony
P.S. And operator>=() should lexigraphically call the operator>=() of each
of its members, NOT simply do the opposite of operator<(). But I mention
here that mostly just to bug Ville. :-)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1133a8182d202d04f340be82
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Feb 25, 2014 at 1:02 PM, Matthew Woehlke <span dir=3D"ltr">=
<<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2014-02-25 12:22, Nevin Liber wrote:<div =
class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 25 February 2014 11:07, Matthew Woehlke wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I guess another way to look at it is that you can have either<br>
lexicographical total ordering, or mathematically correct ordering. The<br>
former allows for introduction of special rules and exceptions in order to<=
br>
provide for total ordering (e.g. NaN < -inf).<br>
</blockquote>
<br>
Could you elaborate? =A0How can you turn a type like double into a type wit=
h<br>
a total ordering?<br>
</blockquote>
<br></div>
By adding exceptions to handle cases where ordering is not otherwise possib=
le, such as the example above.<br>
<br>
I'm not talking about how to implement code to do such a thing. The abo=
ve is a general statement; for a given type, an implementation of ordering =
operators must choose either a lexicographical total order, or a mathematic=
ally correct order. In some cases (e.g. floating point, std::optional of nu=
meric types), the two are mutually exclusive.<div class=3D"">
<br></div></blockquote><div><br></div><div>If you have rules and you follow=
those rules, then you are doing math, and whatever you are doing is "=
mathematically correct".<br></div><div>If you want to order NaN, by sa=
ying it is the least of all floats or the greatest of all floats, or just b=
igger than 0 but less that all positive floats, all of those would be "=
;mathematically correct".<br>
<br></div><div>The problem is that the type 'float' (or double) is =
NOT a type representing numbers.=A0 It is a type that represents a large (b=
ut finite) set of numbers, and a few non-numbers.<br>So whatever rules you =
want to put on that type make it into a, well, whatever the rules you pick =
make it into - a Ring or Field or Commutative Group or non-of-the-above or =
whatever.<br>
<br></div><div>Unsigned integers are the only "mathematically correct&=
quot; type that we have, in the sense that it is closed under its operation=
s modulo 2**N.<br><br></div><div>=A0Tony<br></div></div><br><br></div><div =
class=3D"gmail_extra">
P.S. And operator>=3D() should lexigraphically call the operator>=3D(=
) of each of its members, NOT simply do the opposite of operator<().=A0 =
But I mention here that mostly just to bug Ville. :-)<br><br></div><div cla=
ss=3D"gmail_extra">
<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133a8182d202d04f340be82--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Tue, 25 Feb 2014 12:27:47 -0800
Raw View
On 2014-02-25 12:15, Tony V E wrote:
> P.S. And operator>=() should lexigraphically call the operator>=() of
> each of its members, NOT simply do the opposite of operator<(). But I
> mention here that mostly just to bug Ville. :-)
Hey Tony, could you explain this point a bit please?
Oleg.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 25 Feb 2014 22:39:34 +0200
Raw View
On 25 February 2014 22:27, Oleg Smolsky <oleg@smolsky.net> wrote:
> On 2014-02-25 12:15, Tony V E wrote:
>>
>> P.S. And operator>=() should lexigraphically call the operator>=() of each
>> of its members, NOT simply do the opposite of operator<(). But I mention
>> here that mostly just to bug Ville. :-)
>
> Hey Tony, could you explain this point a bit please?
We had some disagreement on how to define such relational operators, especially
for optional. Currently optional's operator>= does the opposite of
operator<, and
the insinuations to do something else are mere crazy talk. ;)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Wed, 26 Feb 2014 00:09:51 +0100
Raw View
On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
> We had some disagreement on how to define such relational operators, especially
> for optional. Currently optional's operator>= does the opposite of
> operator<, and
> the insinuations to do something else are mere crazy talk. ;)
Was three-valued logic considered during the discussions?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Feb 2014 08:01:58 +0200
Raw View
On 26 February 2014 01:09, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
> On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
>
>> We had some disagreement on how to define such relational operators,
>> especially
>> for optional. Currently optional's operator>= does the opposite of
>> operator<, and
>> the insinuations to do something else are mere crazy talk. ;)
>
>
> Was three-valued logic considered during the discussions?
I think it was mentioned that optional<bool> has some similarities
to boost::tribool, while not quite achieving the convenience nor the
exact semantics. Other than that, no, I don't think so. I suppose
it would be interesting to make the relational operators of optional
to return optional<bool>, but I do not expect to go there.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 26 Feb 2014 10:35:57 -0500
Raw View
--001a1136d45e097c7b04f350f669
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Feb 25, 2014 at 6:09 PM, Bjorn Reese <breese@mail1.stofanet.dk>wrote:
> On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
>
> We had some disagreement on how to define such relational operators,
>> especially
>> for optional. Currently optional's operator>= does the opposite of
>> operator<, and
>> the insinuations to do something else are mere crazy talk. ;)
>>
>
> Was three-valued logic considered during the discussions?
>
>
Only to the point of agreeing that *no one* wanted NaN behaviour. We didn't
really argue it through as to whether returning std::optional<bool> is the
same as NaN behaviour, but it is of the same "flavour".
Interestingly, in any functional language like, say Haskell, the 'obvious'
answer would be for operator<() to return optional<bool>. ie you 'lift'
all the operations up to the new level by applying optional<> to
everything. Not sure if we will see diverging from that as a mistake in 10
years as functional style grows. If so, we can always introduce a maybe<>
class...
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1136d45e097c7b04f350f669
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Feb 25, 2014 at 6:09 PM, Bjorn Reese <span dir=3D"ltr"><=
<a href=3D"mailto:breese@mail1.stofanet.dk" target=3D"_blank">breese@mail1.=
stofanet.dk</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 02/25/2014 09:39 PM, Vill=
e Voutilainen wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
We had some disagreement on how to define such relational operators, especi=
ally<br>
for optional. Currently optional's operator>=3D does the opposite of=
<br>
operator<, and<br>
the insinuations to do something else are mere crazy talk. ;)<br>
</blockquote>
<br></div>
Was three-valued logic considered during the discussions?<div class=3D"HOEn=
Zb"><div class=3D"h5"><br></div></div></blockquote><div><br></div></div>Onl=
y to the point of agreeing that *no one* wanted NaN behaviour. We didn'=
t really argue it through as to whether returning std::optional<bool>=
is the same as NaN behaviour, but it is of the same "flavour".<b=
r>
<br></div><div class=3D"gmail_extra">Interestingly, in any functional langu=
age like, say Haskell, the 'obvious' answer would be for operator&l=
t;() to return optional<bool>.=A0 ie you 'lift' all the opera=
tions up to the new level by applying optional<> to everything.=A0 No=
t sure if we will see diverging from that as a mistake in 10 years as funct=
ional style grows.=A0 If so, we can always introduce a maybe<> class.=
...<br>
<br></div><div class=3D"gmail_extra">Tony<br></div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1136d45e097c7b04f350f669--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Feb 2014 07:43:16 -0800
Raw View
Em qua 26 fev 2014, =E0s 10:35:57, Tony V E escreveu:
> Interestingly, in any functional language like, say Haskell, the 'obvious=
'
> answer would be for operator<() to return optional<bool>. ie you 'lift'
> all the operations up to the new level by applying optional<> to
> everything. Not sure if we will see diverging from that as a mistake in =
10
> years as functional style grows. If so, we can always introduce a maybe<=
>
> class...
How would maybe and optional differ?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 26 Feb 2014 10:43:37 -0500
Raw View
--001a11c355b274273704f3511155
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Feb 26, 2014 at 10:35 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>
>
> On Tue, Feb 25, 2014 at 6:09 PM, Bjorn Reese <breese@mail1.stofanet.dk>wrote:
>
>> On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
>>
>> We had some disagreement on how to define such relational operators,
>>> especially
>>> for optional. Currently optional's operator>= does the opposite of
>>> operator<, and
>>> the insinuations to do something else are mere crazy talk. ;)
>>>
>>
>> Was three-valued logic considered during the discussions?
>>
>>
> Only to the point of agreeing that *no one* wanted NaN behaviour. We
> didn't really argue it through as to whether returning std::optional<bool>
> is the same as NaN behaviour, but it is of the same "flavour".
>
> Interestingly, in any functional language like, say Haskell, the 'obvious'
> answer would be for operator<() to return optional<bool>. ie you 'lift'
> all the operations up to the new level by applying optional<> to
> everything. Not sure if we will see diverging from that as a mistake in 10
> years as functional style grows. If so, we can always introduce a maybe<>
> class...
>
> Tony
>
>
Also, the number 1 reason for adding operator<() was to allow optionals to
be used in standard containers and algorithms (sorted or as keys, etc).
As it turns out, this is better done via specializing std::less, but having
operator<() diverge from std::less is always a bit confusing as well.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c355b274273704f3511155
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Feb 26, 2014 at 10:35 AM, Tony V E <span dir=3D"ltr"><<a=
href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D""><br><br><div class=3D"gmail_quote">On Tue, Feb 25, 2014=
at 6:09 PM, Bjorn Reese <span dir=3D"ltr"><<a href=3D"mailto:breese@mai=
l1.stofanet.dk" target=3D"_blank">breese@mail1.stofanet.dk</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 02/25/2014 09:39 PM, Ville Voutilain=
en wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
We had some disagreement on how to define such relational operators, especi=
ally<br>
for optional. Currently optional's operator>=3D does the opposite of=
<br>
operator<, and<br>
the insinuations to do something else are mere crazy talk. ;)<br>
</blockquote>
<br></div>
Was three-valued logic considered during the discussions?<div><div><br></di=
v></div></blockquote><div><br></div></div></div>Only to the point of agreei=
ng that *no one* wanted NaN behaviour. We didn't really argue it throug=
h as to whether returning std::optional<bool> is the same as NaN beha=
viour, but it is of the same "flavour".<br>
<br></div><div class=3D"gmail_extra">Interestingly, in any functional langu=
age like, say Haskell, the 'obvious' answer would be for operator&l=
t;() to return optional<bool>.=A0 ie you 'lift' all the opera=
tions up to the new level by applying optional<> to everything.=A0 No=
t sure if we will see diverging from that as a mistake in 10 years as funct=
ional style grows.=A0 If so, we can always introduce a maybe<> class.=
...<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div=
class=3D"gmail_extra">Tony<br></div><div class=3D"gmail_extra"><br></div><=
/font></span></div></blockquote><div><br></div><div>Also, the number 1 reas=
on for adding operator<() was to allow optionals to be used in standard =
containers and algorithms (sorted or as keys, etc).<br>
</div><div>As it turns out, this is better done via specializing std::less,=
but having operator<() diverge from std::less is always a bit confusing=
as well.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c355b274273704f3511155--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 26 Feb 2014 10:48:42 -0500
Raw View
--001a1134624ca238cd04f35123bb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 26, 2014 at 10:43 AM, Thiago Macieira <thiago@macieira.org>wrot=
e:
> Em qua 26 fev 2014, =E0s 10:35:57, Tony V E escreveu:
> > Interestingly, in any functional language like, say Haskell, the
> 'obvious'
> > answer would be for operator<() to return optional<bool>. ie you 'lift=
'
> > all the operations up to the new level by applying optional<> to
> > everything. Not sure if we will see diverging from that as a mistake i=
n
> 10
> > years as functional style grows. If so, we can always introduce a
> maybe<>
> > class...
>
> How would maybe and optional differ?
>
Well, I guess it would return optional<bool> from operator<(). And fix any
other issues we might find in hindsight. Basically I'm just saying that if
it turns out that we made fundamental mistakes with optional, we can always
make another class (and it would probably be easier than fixing an existing
class). And that in functional languages it is often called Maybe, so the
name is already there waiting for us.
Or you still have ~3 years to argue that optional should be "fixed" before
full standardization. That _is_ what a TS is for, after all. If we _knew_
it was perfect, it would be in C++14. We know it is 'good', but not 100%
sure about the edges.
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1134624ca238cd04f35123bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Feb 26, 2014 at 10:43 AM, Thiago Macieira <span dir=3D"ltr"=
><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maciei=
ra.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em qua 26 fev 2014, =E0s 10:35:57, Tony V E =
escreveu:<br>
<div class=3D"">> Interestingly, in any functional language like, say Ha=
skell, the 'obvious'<br>
> answer would be for operator<() to return optional<bool>. =A0=
ie you 'lift'<br>
> all the operations up to the new level by applying optional<> to=
<br>
> everything. =A0Not sure if we will see diverging from that as a mistak=
e in 10<br>
> years as functional style grows. =A0If so, we can always introduce a m=
aybe<><br>
> class...<br>
<br>
</div>How would maybe and optional differ?<br></blockquote><div><br></div><=
/div>Well, I guess it would return optional<bool> from operator<()=
..=A0 And fix any other issues we might find in hindsight.=A0 Basically I=
9;m just saying that if it turns out that we made fundamental mistakes with=
optional, we can always make another class (and it would probably be easie=
r than fixing an existing class).=A0 And that in functional languages it is=
often called Maybe, so the name is already there waiting for us.<br>
<br></div><div class=3D"gmail_extra">Or you still have ~3 years to argue th=
at optional should be "fixed" before full standardization.=A0 Tha=
t _is_ what a TS is for, after all.=A0 If we _knew_ it was perfect, it woul=
d be in C++14.=A0 We know it is 'good', but not 100% sure about the=
edges.<br>
<br></div><div class=3D"gmail_extra">Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134624ca238cd04f35123bb--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 27 Feb 2014 10:18:36 -0800 (PST)
Raw View
------=_Part_6039_18580695.1393525116405
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 26, 2014 7:01:58 AM UTC+1, Ville Voutilainen wrote:
>
> On 26 February 2014 01:09, Bjorn Reese <bre...@mail1.stofanet.dk<javascript:>>
> wrote:
> > On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
> >
> >> We had some disagreement on how to define such relational operators,
> >> especially
> >> for optional. Currently optional's operator>= does the opposite of
> >> operator<, and
> >> the insinuations to do something else are mere crazy talk. ;)
> >
> >
> > Was three-valued logic considered during the discussions?
>
>
> I think it was mentioned that optional<bool> has some similarities
> to boost::tribool, while not quite achieving the convenience nor the
> exact semantics. Other than that, no, I don't think so. I suppose
> it would be interesting to make the relational operators of optional
> to return optional<bool>, but I do not expect to go there.
>
I think it's the only right thing to do. Either that or not providing the
operators at all.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6039_18580695.1393525116405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 26, 2014 7:01:58 AM UTC+1, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 26 February=
2014 01:09, Bjorn Reese <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"-dTlFGGXuu4J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">bre...@ma=
il1.stofanet.dk</a>> wrote:
<br>> On 02/25/2014 09:39 PM, Ville Voutilainen wrote:
<br>>
<br>>> We had some disagreement on how to define such relational oper=
ators,
<br>>> especially
<br>>> for optional. Currently optional's operator>=3D does the op=
posite of
<br>>> operator<, and
<br>>> the insinuations to do something else are mere crazy talk. ;)
<br>>
<br>>
<br>> Was three-valued logic considered during the discussions?
<br>
<br>
<br>I think it was mentioned that optional<bool> has some similaritie=
s
<br>to boost::tribool, while not quite achieving the convenience nor the
<br>exact semantics. Other than that, no, I don't think so. I suppose
<br>it would be interesting to make the relational operators of optional
<br>to return optional<bool>, but I do not expect to go there.
<br></blockquote><div><br></div><div>I think it's the only right thing to d=
o. Either that or not providing the operators at all. </div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6039_18580695.1393525116405--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 27 Feb 2014 21:17:19 +0200
Raw View
On 27 February 2014 20:18, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Wednesday, February 26, 2014 7:01:58 AM UTC+1, Ville Voutilainen wrote:
>> exact semantics. Other than that, no, I don't think so. I suppose
>> it would be interesting to make the relational operators of optional
>> to return optional<bool>, but I do not expect to go there.
>
>
> I think it's the only right thing to do. Either that or not providing the
> operators at all.
I don't think either of those options is going to happen.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: j.dufraigne@gmail.com
Date: Thu, 11 Sep 2014 16:59:37 -0700 (PDT)
Raw View
------=_Part_229_1105674287.1410479977348
Content-Type: multipart/alternative;
boundary="----=_Part_230_891744118.1410479977348"
------=_Part_230_891744118.1410479977348
Content-Type: text/plain; charset=UTF-8
Hi Oleg,
I see this thread is quite old, but i do not know where to comment on
N4126, I hope this will reach you.
I really like your proposal.
One of the issue that exists in C++ is that an operator defined for a base
class will be used for derived class of different types.
The problematic code that compile and run:
--
struct Base { int value = 0; /* default: ==; */ };
struct DerivedA : public Base { int derivedValueA = 0; };
struct DerivedB : public Base { int derivedValueB = 0; };
// Usual operator that would be probably be generated with N4126
bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
int main(int argc, char* argv[])
{
DerivedA a; a.derivedValueA = 1;
DerivedB b; b.derivedValueB = 2;
// This ideally should fail compilation. Here Bases are compared and return
true
if (a == b) { return 1; }
return 0;
}
--
It does not seem that allowing all the conversions is helpful. Should we
try to disable them for the generated operators?
Something like the following seem to do the job, but I guess there are
better ways and things I missed.
Possible solution 1 generate:
--
bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
template< typename T > bool operator==(const Base& a, const T& b) = delete;
template< typename T > bool operator==(const T& a, const Base& b) = delete;
--
Possible solution 2 generate:
--
bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
template< typename T, typename U >
typename std::enable_if<
std::is_base_of<Base, T>::value || std::is_base_of<Base, U>::value,
bool
>::type operator==(const T& a, const U& b) = delete; // or static_assert
--
Best Regards,
Jean-Philippe.
On Friday, December 27, 2013 2:29:37 AM UTC, Oleg Smolsky wrote:
>
> Hi all, I've written up the discussion into a paper, attempted to
> provide the minimal standardese and implemented a prototype in Clang. The
> draft is attached and I had asked Alisdair Meredith for a proposal number.
>
> I realize that operator!=(), operator>=(), operator>() and operator<=()
> are contentious as people may choose to derive them in weird ways... So,
> I'll treat them as secondary goals. The primary points are about generating
>
> bool operator==(const Thing &) const = default; // 1a
> bool operator<(const Thing &) const = default; // 1b
>
> Oleg.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_230_891744118.1410479977348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Oleg,</div><div><br></div><div>I see this thread i=
s quite old, but i do not know where to comment on N4126, I hope this will =
reach you.</div><div>I really like your proposal.</div><div><br></div><div>=
One of the issue that exists in C++ is that an operator defined for a base =
class will be used for derived class of different types.</div><div>The prob=
lematic code that compile and run:</div><div><br></div><div>--</div><div>st=
ruct Base { int value =3D 0; /* default: =3D=3D; */ };</div><div>struct Der=
ivedA : public Base { int derivedValueA =3D 0; };</div><div>struct DerivedB=
: public Base { int derivedValueB =3D 0; };</div><div><br></div><div>// Us=
ual operator that would be probably be generated with N4126</div><div>bool =
operator=3D=3D(const Base& a, const Base& b) { return a.value =3D=
=3D b.value; }</div><div><br></div><div>int main(int argc, char* argv[])</d=
iv><div>{</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>DerivedA a; a.derivedValueA =3D 1;</div><div><span class=3D"Apple=
-tab-span" style=3D"white-space:pre"> </span>DerivedB b; b.derivedValueB =
=3D 2;</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre"> </span>// This ideally should fail compilation. Here Bases a=
re compared and return true</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>if (a =3D=3D b) { return 1; }</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return 0;</div><=
div>}</div><div>--</div><div><br></div><div>It does not seem that allowing =
all the conversions is helpful. Should we try to disable them for the gener=
ated operators?</div><div>Something like the following seem to do the job, =
but I guess there are better ways and things I missed.</div><div><br></div>=
<div>Possible solution 1 generate:</div><div>--</div><div>bool operator=3D=
=3D(const Base& a, const Base& b) { return a.value =3D=3D b.value; =
}</div><div>template< typename T > bool operator=3D=3D(const Base&=
; a, const T& b) =3D delete;</div><div>template< typename T > boo=
l operator=3D=3D(const T& a, const Base& b) =3D delete;</div><div>-=
-</div><div><br></div><div>Possible solution 2 generate:</div><div>--</div>=
<div>bool operator=3D=3D(const Base& a, const Base& b) { return a.v=
alue =3D=3D b.value; }</div><div>template< typename T, typename U ></=
div><div>typename std::enable_if<</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre"> </span>std::is_base_of<Base, T>::value =
|| std::is_base_of<Base, U>::value,</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>bool</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre"> </span>>::type operator=3D=3D(co=
nst T& a, const U& b) =3D delete; // or static_assert</div><div>--<=
/div><div><br></div><div>Best Regards,</div><div>Jean-Philippe.</div><br>On=
Friday, December 27, 2013 2:29:37 AM UTC, Oleg Smolsky wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font face=3D"Calibri">Hi all, I've written up the discussion into a
paper, attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached and I had
asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), </font><font face=3D"Calibri"><font fa=
ce=3D"Calibri">operator>=3D(), </font></font><font face=3D"Calibri"><fon=
t face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font face=
=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri">operator>() a=
nd </font></font></font></font></font></font></font><font face=3D"Calibri">=
<font face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font =
face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri"><font face=
=3D"Calibri"><font face=3D"Calibri">operator<=3D()</font></font></font><=
/font></font></font></font>
are contentious as people may choose to derive them in weird
ways... So, I'll treat them as secondary goals. The primary
points are about generating </font></font><br>
<pre> bool operator=3D=3D(const Thing &) const =3D defau=
lt; // 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b</pre>
<font face=3D"Calibri">Oleg.<br>
</font>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_230_891744118.1410479977348--
------=_Part_229_1105674287.1410479977348
Content-Type: text/x-c++src; charset=US-ASCII; name=main.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=main.cpp
X-Attachment-Id: 8b86aea1-bb3f-4c47-b12d-ab1151824966
Content-ID: <8b86aea1-bb3f-4c47-b12d-ab1151824966>
struct Base { int value = 0; /* default: ==; */ };
struct DerivedA : public Base { int derivedValueA = 0; };
struct DerivedB : public Base { int derivedValueB = 0; };
// Usual operator that would be probably be generated with N4126
bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
int main(int argc, char* argv[])
{
DerivedA a; a.derivedValueA = 1;
DerivedB b; b.derivedValueB = 2;
// This ideally should fail compilation. Here Bases are compared and return true
if (a == b) { return 1; }
return 0;
}
//// solution 1:
//bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
//template< typename T > bool operator==(const Base& a, const T& b) = delete;
//template< typename T > bool operator==(const T& a, const Base& b) = delete;
//
//// solution 2:
//#include <type_traits>
//bool operator==(const Base& a, const Base& b) { return a.value == b.value; }
//template< typename T, typename U >
//typename std::enable_if<
// std::is_base_of<Base, T>::value || std::is_base_of<Base, U>::value,
// bool
// >::type operator==(const T& a, const U& b) = delete; // or static_assert
------=_Part_229_1105674287.1410479977348--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Thu, 11 Sep 2014 17:02:11 -0700
Raw View
This is a multi-part message in MIME format.
--------------000809020807060801010506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello Jean-Philippe, the latest paper is available here:
https://isocpp.org/files/papers/n4126.htm
On 2014-09-11 16:59, j.dufraigne@gmail.com wrote:
> Hi Oleg,
>
> I see this thread is quite old, but i do not know where to comment on
> N4126, I hope this will reach you.
> I really like your proposal.
>
> One of the issue that exists in C++ is that an operator defined for a
> base class will be used for derived class of different types.
> The problematic code that compile and run:
>
> --
> struct Base { int value = 0; /* default: ==; */ };
> struct DerivedA : public Base { int derivedValueA = 0; };
> struct DerivedB : public Base { int derivedValueB = 0; };
>
> // Usual operator that would be probably be generated with N4126
> bool operator==(const Base& a, const Base& b) { return a.value ==
> b.value; }
>
> int main(int argc, char* argv[])
> {
> DerivedA a; a.derivedValueA = 1;
> DerivedB b; b.derivedValueB = 2;
>
> // This ideally should fail compilation. Here Bases are compared and
> return true
> if (a == b) { return 1; }
> return 0;
> }
> --
>
> It does not seem that allowing all the conversions is helpful. Should
> we try to disable them for the generated operators?
> Something like the following seem to do the job, but I guess there are
> better ways and things I missed.
>
> Possible solution 1 generate:
> --
> bool operator==(const Base& a, const Base& b) { return a.value ==
> b.value; }
> template< typename T > bool operator==(const Base& a, const T& b) =
> delete;
> template< typename T > bool operator==(const T& a, const Base& b) =
> delete;
> --
>
> Possible solution 2 generate:
> --
> bool operator==(const Base& a, const Base& b) { return a.value ==
> b.value; }
> template< typename T, typename U >
> typename std::enable_if<
> std::is_base_of<Base, T>::value || std::is_base_of<Base, U>::value,
> bool
> >::type operator==(const T& a, const U& b) = delete; // or static_assert
> --
>
> Best Regards,
> Jean-Philippe.
>
> On Friday, December 27, 2013 2:29:37 AM UTC, Oleg Smolsky wrote:
>
> Hi all, I've written up the discussion into a paper, attempted to
> provide the minimal standardese and implemented a prototype in
> Clang. The draft is attached and I had asked Alisdair Meredith for
> a proposal number.
>
> I realize that operator!=(), operator>=(), operator>() and
> operator<=() are contentious as people may choose to derive them
> in weird ways... So, I'll treat them as secondary goals. The
> primary points are about generating
>
> bool operator==(const Thing &) const = default; // 1a
> bool operator<(const Thing &) const = default; // 1b
>
> Oleg.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------000809020807060801010506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Hello Jean-Philippe, the latest paper
is available here:<br>
=A0=A0=A0 <a class=3D"moz-txt-link-freetext" href=3D"https://isocpp.o=
rg/files/papers/n4126.htm">https://isocpp.org/files/papers/n4126.htm</a><br=
>
On 2014-09-11 16:59, <a class=3D"moz-txt-link-abbreviated" href=3D"ma=
ilto:j.dufraigne@gmail.com">j.dufraigne@gmail.com</a> wrote:<br>
</div>
<blockquote
cite=3D"mid:49a4dd4c-0351-46c5-b69a-cbeeb26e1602@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>Hi Oleg,</div>
<div><br>
</div>
<div>I see this thread is quite old, but i do not know where to
comment on N4126, I hope this will reach you.</div>
<div>I really like your proposal.</div>
<div><br>
</div>
<div>One of the issue that exists in C++ is that an operator
defined for a base class will be used for derived class of
different types.</div>
<div>The problematic code that compile and run:</div>
<div><br>
</div>
<div>--</div>
<div>struct Base { int value =3D 0; /* default: =3D=3D; */ };</div>
<div>struct DerivedA : public Base { int derivedValueA =3D 0; };</d=
iv>
<div>struct DerivedB : public Base { int derivedValueB =3D 0; };</d=
iv>
<div><br>
</div>
<div>// Usual operator that would be probably be generated with
N4126</div>
<div>bool operator=3D=3D(const Base& a, const Base& b) {
return a.value =3D=3D b.value; }</div>
<div><br>
</div>
<div>int main(int argc, char* argv[])</div>
<div>{</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>DerivedA
a; a.derivedValueA =3D 1;</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>DerivedB
b; b.derivedValueB =3D 2;</div>
<div><br>
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>//
This ideally should fail compilation. Here Bases are compared
and return true</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>if
(a =3D=3D b) { return 1; }</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>return
0;</div>
<div>}</div>
<div>--</div>
<div><br>
</div>
<div>It does not seem that allowing all the conversions is
helpful. Should we try to disable them for the generated
operators?</div>
<div>Something like the following seem to do the job, but I
guess there are better ways and things I missed.</div>
<div><br>
</div>
<div>Possible solution 1 generate:</div>
<div>--</div>
<div>bool operator=3D=3D(const Base& a, const Base& b) {
return a.value =3D=3D b.value; }</div>
<div>template< typename T > bool operator=3D=3D(const
Base& a, const T& b) =3D delete;</div>
<div>template< typename T > bool operator=3D=3D(const T&
a, const Base& b) =3D delete;</div>
<div>--</div>
<div><br>
</div>
<div>Possible solution 2 generate:</div>
<div>--</div>
<div>bool operator=3D=3D(const Base& a, const Base& b) {
return a.value =3D=3D b.value; }</div>
<div>template< typename T, typename U ></div>
<div>typename std::enable_if<</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>std::is_base_of<Base,
T>::value || std::is_base_of<Base, U>::value,</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>bool</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>>::type
operator=3D=3D(const T& a, const U& b) =3D delete; // or
static_assert</div>
<div>--</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Jean-Philippe.</div>
<br>
On Friday, December 27, 2013 2:29:37 AM UTC, Oleg Smolsky wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <font face=3D"Calibri"=
>Hi
all, I've written up the discussion into a paper,
attempted to provide the minimal standardese and
implemented a prototype in Clang. The draft is attached
and I had asked Alisdair Meredith for a proposal number.<br>
<br>
I realize that operator!=3D(), </font><font face=3D"Calibri">=
<font
face=3D"Calibri">operator>=3D(), </font></font><font
face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri=
"><font
face=3D"Calibri"><font face=3D"Calibri"><font
face=3D"Calibri"><font face=3D"Calibri">operator>=
;()
and </font></font></font></font></font></font></f=
ont><font
face=3D"Calibri"><font face=3D"Calibri"><font face=3D"Calibri=
"><font
face=3D"Calibri"><font face=3D"Calibri"><font
face=3D"Calibri"><font face=3D"Calibri"><font
face=3D"Calibri"><font face=3D"Calibri">operato=
r<=3D()</font></font></font></font></font></font></font>
are contentious as people may choose to derive them in
weird ways... So, I'll treat them as secondary goals.
The primary points are about generating </font></font><br>
<pre> bool operator=3D=3D(const Thing &) const =
=3D default; // 1a
bool operator<(const Thing &) const =3D default; /=
/ 1b</pre>
<font face=3D"Calibri">Oleg.<br>
</font> </div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000809020807060801010506--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 12 Sep 2014 06:41:18 -0700 (PDT)
Raw View
------=_Part_26_865805144.1410529278939
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 23 lutego 2014 08:11:20 UTC+1 u=C5=BCytkownik Oleg Smolsk=
y=20
napisa=C5=82:
>
> Here is the first official draft: N3950: Defaulted comparison operators.
>
> Hi Oleg,
I was looking at the standardese in the revision of the paper:=20
http://isocpp.org/files/papers/n4126.htm.
It looks like the new section 12.10 defines the order in which comparisons=
=20
are performed, when the comparison stops, but it doesn't say what value=20
should be returned. We all know what it should return, but just for=20
completeness' sake it is worth adding a sentence saying that "the function=
=20
returns false if and only if at least one of the performed comparisons=20
returns false". Also it looks like 12.10 should make a requirement that the=
=20
operators=3D=3D in members and sub classes should return a value convertibl=
e to=20
bool: we do not want to generate our operator=3D=3D if our members use over=
load=20
their operator=3D=3D for malicious purposes.
Regards,
&rzej=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_26_865805144.1410529278939
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu niedziela, 23 lutego 2014 08:11:20 UTC+1 u=
=C5=BCytkownik Oleg Smolsky napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">Here is the first official draft: N3950: Defaul=
ted comparison operators.<br><br></div></blockquote><div>Hi Oleg,<br>I was =
looking at the standardese in the revision of the paper: http://isocpp.org/=
files/papers/n4126.htm.<br>It looks like the new section 12.10 defines the =
order in which comparisons are performed, when the comparison stops, but it=
doesn't say what value should be returned. We all know what it should retu=
rn, but just for completeness' sake it is worth adding a sentence saying th=
at "the function returns false if and only if at least one of the performed=
comparisons returns false". Also it looks like 12.10 should make a require=
ment that the operators=3D=3D in members and sub classes should return a va=
lue convertible to bool: we do not want to generate our operator=3D=3D if o=
ur members use overload their operator=3D=3D for malicious purposes.<br><br=
>Regards,<br>&rzej <br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_26_865805144.1410529278939--
.
Author: Oleg Smolsky <oleg@smolsky.net>
Date: Fri, 12 Sep 2014 07:33:20 -0700
Raw View
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 2014-09-12 06:41, Andrzej
Krzemie=C5=84ski wrote:<br>
</div>
<blockquote
cite=3D"mid:a62e6d35-7d03-424a-913b-7e1e8d452d81@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
W dniu niedziela, 23 lutego 2014 08:11:20 UTC+1 u=C5=BCytkownik Ole=
g
Smolsky napisa=C5=82:
<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">Here is the first official draft: N3950:
Defaulted comparison operators.<br>
<br>
</div>
</blockquote>
<div>Hi Oleg,<br>
I was looking at the standardese in the revision of the paper:
<a class=3D"moz-txt-link-freetext" href=3D"http://isocpp.org/file=
s/papers/n4126.htm">http://isocpp.org/files/papers/n4126.htm</a>.<br>
It looks like the new section 12.10 defines the order in which
comparisons are performed, when the comparison stops, but it
doesn't say what value should be returned. We all know what it
should return, but just for completeness' sake it is worth
adding a sentence saying that "the function returns false if
and only if at least one of the performed comparisons returns
false". Also it looks like 12.10 should make a requirement
that the operators=3D=3D in members and sub classes should return
a value convertible to bool: we do not want to generate our
operator=3D=3D if our members use overload their operator=3D=3D f=
or
malicious purposes.<br>
</div>
</div>
</blockquote>
Right, thanks for the tips, Andrzej! I'll revise/clarify these
definitions for the next revision.<br>
<br>
Oleg.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
.