<html>
<head>
<title>Implicit Conversion Operators for Atomics</title>
</head>
<body>
<h1>Implicit Conversion Operators for Atomics</h1>


<p> ISO/IEC JTC1 SC22 WG21 N2514 = 08-0024 - 2008-02-01

<p> Lawrence Crowl, crowl@google.com, Lawrence@Crowl.org

<h2>Introduction</h2>

<p>
The early proposals for atomics,
culminating in
<a href="../../papers/2007/n2324.html">N2324</a>,
provided for implicit conversions from an atomic type
to the corresponding base type
as a more syntactically concise method
for specifying the load operation.
</p>

<p>
Because of the problems with implicit conversions,
the library subcommittee directed their removal from the atomics proposal,
which was reflected in
<a href="../../papers/2007/n2324.html">N2324</a>
and that paper's final version,
<a href="../../papers/2007/n2427.html">N2427</a>,
and is reflected in the current working draft standard,
<a href="../../papers/2007/n2461.pdf">N2461</a>.
</p>

<p>
However, there is substantial support among members of the committee
to reverse that decision and add implicit conversions back into atomics.
This paper clarifies the issues
and provides normative wording for such a change.
</p>

<h2>Issue Discussion</h2>

<p>
Within this discussion,
implict conversion operators yielding
the base type of an atomic type
will be called implicit loads.
Calling one of load functions
will be called an explicit load.
<p>

<h3>Ambiguity and Insecurity</h3>

<p>
The general use of implicit conversions
has caused significant ambiguities and insecurities in working code.
Such problems are described in
<a href="../../papers/2004/n1592.pdf">N1952</a>
and its successors,
most recently
<a href="../../papers/2007/n2437.pdf">N2437</a>.
However, a common feature of these problems
is that the conversion returns an attribute of the object.
As examples,
string_type<code>::operator const char*</code>
returns a representation address
and 
smart_pointer<code>::operator bool</code>
returns the result of a test for null.
</p>

<p>
In contrast,
the implicit load
defined in 
<a href="../../papers/2007/n2324.html">N2324</a>
returns an alternate representation of the atomic's abstract value.
Indeed,
as the atomic types have deleted copy constructors
and no other operations returning atomics,
there is no other representation of the abstract value of the atomic.
</p>

<p>
Furthermore, as the atomic types have deleted copy constructors,
user-defined functions cannot have them as parameters or return types.
Thus, there can be no additional potential ambiguity
in calls to such functions
with arguments formed from explicit loads.
</p>

<p>
In summary, atomic objects are only lvalues, never rvalues.
So, while use of implicit conversion operators
should usually be viewed with suspicion,
the proposed use in atomics introduces no problems.
</p>

<h3>Implicit Load Hides Cost</h3>

<p>
Implicit load makes the cost of an atomic load
essentially invisible in the source.
As atomic loads can be expensive,
the invisibility of the cost
can thus lead programmers to write code
that is significantly more expensive than necessary.
</p>

<p>
The situation is similar for the assignment operator,
which allows minimal, but not invisible,
syntax for an atomic store operation.
</p>

<h3>Implicit Load Encourages Errors</h3>

<p>
Related to the hidden cost of implicit load,
is the hidden semantic implications
of reading an atomic variable more than once.
Algorithms using atomic variables
are much more likely to be correct
if they read the variables only once.
The additional syntactic burden of writing
an explicit load
both encourages minimizing the number of loads
and makes multiple loads on the same variable more obvious.
</p>

<p>
The situation is less problematic for the assignment operator,
as programmers are less likely to perform multiple assignments
and as the operation has some explicit syntax.
</p>

<h3>Implicit Load Aids Presentations</h3>

<p>
In many contexts where code is presented,
physical space is at a premium and
non-essential details are unwelcome.
In such contexts,
presenters will be tempted to write implicit loads
even if the language does not provide them.
Such code will be syntactically incorrect,
thus inhibiting compilation of examples
and inhibiting the conversion of examples into working code.
</p>

<h3>Implicit Load Encourages SC-Focused Presentations</h3>

<p>
Presentations, articles, and papers
will likely assume or require sequentially-consistent operations,
which are often stronger than algorithms require.
The consequences are that
presented algorithms are more understandable
but less efficient.
This tradeoff manifests itself
in both published papers on lock-free algorithms
and on the adoption of those algorithms in real-world environments.
</p>

<p>
This SC focus is already present
in the overloaded assignment and increment operators for atomics.
The concern is the additional degree of focus.
</p>

<h3>Other Languages Have Implicit Load</h3>

<p>
Other programming languages,
notably Java and C#,
have implicit load.
As a result, C++ programs without implicit load
will look clumsier than other languages.
</p>

<h2>Proposed Wording</h2>

<p>
The following changes add implicit load
to the atomics library.
</p>

<h3>29.4.1 (tentative) Integral Types [atomics.types.integral (tentative)]</h3>

<p>
To <code>struct atomic_bool</code>, add member:
</p>

<blockquote>
<pre><code>
operator bool() const volatile;
</code></pre>
</blockquote>

<p>
To <code>struct atomic_<var>itype</var></code>, add member:
</p>

<blockquote>
<pre><code>
operator <var>integral</var>() const volatile;
</code></pre>
</blockquote>

<h3>29.4.2 (tentative) Address Type [atomics.types.address (tentative)]</h3>

<p>
To <code>struct atomic_address</code>, add member:
</p>

<blockquote>
<pre><code>
operator void*() const volatile;
</code></pre>
</blockquote>

<h3>29.4.3 (tentative) Generic Types [atomics.types.generic (tentative)]</h3>

<p>
To template <code>struct atomic</code>, add member:
</p>

<blockquote>
<pre><code>
operator T() const volatile;
</code></pre>
</blockquote>

<p>
To template <code>struct atomic&lt;<var>integral</var>&gt;</code>
specializations, add member:
</p>

<blockquote>
<pre><code>
operator <var>integral</var>() const volatile;
</code></pre>
</blockquote>

<p>
To template <code>struct atomic&lt;T*&gt;</code>
specializations, add member:
</p>

<blockquote>
<pre><code>
operator <var>T*</var>() const volatile;
</code></pre>
</blockquote>

<h3>29.4.4 (tentative) Operations [atomics.types.operatons (tentative)]</h3>

<p>
After paragraph 11,
add the following specification.
</p>

<blockquote>
<pre><code>
<var>A</var>::operator <var>C</var>() const volatile;
</code></pre>

<blockquote>
<p>
<i>Effects:</i>
<code>load()</code>
</p>

<p>
<i>Returns:</i>
The result of <code>load()</code>.
</p>
</blockquote>
</blockquote>

</body>
</html>
