This is a multi-part message in MIME format.
--------------040001000104070806050709
Content-Type: text/plain; charset=UTF-8

This came up in Vicente's recent thread on N4560. Since it seems like an
obvious and good idea, and received some initial positive feedback, I
wrote a quick paper.

The short form is: A function definition whose return type is given as
'auto', which does not specify a trailing return type, and which was
previously declared with a known return type, shall use the return type
from the declaration.

Example:

  // foo.h
  struct { int id; double value; } foo();

  // foo.cpp
  auto foo()
  {
    ...
    return { id, value };
  }

Initial copies attached. Online version at:
https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-type/PXXXX%20Implicit%20Return%20Type.rst
(As with my previous draft paper, updates posted here will be sporadic
at best. Use the github link to always access the current version.)

Please let me know what you think.

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------040001000104070806050709
Content-Type: text/prs.fallenstein.rst;
 name="PXXXX Implicit Return Type.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.rst"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Implicit Return Type
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
~~~~~~~~~~~~~~~~~~~
 December 30, 2015
~~~~~~~~~~~~~~~~~~~

=2E. raw:: html

  <style>
    html { color: black; background: white; }
  </style>

=2E. role:: cpp(code)
   :language: c++


Abstract
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal recommends an enhancement to return type deduction to allow=
 the return type of a function definition to be inferred from a previous =
declaration of the same.

=2E. contents::


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

The concept of multiple return values is well known. At present, however,=
 C++ lacks a good mechanism for implementing the same. ``std::tuple`` is =
considered clunky by many and, critically, creates sub-optimal API by vir=
tue of the returned values being unnamed, forcing developers to rely on s=
upplemental documentation to explain their purpose. Aggregates represent =
an improvement, being self-documenting, but the need to provide external =
definitions of the same is awkward and, worse, pollutes their correspondi=
ng namespace with entities that may be single use. Proposals such as N456=
0_ present a complicated mechanism for providing tagged (self-documenting=
) tuple-like types, which may be necessary in some cases, but still repre=
sent a non-trivial amount of complexity that ideally should not be requir=
ed.

Proposals such as P0144_ (or its competitor P0151_) in particular would r=
epresent a significant step toward support of multiple return values as f=
irst class citizens. These proposals and other current directions show an=
 encouraging movement away from the traditional ``std::pair`` and ``std::=
tuple`` towards comparable concepts without requiring the explicit types.=
 (We expect, however, that these will remain useful for algorithms where =
the identity of the elements is unimportant, while it *is* important to b=
e able to name at least the outer, if not complete, type. In that respect=
, we hypothesize that we may in the future see the ability to construct a=
 ``std::tuple`` from any tuple-like.) On their own, however, these propos=
als risk exacerbating the problem that this proposal aims to address.

It has been suggested on multiple occasions that the optimal solution to =
the above issues is to return an anonymous ``struct``. This solves the pr=
oblems of clutter and self-documentation, but runs afoul of a much worse =
issue; because the ``struct`` is *anonymous*, it can be difficult to impo=
ssible to give its name a second time in order to separate the declaratio=
n and definition of the function that wishes to use it.

However, in C++, functions cannot be overloaded by their return value. Th=
is leads to an obvious question: **why is it necessary to repeat the retu=
rn value at all?**

Even in the case of return types that can be named, it may be that repeat=
ing the type name is excessively verbose or otherwise undesirable. Some m=
ight even call this a violation of the `Don't Repeat Yourself <https://en=
=2Ewikipedia.org/wiki/Don't_repeat_yourself>`_ principle, similar to some=
 of the issues that ``auto`` for variable declaration was introduced to s=
olve. (On the flip side, one could see the ability to elide the return ty=
pe as subject to many abuses, again in much the manner of ``auto``. Howev=
er, many language features can be abused; this should not prevent the add=
ition of a feature that would provide an important benefit when used corr=
ectly.)

We would be remiss not to note that this is already possible in simple ca=
ses using ``decltype`` and a sample invocation of the function. However, =
while this may be adequate in simple cases, it is nevertheless needlessly=
 verbose, and as the argument list grows longer, and/or gains arguments f=
or which providing a legal value is non-trivial, it can quickly become un=
wieldy and unfeasible.


Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

Recent changes to the language have progressively relaxed the requirement=
s for how return types are specified. We began with trailing return type =
specification, and have progressed to inferred return types in certain ca=
ses.

This proposal is to continue this direction by adding an additional use o=
f ``auto`` as a return specifier, meaning "use the return type seen when =
this function was previously declared". This provides an optimal solution=
 to the following problem:

=2E. code:: c++

  // foo.h
  struct { int id; double value; } foo();

How does one now provide an external definition for ``foo()``? We propose=
:

=2E. code:: c++

  // foo.cpp
  auto foo()
  {
    ...
    return { id, value };
  }

The use of ``auto`` as the return type specifier, with no trailing return=
 type, and for a function that has been previously declared with a known =
return type, shall instruct the compiler to define the function using the=
 return type from the previous declaration. (Note that this works for *an=
y* type, not just anonymous ``struct``\ s.)

Naturally, "previous declaration" here means a declaration having the sam=
e name and argument list. This, for example, would remain illegal:

=2E. code:: c++

  struct { int id; int value; } foo(int);
  struct { int id; float value; } foo(float);

  auto foo(double input) // does not match any previous declaration
  {
    ...
    return { id, result };
  }

Additionally, and for obvious reasons, we propose to remove the prohibiti=
on ([dcl.fct]/11) against defining types in return type specifications. W=
e additionally note that this prohibition is already not enforced by at l=
east one major compiler (GCC). We further believe this prohibition to be =
outdated; it made sense in C++98, but with recent changes such as the add=
ition of ``decltype`` and the ability to omit the type name in a ``return=
`` statement returning an in-place constructed class, the reasons for the=
 prohibition have been greatly mitigated. This other part of this proposa=
l would largely remove any remaining motivation for the prohibition.


Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

An obvious follow-on question is, should we also lift the prohibition aga=
inst types defined in parameter specifications? There have been suggestio=
ns floated to implement the much requested named parameters in something =
like this manner. However, there are significant (in our opinion) reasons=
 to not address this, at least initially. First, it is widely contested t=
hat this is not an optimal solution to the problem (named parameters) in =
the first place. Second, it depends on named initializers, which is an ar=
ea of ongoing work. Third, this proposal works largely because C++ forbid=
s overloading on return type, which may be leveraged to eliminate any amb=
iguity as to the deduction of the actual type of ``auto``; this is not th=
e case for parameters, and so permitting ``auto`` as a parameter type spe=
cifier would quickly run into issues that can be avoided for the return t=
ype case.

While we do not wish to categorically rule out future changes in this dir=
ection, we feel that it is not appropriate for this proposal to attempt t=
o address these issues.

On a related note, it is not strictly necessary for the sake of the added=
 utility of implied return type to relax [dcl.fct]/11. However, much of t=
he benefit is lost with this prohibition in place. Conversely, simply rel=
axing the prohibition is of significantly less benefit without the propos=
ed implied return type feature. Accordingly, while we considered splittin=
g the two changes into separate proposals, we have decided for now to kee=
p them together.


=2E. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..=
 .. ..

=2E. _N4560: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
0.pdf
=2E. _P0144: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p014=
4r0.pdf
=2E. _P0151: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p015=
1r0.pdf

=2E. |--| unicode:: U+02014 .. em dash

--------------040001000104070806050709
Content-Type: text/html; charset=UTF-8;
 name="PXXXX Implicit Return Type.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.html"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiID8+CjwhRE9DVFlQRSBodG1s
IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRw
Oi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4K
PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJl
biIgbGFuZz0iZW4iPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+CjxtZXRhIG5hbWU9ImdlbmVy
YXRvciIgY29udGVudD0iRG9jdXRpbHMgMC4xMTogaHR0cDovL2RvY3V0aWxzLnNvdXJjZWZv
cmdlLm5ldC8iIC8+Cjx0aXRsZT5JbXBsaWNpdCBSZXR1cm4gVHlwZTwvdGl0bGU+CjxzdHls
ZSB0eXBlPSJ0ZXh0L2NzcyI+CgovKgo6QXV0aG9yOiBEYXZpZCBHb29kZ2VyIChnb29kZ2Vy
QHB5dGhvbi5vcmcpCjpJZDogJElkOiBodG1sNGNzczEuY3NzIDc2MTQgMjAxMy0wMi0yMSAx
NTo1NTo1MVogbWlsZGUgJAo6Q29weXJpZ2h0OiBUaGlzIHN0eWxlc2hlZXQgaGFzIGJlZW4g
cGxhY2VkIGluIHRoZSBwdWJsaWMgZG9tYWluLgoKRGVmYXVsdCBjYXNjYWRpbmcgc3R5bGUg
c2hlZXQgZm9yIHRoZSBIVE1MIG91dHB1dCBvZiBEb2N1dGlscy4KClNlZSBodHRwOi8vZG9j
dXRpbHMuc2YubmV0L2RvY3MvaG93dG8vaHRtbC1zdHlsZXNoZWV0cy5odG1sIGZvciBob3cg
dG8KY3VzdG9taXplIHRoaXMgc3R5bGUgc2hlZXQuCiovCgovKiB1c2VkIHRvIHJlbW92ZSBi
b3JkZXJzIGZyb20gdGFibGVzIGFuZCBpbWFnZXMgKi8KLmJvcmRlcmxlc3MsIHRhYmxlLmJv
cmRlcmxlc3MgdGQsIHRhYmxlLmJvcmRlcmxlc3MgdGggewogIGJvcmRlcjogMCB9Cgp0YWJs
ZS5ib3JkZXJsZXNzIHRkLCB0YWJsZS5ib3JkZXJsZXNzIHRoIHsKICAvKiBPdmVycmlkZSBw
YWRkaW5nIGZvciAidGFibGUuZG9jdXRpbHMgdGQiIHdpdGggIiEgaW1wb3J0YW50Ii4KICAg
ICBUaGUgcmlnaHQgcGFkZGluZyBzZXBhcmF0ZXMgdGhlIHRhYmxlIGNlbGxzLiAqLwogIHBh
ZGRpbmc6IDAgMC41ZW0gMCAwICEgaW1wb3J0YW50IH0KCi5maXJzdCB7CiAgLyogT3ZlcnJp
ZGUgbW9yZSBzcGVjaWZpYyBtYXJnaW4gc3R5bGVzIHdpdGggIiEgaW1wb3J0YW50Ii4gKi8K
ICBtYXJnaW4tdG9wOiAwICEgaW1wb3J0YW50IH0KCi5sYXN0LCAud2l0aC1zdWJ0aXRsZSB7
CiAgbWFyZ2luLWJvdHRvbTogMCAhIGltcG9ydGFudCB9CgouaGlkZGVuIHsKICBkaXNwbGF5
OiBub25lIH0KCmEudG9jLWJhY2tyZWYgewogIHRleHQtZGVjb3JhdGlvbjogbm9uZSA7CiAg
Y29sb3I6IGJsYWNrIH0KCmJsb2NrcXVvdGUuZXBpZ3JhcGggewogIG1hcmdpbjogMmVtIDVl
bSA7IH0KCmRsLmRvY3V0aWxzIGRkIHsKICBtYXJnaW4tYm90dG9tOiAwLjVlbSB9CgpvYmpl
Y3RbdHlwZT0iaW1hZ2Uvc3ZnK3htbCJdLCBvYmplY3RbdHlwZT0iYXBwbGljYXRpb24veC1z
aG9ja3dhdmUtZmxhc2giXSB7CiAgb3ZlcmZsb3c6IGhpZGRlbjsKfQoKLyogVW5jb21tZW50
IChhbmQgcmVtb3ZlIHRoaXMgdGV4dCEpIHRvIGdldCBib2xkLWZhY2VkIGRlZmluaXRpb24g
bGlzdCB0ZXJtcwpkbC5kb2N1dGlscyBkdCB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgfQoqLwoK
ZGl2LmFic3RyYWN0IHsKICBtYXJnaW46IDJlbSA1ZW0gfQoKZGl2LmFic3RyYWN0IHAudG9w
aWMtdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICB0ZXh0LWFsaWduOiBjZW50ZXIg
fQoKZGl2LmFkbW9uaXRpb24sIGRpdi5hdHRlbnRpb24sIGRpdi5jYXV0aW9uLCBkaXYuZGFu
Z2VyLCBkaXYuZXJyb3IsCmRpdi5oaW50LCBkaXYuaW1wb3J0YW50LCBkaXYubm90ZSwgZGl2
LnRpcCwgZGl2Lndhcm5pbmcgewogIG1hcmdpbjogMmVtIDsKICBib3JkZXI6IG1lZGl1bSBv
dXRzZXQgOwogIHBhZGRpbmc6IDFlbSB9CgpkaXYuYWRtb25pdGlvbiBwLmFkbW9uaXRpb24t
dGl0bGUsIGRpdi5oaW50IHAuYWRtb25pdGlvbi10aXRsZSwKZGl2LmltcG9ydGFudCBwLmFk
bW9uaXRpb24tdGl0bGUsIGRpdi5ub3RlIHAuYWRtb25pdGlvbi10aXRsZSwKZGl2LnRpcCBw
LmFkbW9uaXRpb24tdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICBmb250LWZhbWls
eTogc2Fucy1zZXJpZiB9CgpkaXYuYXR0ZW50aW9uIHAuYWRtb25pdGlvbi10aXRsZSwgZGl2
LmNhdXRpb24gcC5hZG1vbml0aW9uLXRpdGxlLApkaXYuZGFuZ2VyIHAuYWRtb25pdGlvbi10
aXRsZSwgZGl2LmVycm9yIHAuYWRtb25pdGlvbi10aXRsZSwKZGl2Lndhcm5pbmcgcC5hZG1v
bml0aW9uLXRpdGxlLCAuY29kZSAuZXJyb3IgewogIGNvbG9yOiByZWQgOwogIGZvbnQtd2Vp
Z2h0OiBib2xkIDsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiB9CgovKiBVbmNvbW1lbnQg
KGFuZCByZW1vdmUgdGhpcyB0ZXh0ISkgdG8gZ2V0IHJlZHVjZWQgdmVydGljYWwgc3BhY2Ug
aW4KICAgY29tcG91bmQgcGFyYWdyYXBocy4KZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1maXJz
dCwgZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1taWRkbGUgewogIG1hcmdpbi1ib3R0b206IDAu
NWVtIH0KCmRpdi5jb21wb3VuZCAuY29tcG91bmQtbGFzdCwgZGl2LmNvbXBvdW5kIC5jb21w
b3VuZC1taWRkbGUgewogIG1hcmdpbi10b3A6IDAuNWVtIH0KKi8KCmRpdi5kZWRpY2F0aW9u
IHsKICBtYXJnaW46IDJlbSA1ZW0gOwogIHRleHQtYWxpZ246IGNlbnRlciA7CiAgZm9udC1z
dHlsZTogaXRhbGljIH0KCmRpdi5kZWRpY2F0aW9uIHAudG9waWMtdGl0bGUgewogIGZvbnQt
d2VpZ2h0OiBib2xkIDsKICBmb250LXN0eWxlOiBub3JtYWwgfQoKZGl2LmZpZ3VyZSB7CiAg
bWFyZ2luLWxlZnQ6IDJlbSA7CiAgbWFyZ2luLXJpZ2h0OiAyZW0gfQoKZGl2LmZvb3Rlciwg
ZGl2LmhlYWRlciB7CiAgY2xlYXI6IGJvdGg7CiAgZm9udC1zaXplOiBzbWFsbGVyIH0KCmRp
di5saW5lLWJsb2NrIHsKICBkaXNwbGF5OiBibG9jayA7CiAgbWFyZ2luLXRvcDogMWVtIDsK
ICBtYXJnaW4tYm90dG9tOiAxZW0gfQoKZGl2LmxpbmUtYmxvY2sgZGl2LmxpbmUtYmxvY2sg
ewogIG1hcmdpbi10b3A6IDAgOwogIG1hcmdpbi1ib3R0b206IDAgOwogIG1hcmdpbi1sZWZ0
OiAxLjVlbSB9CgpkaXYuc2lkZWJhciB7CiAgbWFyZ2luOiAwIDAgMC41ZW0gMWVtIDsKICBi
b3JkZXI6IG1lZGl1bSBvdXRzZXQgOwogIHBhZGRpbmc6IDFlbSA7CiAgYmFja2dyb3VuZC1j
b2xvcjogI2ZmZmZlZSA7CiAgd2lkdGg6IDQwJSA7CiAgZmxvYXQ6IHJpZ2h0IDsKICBjbGVh
cjogcmlnaHQgfQoKZGl2LnNpZGViYXIgcC5ydWJyaWMgewogIGZvbnQtZmFtaWx5OiBzYW5z
LXNlcmlmIDsKICBmb250LXNpemU6IG1lZGl1bSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2VzIHsK
ICBtYXJnaW46IDVlbSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2VzIGgxIHsKICBjb2xvcjogcmVk
IH0KCmRpdi5zeXN0ZW0tbWVzc2FnZSB7CiAgYm9yZGVyOiBtZWRpdW0gb3V0c2V0IDsKICBw
YWRkaW5nOiAxZW0gfQoKZGl2LnN5c3RlbS1tZXNzYWdlIHAuc3lzdGVtLW1lc3NhZ2UtdGl0
bGUgewogIGNvbG9yOiByZWQgOwogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCmRpdi50b3BpYyB7
CiAgbWFyZ2luOiAyZW0gfQoKaDEuc2VjdGlvbi1zdWJ0aXRsZSwgaDIuc2VjdGlvbi1zdWJ0
aXRsZSwgaDMuc2VjdGlvbi1zdWJ0aXRsZSwKaDQuc2VjdGlvbi1zdWJ0aXRsZSwgaDUuc2Vj
dGlvbi1zdWJ0aXRsZSwgaDYuc2VjdGlvbi1zdWJ0aXRsZSB7CiAgbWFyZ2luLXRvcDogMC40
ZW0gfQoKaDEudGl0bGUgewogIHRleHQtYWxpZ246IGNlbnRlciB9CgpoMi5zdWJ0aXRsZSB7
CiAgdGV4dC1hbGlnbjogY2VudGVyIH0KCmhyLmRvY3V0aWxzIHsKICB3aWR0aDogNzUlIH0K
CmltZy5hbGlnbi1sZWZ0LCAuZmlndXJlLmFsaWduLWxlZnQsIG9iamVjdC5hbGlnbi1sZWZ0
IHsKICBjbGVhcjogbGVmdCA7CiAgZmxvYXQ6IGxlZnQgOwogIG1hcmdpbi1yaWdodDogMWVt
IH0KCmltZy5hbGlnbi1yaWdodCwgLmZpZ3VyZS5hbGlnbi1yaWdodCwgb2JqZWN0LmFsaWdu
LXJpZ2h0IHsKICBjbGVhcjogcmlnaHQgOwogIGZsb2F0OiByaWdodCA7CiAgbWFyZ2luLWxl
ZnQ6IDFlbSB9CgppbWcuYWxpZ24tY2VudGVyLCAuZmlndXJlLmFsaWduLWNlbnRlciwgb2Jq
ZWN0LmFsaWduLWNlbnRlciB7CiAgZGlzcGxheTogYmxvY2s7CiAgbWFyZ2luLWxlZnQ6IGF1
dG87CiAgbWFyZ2luLXJpZ2h0OiBhdXRvOwp9CgouYWxpZ24tbGVmdCB7CiAgdGV4dC1hbGln
bjogbGVmdCB9CgouYWxpZ24tY2VudGVyIHsKICBjbGVhcjogYm90aCA7CiAgdGV4dC1hbGln
bjogY2VudGVyIH0KCi5hbGlnbi1yaWdodCB7CiAgdGV4dC1hbGlnbjogcmlnaHQgfQoKLyog
cmVzZXQgaW5uZXIgYWxpZ25tZW50IGluIGZpZ3VyZXMgKi8KZGl2LmFsaWduLXJpZ2h0IHsK
ICB0ZXh0LWFsaWduOiBpbmhlcml0IH0KCi8qIGRpdi5hbGlnbi1jZW50ZXIgKiB7ICovCi8q
ICAgdGV4dC1hbGlnbjogbGVmdCB9ICovCgpvbC5zaW1wbGUsIHVsLnNpbXBsZSB7CiAgbWFy
Z2luLWJvdHRvbTogMWVtIH0KCm9sLmFyYWJpYyB7CiAgbGlzdC1zdHlsZTogZGVjaW1hbCB9
CgpvbC5sb3dlcmFscGhhIHsKICBsaXN0LXN0eWxlOiBsb3dlci1hbHBoYSB9CgpvbC51cHBl
cmFscGhhIHsKICBsaXN0LXN0eWxlOiB1cHBlci1hbHBoYSB9CgpvbC5sb3dlcnJvbWFuIHsK
ICBsaXN0LXN0eWxlOiBsb3dlci1yb21hbiB9CgpvbC51cHBlcnJvbWFuIHsKICBsaXN0LXN0
eWxlOiB1cHBlci1yb21hbiB9CgpwLmF0dHJpYnV0aW9uIHsKICB0ZXh0LWFsaWduOiByaWdo
dCA7CiAgbWFyZ2luLWxlZnQ6IDUwJSB9CgpwLmNhcHRpb24gewogIGZvbnQtc3R5bGU6IGl0
YWxpYyB9CgpwLmNyZWRpdHMgewogIGZvbnQtc3R5bGU6IGl0YWxpYyA7CiAgZm9udC1zaXpl
OiBzbWFsbGVyIH0KCnAubGFiZWwgewogIHdoaXRlLXNwYWNlOiBub3dyYXAgfQoKcC5ydWJy
aWMgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICBmb250LXNpemU6IGxhcmdlciA7CiAgY29s
b3I6IG1hcm9vbiA7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0KCnAuc2lkZWJhci10aXRsZSB7
CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICBm
b250LXNpemU6IGxhcmdlciB9CgpwLnNpZGViYXItc3VidGl0bGUgewogIGZvbnQtZmFtaWx5
OiBzYW5zLXNlcmlmIDsKICBmb250LXdlaWdodDogYm9sZCB9CgpwLnRvcGljLXRpdGxlIHsK
ICBmb250LXdlaWdodDogYm9sZCB9CgpwcmUuYWRkcmVzcyB7CiAgbWFyZ2luLWJvdHRvbTog
MCA7CiAgbWFyZ2luLXRvcDogMCA7CiAgZm9udDogaW5oZXJpdCB9CgpwcmUubGl0ZXJhbC1i
bG9jaywgcHJlLmRvY3Rlc3QtYmxvY2ssIHByZS5tYXRoLCBwcmUuY29kZSB7CiAgbWFyZ2lu
LWxlZnQ6IDJlbSA7CiAgbWFyZ2luLXJpZ2h0OiAyZW0gfQoKcHJlLmNvZGUgLmxuIHsgY29s
b3I6IGdyZXk7IH0gLyogbGluZSBudW1iZXJzICovCnByZS5jb2RlLCBjb2RlIHsgYmFja2dy
b3VuZC1jb2xvcjogI2VlZWVlZSB9CnByZS5jb2RlIC5jb21tZW50LCBjb2RlIC5jb21tZW50
IHsgY29sb3I6ICM1QzY1NzYgfQpwcmUuY29kZSAua2V5d29yZCwgY29kZSAua2V5d29yZCB7
IGNvbG9yOiAjM0IwRDA2OyBmb250LXdlaWdodDogYm9sZCB9CnByZS5jb2RlIC5saXRlcmFs
LnN0cmluZywgY29kZSAubGl0ZXJhbC5zdHJpbmcgeyBjb2xvcjogIzBDNTQwNCB9CnByZS5j
b2RlIC5uYW1lLmJ1aWx0aW4sIGNvZGUgLm5hbWUuYnVpbHRpbiB7IGNvbG9yOiAjMzUyQjg0
IH0KcHJlLmNvZGUgLmRlbGV0ZWQsIGNvZGUgLmRlbGV0ZWQgeyBiYWNrZ3JvdW5kLWNvbG9y
OiAjREVCMEExfQpwcmUuY29kZSAuaW5zZXJ0ZWQsIGNvZGUgLmluc2VydGVkIHsgYmFja2dy
b3VuZC1jb2xvcjogI0EzRDI4OX0KCnNwYW4uY2xhc3NpZmllciB7CiAgZm9udC1mYW1pbHk6
IHNhbnMtc2VyaWYgOwogIGZvbnQtc3R5bGU6IG9ibGlxdWUgfQoKc3Bhbi5jbGFzc2lmaWVy
LWRlbGltaXRlciB7CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0
OiBib2xkIH0KCnNwYW4uaW50ZXJwcmV0ZWQgewogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlm
IH0KCnNwYW4ub3B0aW9uIHsKICB3aGl0ZS1zcGFjZTogbm93cmFwIH0KCnNwYW4ucHJlIHsK
ICB3aGl0ZS1zcGFjZTogcHJlIH0KCnNwYW4ucHJvYmxlbWF0aWMgewogIGNvbG9yOiByZWQg
fQoKc3Bhbi5zZWN0aW9uLXN1YnRpdGxlIHsKICAvKiBmb250LXNpemUgcmVsYXRpdmUgdG8g
cGFyZW50IChoMS4uaDYgZWxlbWVudCkgKi8KICBmb250LXNpemU6IDgwJSB9Cgp0YWJsZS5j
aXRhdGlvbiB7CiAgYm9yZGVyLWxlZnQ6IHNvbGlkIDFweCBncmF5OwogIG1hcmdpbi1sZWZ0
OiAxcHggfQoKdGFibGUuZG9jaW5mbyB7CiAgbWFyZ2luOiAyZW0gNGVtIH0KCnRhYmxlLmRv
Y3V0aWxzIHsKICBtYXJnaW4tdG9wOiAwLjVlbSA7CiAgbWFyZ2luLWJvdHRvbTogMC41ZW0g
fQoKdGFibGUuZm9vdG5vdGUgewogIGJvcmRlci1sZWZ0OiBzb2xpZCAxcHggYmxhY2s7CiAg
bWFyZ2luLWxlZnQ6IDFweCB9Cgp0YWJsZS5kb2N1dGlscyB0ZCwgdGFibGUuZG9jdXRpbHMg
dGgsCnRhYmxlLmRvY2luZm8gdGQsIHRhYmxlLmRvY2luZm8gdGggewogIHBhZGRpbmctbGVm
dDogMC41ZW0gOwogIHBhZGRpbmctcmlnaHQ6IDAuNWVtIDsKICB2ZXJ0aWNhbC1hbGlnbjog
dG9wIH0KCnRhYmxlLmRvY3V0aWxzIHRoLmZpZWxkLW5hbWUsIHRhYmxlLmRvY2luZm8gdGgu
ZG9jaW5mby1uYW1lIHsKICBmb250LXdlaWdodDogYm9sZCA7CiAgdGV4dC1hbGlnbjogbGVm
dCA7CiAgd2hpdGUtc3BhY2U6IG5vd3JhcCA7CiAgcGFkZGluZy1sZWZ0OiAwIH0KCi8qICJi
b29rdGFicyIgc3R5bGUgKG5vIHZlcnRpY2FsIGxpbmVzKSAqLwp0YWJsZS5kb2N1dGlscy5i
b29rdGFicyB7CiAgYm9yZGVyOiAwcHg7CiAgYm9yZGVyLXRvcDogMnB4IHNvbGlkOwogIGJv
cmRlci1ib3R0b206IDJweCBzb2xpZDsKICBib3JkZXItY29sbGFwc2U6IGNvbGxhcHNlOwp9
CnRhYmxlLmRvY3V0aWxzLmJvb2t0YWJzICogewogIGJvcmRlcjogMHB4Owp9CnRhYmxlLmRv
Y3V0aWxzLmJvb2t0YWJzIHRoIHsKICBib3JkZXItYm90dG9tOiB0aGluIHNvbGlkOwogIHRl
eHQtYWxpZ246IGxlZnQ7Cn0KCmgxIHR0LmRvY3V0aWxzLCBoMiB0dC5kb2N1dGlscywgaDMg
dHQuZG9jdXRpbHMsCmg0IHR0LmRvY3V0aWxzLCBoNSB0dC5kb2N1dGlscywgaDYgdHQuZG9j
dXRpbHMgewogIGZvbnQtc2l6ZTogMTAwJSB9Cgp1bC5hdXRvLXRvYyB7CiAgbGlzdC1zdHls
ZS10eXBlOiBub25lIH0KCjwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+CjxkaXYgY2xhc3M9ImRv
Y3VtZW50IiBpZD0iaW1wbGljaXQtcmV0dXJuLXR5cGUiPgo8aDEgY2xhc3M9InRpdGxlIj5J
bXBsaWNpdCBSZXR1cm4gVHlwZTwvaDE+CjxoMiBjbGFzcz0ic3VidGl0bGUiIGlkPSJkZWNl
bWJlci0zMC0yMDE1Ij5EZWNlbWJlciAzMCwgMjAxNTwvaDI+Cgo8c3R5bGU+CiAgaHRtbCB7
IGNvbG9yOiBibGFjazsgYmFja2dyb3VuZDogd2hpdGU7IH0KPC9zdHlsZT48ZGl2IGNsYXNz
PSJzZWN0aW9uIiBpZD0iYWJzdHJhY3QiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBo
cmVmPSIjaWQxIj5BYnN0cmFjdDwvYT48L2gxPgo8cD5UaGlzIHByb3Bvc2FsIHJlY29tbWVu
ZHMgYW4gZW5oYW5jZW1lbnQgdG8gcmV0dXJuIHR5cGUgZGVkdWN0aW9uIHRvIGFsbG93IHRo
ZSByZXR1cm4gdHlwZSBvZiBhIGZ1bmN0aW9uIGRlZmluaXRpb24gdG8gYmUgaW5mZXJyZWQg
ZnJvbSBhIHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mIHRoZSBzYW1lLjwvcD4KPGRpdiBjbGFz
cz0iY29udGVudHMgdG9waWMiIGlkPSJjb250ZW50cyI+CjxwIGNsYXNzPSJ0b3BpYy10aXRs
ZSBmaXJzdCI+Q29udGVudHM8L3A+Cjx1bCBjbGFzcz0ic2ltcGxlIj4KPGxpPjxhIGNsYXNz
PSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNhYnN0cmFjdCIgaWQ9ImlkMSI+QWJzdHJh
Y3Q8L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNy
YXRpb25hbGUiIGlkPSJpZDIiPlJhdGlvbmFsZTwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJl
ZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3Byb3Bvc2FsIiBpZD0iaWQzIj5Qcm9wb3NhbDwv
YT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI2Rpc2N1
c3Npb24iIGlkPSJpZDQiPkRpc2N1c3Npb248L2E+PC9saT4KPC91bD4KPC9kaXY+CjwvZGl2
Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0icmF0aW9uYWxlIj4KPGgxPjxhIGNsYXNzPSJ0
b2MtYmFja3JlZiIgaHJlZj0iI2lkMiI+UmF0aW9uYWxlPC9hPjwvaDE+CjxwPlRoZSBjb25j
ZXB0IG9mIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgaXMgd2VsbCBrbm93bi4gQXQgcHJlc2Vu
dCwgaG93ZXZlciwgQysrIGxhY2tzIGEgZ29vZCBtZWNoYW5pc20gZm9yIGltcGxlbWVudGlu
ZyB0aGUgc2FtZS4gPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj48c3BhbiBjbGFzcz0i
cHJlIj5zdGQ6OnR1cGxlPC9zcGFuPjwvdHQ+IGlzIGNvbnNpZGVyZWQgY2x1bmt5IGJ5IG1h
bnkgYW5kLCBjcml0aWNhbGx5LCBjcmVhdGVzIHN1Yi1vcHRpbWFsIEFQSSBieSB2aXJ0dWUg
b2YgdGhlIHJldHVybmVkIHZhbHVlcyBiZWluZyB1bm5hbWVkLCBmb3JjaW5nIGRldmVsb3Bl
cnMgdG8gcmVseSBvbiBzdXBwbGVtZW50YWwgZG9jdW1lbnRhdGlvbiB0byBleHBsYWluIHRo
ZWlyIHB1cnBvc2UuIEFnZ3JlZ2F0ZXMgcmVwcmVzZW50IGFuIGltcHJvdmVtZW50LCBiZWlu
ZyBzZWxmLWRvY3VtZW50aW5nLCBidXQgdGhlIG5lZWQgdG8gcHJvdmlkZSBleHRlcm5hbCBk
ZWZpbml0aW9ucyBvZiB0aGUgc2FtZSBpcyBhd2t3YXJkIGFuZCwgd29yc2UsIHBvbGx1dGVz
IHRoZWlyIGNvcnJlc3BvbmRpbmcgbmFtZXNwYWNlIHdpdGggZW50aXRpZXMgdGhhdCBtYXkg
YmUgc2luZ2xlIHVzZS4gUHJvcG9zYWxzIHN1Y2ggYXMgPGEgY2xhc3M9InJlZmVyZW5jZSBl
eHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEv
ZG9jcy9wYXBlcnMvMjAxNS9uNDU2MC5wZGYiPk40NTYwPC9hPiBwcmVzZW50IGEgY29tcGxp
Y2F0ZWQgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgdGFnZ2VkIChzZWxmLWRvY3VtZW50aW5n
KSB0dXBsZS1saWtlIHR5cGVzLCB3aGljaCBtYXkgYmUgbmVjZXNzYXJ5IGluIHNvbWUgY2Fz
ZXMsIGJ1dCBzdGlsbCByZXByZXNlbnQgYSBub24tdHJpdmlhbCBhbW91bnQgb2YgY29tcGxl
eGl0eSB0aGF0IGlkZWFsbHkgc2hvdWxkIG5vdCBiZSByZXF1aXJlZC48L3A+CjxwPlByb3Bv
c2FscyBzdWNoIGFzIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6
Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvcDAx
NDRyMC5wZGYiPlAwMTQ0PC9hPiAob3IgaXRzIGNvbXBldGl0b3IgPGEgY2xhc3M9InJlZmVy
ZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIy
L3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZiI+UDAxNTE8L2E+KSBpbiBwYXJ0
aWN1bGFyIHdvdWxkIHJlcHJlc2VudCBhIHNpZ25pZmljYW50IHN0ZXAgdG93YXJkIHN1cHBv
cnQgb2YgbXVsdGlwbGUgcmV0dXJuIHZhbHVlcyBhcyBmaXJzdCBjbGFzcyBjaXRpemVucy4g
VGhlc2UgcHJvcG9zYWxzIGFuZCBvdGhlciBjdXJyZW50IGRpcmVjdGlvbnMgc2hvdyBhbiBl
bmNvdXJhZ2luZyBtb3ZlbWVudCBhd2F5IGZyb20gdGhlIHRyYWRpdGlvbmFsIDx0dCBjbGFz
cz0iZG9jdXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjpwYWlyPC9zcGFu
PjwvdHQ+IGFuZCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJw
cmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gdG93YXJkcyBjb21wYXJhYmxlIGNvbmNlcHRz
IHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBleHBsaWNpdCB0eXBlcy4gKFdlIGV4cGVjdCwgaG93
ZXZlciwgdGhhdCB0aGVzZSB3aWxsIHJlbWFpbiB1c2VmdWwgZm9yIGFsZ29yaXRobXMgd2hl
cmUgdGhlIGlkZW50aXR5IG9mIHRoZSBlbGVtZW50cyBpcyB1bmltcG9ydGFudCwgd2hpbGUg
aXQgPGVtPmlzPC9lbT4gaW1wb3J0YW50IHRvIGJlIGFibGUgdG8gbmFtZSBhdCBsZWFzdCB0
aGUgb3V0ZXIsIGlmIG5vdCBjb21wbGV0ZSwgdHlwZS4gSW4gdGhhdCByZXNwZWN0LCB3ZSBo
eXBvdGhlc2l6ZSB0aGF0IHdlIG1heSBpbiB0aGUgZnV0dXJlIHNlZSB0aGUgYWJpbGl0eSB0
byBjb25zdHJ1Y3QgYSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNz
PSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gZnJvbSBhbnkgdHVwbGUtbGlrZS4pIE9u
IHRoZWlyIG93biwgaG93ZXZlciwgdGhlc2UgcHJvcG9zYWxzIHJpc2sgZXhhY2VyYmF0aW5n
IHRoZSBwcm9ibGVtIHRoYXQgdGhpcyBwcm9wb3NhbCBhaW1zIHRvIGFkZHJlc3MuPC9wPgo8
cD5JdCBoYXMgYmVlbiBzdWdnZXN0ZWQgb24gbXVsdGlwbGUgb2NjYXNpb25zIHRoYXQgdGhl
IG9wdGltYWwgc29sdXRpb24gdG8gdGhlIGFib3ZlIGlzc3VlcyBpcyB0byByZXR1cm4gYW4g
YW5vbnltb3VzIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+c3RydWN0PC90dD4uIFRo
aXMgc29sdmVzIHRoZSBwcm9ibGVtcyBvZiBjbHV0dGVyIGFuZCBzZWxmLWRvY3VtZW50YXRp
b24sIGJ1dCBydW5zIGFmb3VsIG9mIGEgbXVjaCB3b3JzZSBpc3N1ZTsgYmVjYXVzZSB0aGUg
PHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5zdHJ1Y3Q8L3R0PiBpcyA8ZW0+YW5vbnlt
b3VzPC9lbT4sIGl0IGNhbiBiZSBkaWZmaWN1bHQgdG8gaW1wb3NzaWJsZSB0byBnaXZlIGl0
cyBuYW1lIGEgc2Vjb25kIHRpbWUgaW4gb3JkZXIgdG8gc2VwYXJhdGUgdGhlIGRlY2xhcmF0
aW9uIGFuZCBkZWZpbml0aW9uIG9mIHRoZSBmdW5jdGlvbiB0aGF0IHdpc2hlcyB0byB1c2Ug
aXQuPC9wPgo8cD5Ib3dldmVyLCBpbiBDKyssIGZ1bmN0aW9ucyBjYW5ub3QgYmUgb3Zlcmxv
YWRlZCBieSB0aGVpciByZXR1cm4gdmFsdWUuIFRoaXMgbGVhZHMgdG8gYW4gb2J2aW91cyBx
dWVzdGlvbjogPHN0cm9uZz53aHkgaXMgaXQgbmVjZXNzYXJ5IHRvIHJlcGVhdCB0aGUgcmV0
dXJuIHZhbHVlIGF0IGFsbD88L3N0cm9uZz48L3A+CjxwPkV2ZW4gaW4gdGhlIGNhc2Ugb2Yg
cmV0dXJuIHR5cGVzIHRoYXQgY2FuIGJlIG5hbWVkLCBpdCBtYXkgYmUgdGhhdCByZXBlYXRp
bmcgdGhlIHR5cGUgbmFtZSBpcyBleGNlc3NpdmVseSB2ZXJib3NlIG9yIG90aGVyd2lzZSB1
bmRlc2lyYWJsZS4gU29tZSBtaWdodCBldmVuIGNhbGwgdGhpcyBhIHZpb2xhdGlvbiBvZiB0
aGUgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cHM6Ly9lbi53aWtp
cGVkaWEub3JnL3dpa2kvRG9uJ3RfcmVwZWF0X3lvdXJzZWxmIj5Eb24ndCBSZXBlYXQgWW91
cnNlbGY8L2E+IHByaW5jaXBsZSwgc2ltaWxhciB0byBzb21lIG9mIHRoZSBpc3N1ZXMgdGhh
dCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88L3R0PiBmb3IgdmFyaWFibGUg
ZGVjbGFyYXRpb24gd2FzIGludHJvZHVjZWQgdG8gc29sdmUuIChPbiB0aGUgZmxpcCBzaWRl
LCBvbmUgY291bGQgc2VlIHRoZSBhYmlsaXR5IHRvIGVsaWRlIHRoZSByZXR1cm4gdHlwZSBh
cyBzdWJqZWN0IHRvIG1hbnkgYWJ1c2VzLCBhZ2FpbiBpbiBtdWNoIHRoZSBtYW5uZXIgb2Yg
PHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRvPC90dD4uIEhvd2V2ZXIsIG1hbnkg
bGFuZ3VhZ2UgZmVhdHVyZXMgY2FuIGJlIGFidXNlZDsgdGhpcyBzaG91bGQgbm90IHByZXZl
bnQgdGhlIGFkZGl0aW9uIG9mIGEgZmVhdHVyZSB0aGF0IHdvdWxkIHByb3ZpZGUgYW4gaW1w
b3J0YW50IGJlbmVmaXQgd2hlbiB1c2VkIGNvcnJlY3RseS4pPC9wPgo8cD5XZSB3b3VsZCBi
ZSByZW1pc3Mgbm90IHRvIG5vdGUgdGhhdCB0aGlzIGlzIGFscmVhZHkgcG9zc2libGUgaW4g
c2ltcGxlIGNhc2VzIHVzaW5nIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+ZGVjbHR5
cGU8L3R0PiBhbmQgYSBzYW1wbGUgaW52b2NhdGlvbiBvZiB0aGUgZnVuY3Rpb24uIEhvd2V2
ZXIsIHdoaWxlIHRoaXMgbWF5IGJlIGFkZXF1YXRlIGluIHNpbXBsZSBjYXNlcywgaXQgaXMg
bmV2ZXJ0aGVsZXNzIG5lZWRsZXNzbHkgdmVyYm9zZSwgYW5kIGFzIHRoZSBhcmd1bWVudCBs
aXN0IGdyb3dzIGxvbmdlciwgYW5kL29yIGdhaW5zIGFyZ3VtZW50cyBmb3Igd2hpY2ggcHJv
dmlkaW5nIGEgbGVnYWwgdmFsdWUgaXMgbm9uLXRyaXZpYWwsIGl0IGNhbiBxdWlja2x5IGJl
Y29tZSB1bndpZWxkeSBhbmQgdW5mZWFzaWJsZS48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJz
ZWN0aW9uIiBpZD0icHJvcG9zYWwiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVm
PSIjaWQzIj5Qcm9wb3NhbDwvYT48L2gxPgo8cD5SZWNlbnQgY2hhbmdlcyB0byB0aGUgbGFu
Z3VhZ2UgaGF2ZSBwcm9ncmVzc2l2ZWx5IHJlbGF4ZWQgdGhlIHJlcXVpcmVtZW50cyBmb3Ig
aG93IHJldHVybiB0eXBlcyBhcmUgc3BlY2lmaWVkLiBXZSBiZWdhbiB3aXRoIHRyYWlsaW5n
IHJldHVybiB0eXBlIHNwZWNpZmljYXRpb24sIGFuZCBoYXZlIHByb2dyZXNzZWQgdG8gaW5m
ZXJyZWQgcmV0dXJuIHR5cGVzIGluIGNlcnRhaW4gY2FzZXMuPC9wPgo8cD5UaGlzIHByb3Bv
c2FsIGlzIHRvIGNvbnRpbnVlIHRoaXMgZGlyZWN0aW9uIGJ5IGFkZGluZyBhbiBhZGRpdGlv
bmFsIHVzZSBvZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88L3R0PiBhcyBh
IHJldHVybiBzcGVjaWZpZXIsIG1lYW5pbmcgJnF1b3Q7dXNlIHRoZSByZXR1cm4gdHlwZSBz
ZWVuIHdoZW4gdGhpcyBmdW5jdGlvbiB3YXMgcHJldmlvdXNseSBkZWNsYXJlZCZxdW90Oy4g
VGhpcyBwcm92aWRlcyBhbiBvcHRpbWFsIHNvbHV0aW9uIHRvIHRoZSBmb2xsb3dpbmcgcHJv
YmxlbTo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwtYmxvY2siPgo8c3BhbiBj
bGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIGZvby5oCjwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5
d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+
IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5h
bWUiPmlkPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4gPHNwYW4g
Y2xhc3M9ImtleXdvcmQgdHlwZSI+ZG91YmxlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+
dmFsdWU8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5mb288L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8L3NwYW4+CjwvcHJlPgo8cD5Ib3cg
ZG9lcyBvbmUgbm93IHByb3ZpZGUgYW4gZXh0ZXJuYWwgZGVmaW5pdGlvbiBmb3IgPHR0IGNs
YXNzPSJkb2N1dGlscyBsaXRlcmFsIj5mb28oKTwvdHQ+PyBXZSBwcm9wb3NlOjwvcD4KPHBy
ZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJjb21tZW50
IHNpbmdsZSI+Ly8gZm9vLmNwcAo8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88
L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57
PC9zcGFuPgogIDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uPC9zcGFuPgogIDxzcGFu
IGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmlkPC9zcGFuPjxzcGFuIGNsYXNzPSJw
dW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPnZhbHVlPC9zcGFuPiA8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8cD5UaGUgdXNlIG9mIDx0dCBjbGFzcz0iZG9jdXRp
bHMgbGl0ZXJhbCI+YXV0bzwvdHQ+IGFzIHRoZSByZXR1cm4gdHlwZSBzcGVjaWZpZXIsIHdp
dGggbm8gdHJhaWxpbmcgcmV0dXJuIHR5cGUsIGFuZCBmb3IgYSBmdW5jdGlvbiB0aGF0IGhh
cyBiZWVuIHByZXZpb3VzbHkgZGVjbGFyZWQgd2l0aCBhIGtub3duIHJldHVybiB0eXBlLCBz
aGFsbCBpbnN0cnVjdCB0aGUgY29tcGlsZXIgdG8gZGVmaW5lIHRoZSBmdW5jdGlvbiB1c2lu
ZyB0aGUgcmV0dXJuIHR5cGUgZnJvbSB0aGUgcHJldmlvdXMgZGVjbGFyYXRpb24uIChOb3Rl
IHRoYXQgdGhpcyB3b3JrcyBmb3IgPGVtPmFueTwvZW0+IHR5cGUsIG5vdCBqdXN0IGFub255
bW91cyA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnN0cnVjdDwvdHQ+cy4pPC9wPgo8
cD5OYXR1cmFsbHksICZxdW90O3ByZXZpb3VzIGRlY2xhcmF0aW9uJnF1b3Q7IGhlcmUgbWVh
bnMgYSBkZWNsYXJhdGlvbiBoYXZpbmcgdGhlIHNhbWUgbmFtZSBhbmQgYXJndW1lbnQgbGlz
dC4gVGhpcywgZm9yIGV4YW1wbGUsIHdvdWxkIHJlbWFpbiBpbGxlZ2FsOjwvcD4KPHByZSBj
bGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5z
dHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4g
Y2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+aWQ8
L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0i
a2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj52YWx1ZTwvc3Bh
bj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+fTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+
aW50PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTs8L3NwYW4+CjxzcGFuIGNs
YXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBj
bGFzcz0ibmFtZSI+aWQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFu
PiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im5hbWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4g
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+
Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFz
cz0ia2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pik7PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+IDxzcGFuIGNs
YXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im5hbWUiPmlucHV0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
KTwvc3Bhbj4gPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBkb2VzIG5vdCBtYXRj
aCBhbnkgcHJldmlvdXMgZGVjbGFyYXRpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj4K
ICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8
L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTs8L3NwYW4+CjxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPkFkZGl0aW9uYWxseSwgYW5kIGZv
ciBvYnZpb3VzIHJlYXNvbnMsIHdlIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZSBwcm9oaWJpdGlv
biAoW2RjbC5mY3RdLzExKSBhZ2FpbnN0IGRlZmluaW5nIHR5cGVzIGluIHJldHVybiB0eXBl
IHNwZWNpZmljYXRpb25zLiBXZSBhZGRpdGlvbmFsbHkgbm90ZSB0aGF0IHRoaXMgcHJvaGli
aXRpb24gaXMgYWxyZWFkeSBub3QgZW5mb3JjZWQgYnkgYXQgbGVhc3Qgb25lIG1ham9yIGNv
bXBpbGVyIChHQ0MpLiBXZSBmdXJ0aGVyIGJlbGlldmUgdGhpcyBwcm9oaWJpdGlvbiB0byBi
ZSBvdXRkYXRlZDsgaXQgbWFkZSBzZW5zZSBpbiBDKys5OCwgYnV0IHdpdGggcmVjZW50IGNo
YW5nZXMgc3VjaCBhcyB0aGUgYWRkaXRpb24gb2YgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRl
cmFsIj5kZWNsdHlwZTwvdHQ+IGFuZCB0aGUgYWJpbGl0eSB0byBvbWl0IHRoZSB0eXBlIG5h
bWUgaW4gYSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnJldHVybjwvdHQ+IHN0YXRl
bWVudCByZXR1cm5pbmcgYW4gaW4tcGxhY2UgY29uc3RydWN0ZWQgY2xhc3MsIHRoZSByZWFz
b25zIGZvciB0aGUgcHJvaGliaXRpb24gaGF2ZSBiZWVuIGdyZWF0bHkgbWl0aWdhdGVkLiBU
aGlzIG90aGVyIHBhcnQgb2YgdGhpcyBwcm9wb3NhbCB3b3VsZCBsYXJnZWx5IHJlbW92ZSBh
bnkgcmVtYWluaW5nIG1vdGl2YXRpb24gZm9yIHRoZSBwcm9oaWJpdGlvbi48L3A+CjwvZGl2
Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0iZGlzY3Vzc2lvbiI+CjxoMT48YSBjbGFzcz0i
dG9jLWJhY2tyZWYiIGhyZWY9IiNpZDQiPkRpc2N1c3Npb248L2E+PC9oMT4KPHA+QW4gb2J2
aW91cyBmb2xsb3ctb24gcXVlc3Rpb24gaXMsIHNob3VsZCB3ZSBhbHNvIGxpZnQgdGhlIHBy
b2hpYml0aW9uIGFnYWluc3QgdHlwZXMgZGVmaW5lZCBpbiBwYXJhbWV0ZXIgc3BlY2lmaWNh
dGlvbnM/IFRoZXJlIGhhdmUgYmVlbiBzdWdnZXN0aW9ucyBmbG9hdGVkIHRvIGltcGxlbWVu
dCB0aGUgbXVjaCByZXF1ZXN0ZWQgbmFtZWQgcGFyYW1ldGVycyBpbiBzb21ldGhpbmcgbGlr
ZSB0aGlzIG1hbm5lci4gSG93ZXZlciwgdGhlcmUgYXJlIHNpZ25pZmljYW50IChpbiBvdXIg
b3BpbmlvbikgcmVhc29ucyB0byBub3QgYWRkcmVzcyB0aGlzLCBhdCBsZWFzdCBpbml0aWFs
bHkuIEZpcnN0LCBpdCBpcyB3aWRlbHkgY29udGVzdGVkIHRoYXQgdGhpcyBpcyBub3QgYW4g
b3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSAobmFtZWQgcGFyYW1ldGVycykgaW4g
dGhlIGZpcnN0IHBsYWNlLiBTZWNvbmQsIGl0IGRlcGVuZHMgb24gbmFtZWQgaW5pdGlhbGl6
ZXJzLCB3aGljaCBpcyBhbiBhcmVhIG9mIG9uZ29pbmcgd29yay4gVGhpcmQsIHRoaXMgcHJv
cG9zYWwgd29ya3MgbGFyZ2VseSBiZWNhdXNlIEMrKyBmb3JiaWRzIG92ZXJsb2FkaW5nIG9u
IHJldHVybiB0eXBlLCB3aGljaCBtYXkgYmUgbGV2ZXJhZ2VkIHRvIGVsaW1pbmF0ZSBhbnkg
YW1iaWd1aXR5IGFzIHRvIHRoZSBkZWR1Y3Rpb24gb2YgdGhlIGFjdHVhbCB0eXBlIG9mIDx0
dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+OyB0aGlzIGlzIG5vdCB0aGUg
Y2FzZSBmb3IgcGFyYW1ldGVycywgYW5kIHNvIHBlcm1pdHRpbmcgPHR0IGNsYXNzPSJkb2N1
dGlscyBsaXRlcmFsIj5hdXRvPC90dD4gYXMgYSBwYXJhbWV0ZXIgdHlwZSBzcGVjaWZpZXIg
d291bGQgcXVpY2tseSBydW4gaW50byBpc3N1ZXMgdGhhdCBjYW4gYmUgYXZvaWRlZCBmb3Ig
dGhlIHJldHVybiB0eXBlIGNhc2UuPC9wPgo8cD5XaGlsZSB3ZSBkbyBub3Qgd2lzaCB0byBj
YXRlZ29yaWNhbGx5IHJ1bGUgb3V0IGZ1dHVyZSBjaGFuZ2VzIGluIHRoaXMgZGlyZWN0aW9u
LCB3ZSBmZWVsIHRoYXQgaXQgaXMgbm90IGFwcHJvcHJpYXRlIGZvciB0aGlzIHByb3Bvc2Fs
IHRvIGF0dGVtcHQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMuPC9wPgo8cD5PbiBhIHJlbGF0
ZWQgbm90ZSwgaXQgaXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgdGhlIHNha2Ugb2Yg
dGhlIGFkZGVkIHV0aWxpdHkgb2YgaW1wbGllZCByZXR1cm4gdHlwZSB0byByZWxheCBbZGNs
LmZjdF0vMTEuIEhvd2V2ZXIsIG11Y2ggb2YgdGhlIGJlbmVmaXQgaXMgbG9zdCB3aXRoIHRo
aXMgcHJvaGliaXRpb24gaW4gcGxhY2UuIENvbnZlcnNlbHksIHNpbXBseSByZWxheGluZyB0
aGUgcHJvaGliaXRpb24gaXMgb2Ygc2lnbmlmaWNhbnRseSBsZXNzIGJlbmVmaXQgd2l0aG91
dCB0aGUgcHJvcG9zZWQgaW1wbGllZCByZXR1cm4gdHlwZSBmZWF0dXJlLiBBY2NvcmRpbmds
eSwgd2hpbGUgd2UgY29uc2lkZXJlZCBzcGxpdHRpbmcgdGhlIHR3byBjaGFuZ2VzIGludG8g
c2VwYXJhdGUgcHJvcG9zYWxzLCB3ZSBoYXZlIGRlY2lkZWQgZm9yIG5vdyB0byBrZWVwIHRo
ZW0gdG9nZXRoZXIuPC9wPgo8IS0tIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4u
IC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC4uIC0tPgo8L2Rpdj4K
PC9kaXY+CjwvYm9keT4KPC9odG1sPgo=
--------------040001000104070806050709--


.

--001a11426f9e5f20db052823f072
Content-Type: text/plain; charset=UTF-8

+1
From an user point of view, this looks pretty clear and very useful.

2015-12-30 17:54 GMT-03:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> This came up in Vicente's recent thread on N4560. Since it seems like an
> obvious and good idea, and received some initial positive feedback, I
> wrote a quick paper.
>
> The short form is: A function definition whose return type is given as
> 'auto', which does not specify a trailing return type, and which was
> previously declared with a known return type, shall use the return type
> from the declaration.
>
> Example:
>
>   // foo.h
>   struct { int id; double value; } foo();
>
>   // foo.cpp
>   auto foo()
>   {
>     ...
>     return { id, value };
>   }
>
> Initial copies attached. Online version at:
>
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-type/PXXXX%20Implicit%20Return%20Type.rst
> (As with my previous draft paper, updates posted here will be sporadic
> at best. Use the github link to always access the current version.)
>
> Please let me know what you think.
>
> --
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--
Daker Fernandes Pinheiro
http://codecereal.blogspot.com

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11426f9e5f20db052823f072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>+1</div><div>From an user point of view, this looks p=
retty clear and very useful.</div></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">2015-12-30 17:54 GMT-03:00 Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">=
mwoehlke.floss@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
This came up in Vicente&#39;s recent thread on N4560. Since it seems like a=
n<br>
obvious and good idea, and received some initial positive feedback, I<br>
wrote a quick paper.<br>
<br>
The short form is: A function definition whose return type is given as<br>
&#39;auto&#39;, which does not specify a trailing return type, and which wa=
s<br>
previously declared with a known return type, shall use the return type<br>
from the declaration.<br>
<br>
Example:<br>
<br>
=C2=A0 // foo.h<br>
=C2=A0 struct { int id; double value; } foo();<br>
<br>
=C2=A0 // foo.cpp<br>
=C2=A0 auto foo()<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 return { id, value };<br>
=C2=A0 }<br>
<br>
Initial copies attached. Online version at:<br>
<a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-ret=
urn-type/PXXXX%20Implicit%20Return%20Type.rst" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-retur=
n-type/PXXXX%20Implicit%20Return%20Type.rst</a><br>
(As with my previous draft paper, updates posted here will be sporadic<br>
at best. Use the github link to always access the current version.)<br>
<br>
Please let me know what you think.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature">Daker Fernandes Pinheiro<br><a href=3D"htt=
p://codecereal.blogspot.com" target=3D"_blank">http://codecereal.blogspot.c=
om</a><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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11426f9e5f20db052823f072--

.

------=_Part_1491_1051090299.1451514057243
Content-Type: multipart/alternative;
 boundary="----=_Part_1492_1271519324.1451514057243"

------=_Part_1492_1271519324.1451514057243
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:
>
> This came up in Vicente's recent thread on N4560. Since it seems like an
> obvious and good idea, and received some initial positive feedback, I
> wrote a quick paper.
>
> The short form is: A function definition whose return type is given as
> 'auto', which does not specify a trailing return type, and which was
> previously declared with a known return type, shall use the return type
> from the declaration.
>
> Example:
>
>   // foo.h
>   struct { int id; double value; } foo();
>

I realize that there's kinda a parser here here. Namely, that the above
already has a well-defined meaning: it declares a variable named `foo` of
an anonymous type, and default initializes it.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1492_1271519324.1451514057243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This came up =
in Vicente&#39;s recent thread on N4560. Since it seems like an
<br>obvious and good idea, and received some initial positive feedback, I
<br>wrote a quick paper.
<br>
<br>The short form is: A function definition whose return type is given as
<br>&#39;auto&#39;, which does not specify a trailing return type, and whic=
h was
<br>previously declared with a known return type, shall use the return type
<br>from the declaration.
<br>
<br>Example:
<br>
<br>=C2=A0 // foo.h
<br>=C2=A0 struct { int id; double value; } foo();
<br></blockquote><div><br>I realize that there&#39;s kinda a parser here he=
re. Namely, that the above already has a well-defined meaning: it declares =
a variable named `foo` of an anonymous type, and default initializes it.</d=
iv><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1492_1271519324.1451514057243--
------=_Part_1491_1051090299.1451514057243--

.

------=_Part_371_608759137.1451514149586
Content-Type: multipart/alternative;
 boundary="----=_Part_372_1385896721.1451514149586"

------=_Part_372_1385896721.1451514149586
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:
>
> On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:
>>
>> This came up in Vicente's recent thread on N4560. Since it seems like an
>> obvious and good idea, and received some initial positive feedback, I
>> wrote a quick paper.
>>
>> The short form is: A function definition whose return type is given as
>> 'auto', which does not specify a trailing return type, and which was
>> previously declared with a known return type, shall use the return type
>> from the declaration.
>>
>> Example:
>>
>>   // foo.h
>>   struct { int id; double value; } foo();
>>
>
> I realize that there's kinda a parser here here. Namely, that the above
> already has a well-defined meaning: it declares a variable named `foo` of
> an anonymous type, and default initializes it.
>

And when I said "default initializes it," I of course meant "value
initializes it." Either way, it already means something totally different.

However, there's no meaning attached to:

auto foo() -> struct {...};
>

So as long as you use a late-specified return type, it'll work.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_372_1385896721.1451514149586
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>On Wednesday, December 30, 20=
15 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">This came up in Vicente&#39;s recent thread on N4560. Since it s=
eems like an
<br>obvious and good idea, and received some initial positive feedback, I
<br>wrote a quick paper.
<br>
<br>The short form is: A function definition whose return type is given as
<br>&#39;auto&#39;, which does not specify a trailing return type, and whic=
h was
<br>previously declared with a known return type, shall use the return type
<br>from the declaration.
<br>
<br>Example:
<br>
<br>=C2=A0 // foo.h
<br>=C2=A0 struct { int id; double value; } foo();
<br></blockquote><div><br>I realize that there&#39;s kinda a parser here he=
re. Namely, that the above already has a well-defined meaning: it declares =
a variable named `foo` of an anonymous type, and default initializes it.</d=
iv></div></blockquote><div><br>And when I said &quot;default initializes it=
,&quot; I of course meant &quot;value initializes it.&quot; Either way, it =
already means something totally different.<br><br>However, there&#39;s no m=
eaning attached to:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gma=
il_quote"><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">au=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</sp=
an><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: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{...};</span></div></code></div></blockquote><br>So as lon=
g as you use a late-specified return type, it&#39;ll work. <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_372_1385896721.1451514149586--
------=_Part_371_608759137.1451514149586--

.

------=_Part_6299_187538096.1451514245869
Content-Type: multipart/alternative;
 boundary="----=_Part_6300_19078678.1451514245869"

------=_Part_6300_19078678.1451514245869
Content-Type: text/plain; charset=UTF-8



On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:
>
>
> I realize that there's kinda a parser here here. Namely, that the above
> already has a well-defined meaning: it declares a variable named `foo` of
> an anonymous type, and default initializes it.
>
>
No, it doesn't. This is currently unambiguously parsed as an (ill-formed)
function declaration, because `()` is not a valid *initializer *in the
grammar.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6300_19078678.1451514245869
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, December 30, 2015 at 5:20:57 PM UTC-=
5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>I realize that there&#39;s kinda a parser here here. Name=
ly, that the above already has a well-defined meaning: it declares a variab=
le named `foo` of an anonymous type, and default initializes it.</div><br><=
/div></blockquote><div><br></div><div>No, it doesn&#39;t. This is currently=
 unambiguously parsed as an (ill-formed) function declaration, because `()`=
 is not a valid <i>initializer </i>in the grammar.</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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6300_19078678.1451514245869--
------=_Part_6299_187538096.1451514245869--

.

------=_Part_819_1629266514.1451515750730
Content-Type: multipart/alternative;
 boundary="----=_Part_820_224740069.1451515750730"

------=_Part_820_224740069.1451515750730
Content-Type: text/plain; charset=UTF-8



On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:
>
> This came up in Vicente's recent thread on N4560. Since it seems like an
> obvious and good idea, and received some initial positive feedback, I
> wrote a quick paper.
>
> The short form is: A function definition whose return type is given as
> 'auto', which does not specify a trailing return type, and which was
> previously declared with a known return type, shall use the return type
> from the declaration.
>
> Example:
>
>   // foo.h
>   struct { int id; double value; } foo();
>
>   // foo.cpp
>   auto foo()
>   {
>     ...
>     return { id, value };
>   }
>
> Initial copies attached. Online version at:
>
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-type/PXXXX%20Implicit%20Return%20Type.rst
> (As with my previous draft paper, updates posted here will be sporadic
> at best. Use the github link to always access the current version.)
>
> Please let me know what you think.
>
> --
> Matthew
>


Does this apply to function templates, whose signature *does* include the
return type?

Also, given

struct { int i; } a, foo();
struct { int i; } bar();

can you write `a = bar();`? In C, you can't, because the two anonymous
structs are distinct, incompatible types. In fact, in C you can't even do

struct { int i; } foo();
struct { int i; } foo() { abort(); }

in the same translation unit.

We additionally note that this prohibition is already not enforced by at
> least one major compiler (GCC).


This is wrong. All versions of GCC on Wandbox enforce [dcl.fct]/11, even
without -pedantic. The one claimed to work in GCC 4.5.2 involves lambda
return types, not regular functions.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_820_224740069.1451515750730
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlk=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This came up in Vicent=
e&#39;s recent thread on N4560. Since it seems like an
<br>obvious and good idea, and received some initial positive feedback, I
<br>wrote a quick paper.
<br>
<br>The short form is: A function definition whose return type is given as
<br>&#39;auto&#39;, which does not specify a trailing return type, and whic=
h was
<br>previously declared with a known return type, shall use the return type
<br>from the declaration.
<br>
<br>Example:
<br>
<br>=C2=A0 // foo.h
<br>=C2=A0 struct { int id; double value; } foo();
<br>
<br>=C2=A0 // foo.cpp
<br>=C2=A0 auto foo()
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 ...
<br>=C2=A0 =C2=A0 return { id, value };
<br>=C2=A0 }
<br>
<br>Initial copies attached. Online version at:
<br><a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit=
-return-type/PXXXX%20Implicit%20Return%20Type.rst" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-r=
eturn-type%2FPXXXX%2520Implicit%2520Return%2520Type.rst\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGw8_hhMkrYXTozwkr0GFtwtwd1QA&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
mwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-return-type%2FPXXXX%2520Imp=
licit%2520Return%2520Type.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNGw8_hhMkrY=
XTozwkr0GFtwtwd1QA&#39;;return true;">https://github.com/mwoehlke/<wbr>cpp-=
proposals/blob/Pxxx-<wbr>implicit-return-type/PXXXX%<wbr>20Implicit%20Retur=
n%20Type.rst</a>
<br>(As with my previous draft paper, updates posted here will be sporadic
<br>at best. Use the github link to always access the current version.)
<br>
<br>Please let me know what you think.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div><br></div><div>Does this apply to func=
tion templates, whose signature *does* include the return type?</div><div><=
br></div><div>Also, given</div><div><br></div><div class=3D"prettyprint" st=
yle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgro=
und-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ruct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><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"> bar</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span></div></code></div><div><br>=
</div><div>can you write `a =3D bar();`? In C, you can&#39;t, because the t=
wo anonymous structs are distinct, incompatible types. In fact, in C you ca=
n&#39;t even do</div><div><br></div><div class=3D"prettyprint" style=3D"bor=
der: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color:=
 rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</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"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> i</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: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> foo</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: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> abort</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span></div></code></div><div><br></div><div>in the same translation unit.</=
div><div><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); bord=
er-left-style: solid; padding-left: 1ex;">We additionally note that this pr=
ohibition is already not enforced by at least one major compiler (GCC).=C2=
=A0</blockquote><div><br></div><div>This is wrong. All versions of GCC on W=
andbox enforce [dcl.fct]/11, even without -pedantic. The one claimed to wor=
k in GCC 4.5.2 involves lambda return types, not regular functions.</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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_820_224740069.1451515750730--
------=_Part_819_1629266514.1451515750730--

.

------=_Part_707_956241642.1451517717865
Content-Type: multipart/alternative;
 boundary="----=_Part_708_1570742182.1451517717865"

------=_Part_708_1570742182.1451517717865
Content-Type: text/plain; charset=UTF-8

Matthew: I think you are obscuring the subject of your proposal by using an
unnamed struct as the return type in your example. While I would like this
to work, it is a separate proposal subject. There are plenty of other hard
to spell return types out there that we'd like to not have to repeat,
especially with templates and enable_if constructs.

Also, I think that the wording needs to get rid of the ordering idea of
'previous' declaration and instead be worded similarly to how defaulted
argument values are handled, i.e. at least one of the visible declarations
must have a non-auto return type. In contrast with default value
expressions the return type must be allowed to be stated on any number of
declarations, as this is the current way of repeating declarations.

This seems to imply that *if* anonymous struct return is introduced it also
has to be *allowed* to be stated explicitly on more than one delaration,
for reasons of orthogonality. This reasoning should however be part of that
proposal.


Den onsdag 30 december 2015 kl. 23:49:11 UTC+1 skrev T. C.:
>
>
>
> On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:
>>
>> This came up in Vicente's recent thread on N4560. Since it seems like an
>> obvious and good idea, and received some initial positive feedback, I
>> wrote a quick paper.
>>
>> The short form is: A function definition whose return type is given as
>> 'auto', which does not specify a trailing return type, and which was
>> previously declared with a known return type, shall use the return type
>> from the declaration.
>>
>> Example:
>>
>>   // foo.h
>>   struct { int id; double value; } foo();
>>
>>   // foo.cpp
>>   auto foo()
>>   {
>>     ...
>>     return { id, value };
>>   }
>>
>> Initial copies attached. Online version at:
>>
>> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-type/PXXXX%20Implicit%20Return%20Type.rst
>> (As with my previous draft paper, updates posted here will be sporadic
>> at best. Use the github link to always access the current version.)
>>
>> Please let me know what you think.
>>
>> --
>> Matthew
>>
>
>
> Does this apply to function templates, whose signature *does* include the
> return type?
>
> Also, given
>
> struct { int i; } a, foo();
> struct { int i; } bar();
>
> can you write `a = bar();`? In C, you can't, because the two anonymous
> structs are distinct, incompatible types. In fact, in C you can't even do
>
> struct { int i; } foo();
> struct { int i; } foo() { abort(); }
>
> in the same translation unit.
>
> We additionally note that this prohibition is already not enforced by at
>> least one major compiler (GCC).
>
>
> This is wrong. All versions of GCC on Wandbox enforce [dcl.fct]/11, even
> without -pedantic. The one claimed to work in GCC 4.5.2 involves lambda
> return types, not regular functions.
>

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_708_1570742182.1451517717865
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Matthew: I think you are obscuring the subject of your pro=
posal by using an unnamed struct as the return type in your example. While =
I would like this to work, it is a separate proposal subject. There are ple=
nty of other hard to spell return types out there that we&#39;d like to not=
 have to repeat, especially with templates and enable_if constructs.<div><b=
r></div><div>Also, I think that the wording needs to get rid of the orderin=
g idea of &#39;previous&#39; declaration and instead be worded similarly to=
 how defaulted argument values are handled, i.e. at least one of the visibl=
e declarations must have a non-auto return type. In contrast with default v=
alue expressions the return type must be allowed to be stated on any number=
 of declarations, as this is the current way of repeating declarations.</di=
v><div><br></div><div>This seems to imply that <i>if</i>=C2=A0anonymous str=
uct return is introduced it also has to be <i>allowed</i>=C2=A0to be stated=
 explicitly on more than one delaration, for reasons of orthogonality. This=
 reasoning should however be part of that proposal.</div><div><br></div><di=
v><br></div><div>Den onsdag 30 december 2015 kl. 23:49:11 UTC+1 skrev T. C.=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Wednesday, Decembe=
r 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">This came up in Vicente&#39;s recent thread on N4560. Si=
nce it seems like an
<br>obvious and good idea, and received some initial positive feedback, I
<br>wrote a quick paper.
<br>
<br>The short form is: A function definition whose return type is given as
<br>&#39;auto&#39;, which does not specify a trailing return type, and whic=
h was
<br>previously declared with a known return type, shall use the return type
<br>from the declaration.
<br>
<br>Example:
<br>
<br>=C2=A0 // foo.h
<br>=C2=A0 struct { int id; double value; } foo();
<br>
<br>=C2=A0 // foo.cpp
<br>=C2=A0 auto foo()
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 ...
<br>=C2=A0 =C2=A0 return { id, value };
<br>=C2=A0 }
<br>
<br>Initial copies attached. Online version at:
<br><a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit=
-return-type/PXXXX%20Implicit%20Return%20Type.rst" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75=
https%3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-=
return-type%2FPXXXX%2520Implicit%2520Return%2520Type.rst\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGw8_hhMkrYXTozwkr0GFtwtwd1QA&#39;;return true;" onclick=3D=
"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2=
Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-return-type%2FPXXXX%2520Im=
plicit%2520Return%2520Type.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNGw8_hhMkr=
YXTozwkr0GFtwtwd1QA&#39;;return true;">https://github.com/mwoehlke/<wbr>cpp=
-proposals/blob/Pxxx-<wbr>implicit-return-type/PXXXX%<wbr>20Implicit%20Retu=
rn%20Type.rst</a>
<br>(As with my previous draft paper, updates posted here will be sporadic
<br>at best. Use the github link to always access the current version.)
<br>
<br>Please let me know what you think.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div><br></div><div>Does this apply to func=
tion templates, whose signature *does* include the return type?</div><div><=
br></div><div>Also, given</div><div><br></div><div style=3D"border:1px soli=
d rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)">=
<code><div><span style=3D"color:#008">struct</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">int</span><span style=3D"color:#000"> i</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"> a</span><span=
 style=3D"color:#660">,</span><span style=3D"color:#000"> foo</span><span s=
tyle=3D"color:#660">();</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#008">struct</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> i</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"> bar</span><span style=3D"col=
or:#660">();</span></div></code></div><div><br></div><div>can you write `a =
=3D bar();`? In C, you can&#39;t, because the two anonymous structs are dis=
tinct, incompatible types. In fact, in C you can&#39;t even do</div><div><b=
r></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wor=
d;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">=
struct</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</=
span><span style=3D"color:#000"> i</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><spa=
n style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">struct</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"c=
olor:#000"> foo</span><span style=3D"color:#660">()</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"> abort</span><span style=3D"color:#660">();</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">}</span></div></code></div><div><=
br></div><div>in the same translation unit.</div><div><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
We additionally note that this prohibition is already not enforced by at le=
ast one major compiler (GCC).=C2=A0</blockquote><div><br></div><div>This is=
 wrong. All versions of GCC on Wandbox enforce [dcl.fct]/11, even without -=
pedantic. The one claimed to work in GCC 4.5.2 involves lambda return types=
, not regular functions.</div></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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_708_1570742182.1451517717865--
------=_Part_707_956241642.1451517717865--

.

------=_Part_1343_1353255786.1451527741796
Content-Type: multipart/alternative;
 boundary="----=_Part_1344_950448126.1451527741796"

------=_Part_1344_950448126.1451527741796
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 5:24:06 PM UTC-5, T. C. wrote:
>
> On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:
>>
>>
>> I realize that there's kinda a parser here here. Namely, that the above
>> already has a well-defined meaning: it declares a variable named `foo` of
>> an anonymous type, and default initializes it.
>>
>>
> No, it doesn't. This is currently unambiguously parsed as an (ill-formed)
> function declaration, because `()` is not a valid *initializer *in the
> grammar.
>

So, until C++11 introduced braced-init-lists, there was no way to
value-initialize an anonymous struct? Huh.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1344_950448126.1451527741796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 30, 2015 at 5:24:06 PM UTC-5, T. C.=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Wed=
nesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I realize that ther=
e&#39;s kinda a parser here here. Namely, that the above already has a well=
-defined meaning: it declares a variable named `foo` of an anonymous type, =
and default initializes it.</div><br></div></blockquote><div><br></div><div=
>No, it doesn&#39;t. This is currently unambiguously parsed as an (ill-form=
ed) function declaration, because `()` is not a valid <i>initializer </i>in=
 the grammar.</div></div></blockquote><div><br>So, until C++11 introduced b=
raced-init-lists, there was no way to value-initialize an anonymous struct?=
 Huh.<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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1344_950448126.1451527741796--
------=_Part_1343_1353255786.1451527741796--

.

On 31 December 2015 at 04:09, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 30, 2015 at 5:24:06 PM UTC-5, T. C. wrote:
>>
>> On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:
>>>
>>>
>>> I realize that there's kinda a parser here here. Namely, that the above
>>> already has a well-defined meaning: it declares a variable named `foo` of an
>>> anonymous type, and default initializes it.
>>>
>>
>> No, it doesn't. This is currently unambiguously parsed as an (ill-formed)
>> function declaration, because `()` is not a valid initializer in the
>> grammar.
>
>
> So, until C++11 introduced braced-init-lists, there was no way to
> value-initialize an anonymous struct? Huh.


I thought the point was that you weren't able to paren-initialize a named object
of type of an anonymous struct. Immediately paren-initializing a temporary
of type of an anonymous struct seems different to me. Of course, I may
be mistaken
since I'm not quite sure what we're talking about here, example-wise
or specification-wise
or otherwise. :)

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------010206070306090702070409
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 30/12/2015 23:49, T. C. a =C3=A9crit :
>
>
> On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew Woehlke=20
> wrote:
>
>     This came up in Vicente's recent thread on N4560. Since it seems
>     like an
>     obvious and good idea, and received some initial positive feedback, I
>     wrote a quick paper.
>
>     The short form is: A function definition whose return type is
>     given as
>     'auto', which does not specify a trailing return type, and which was
>     previously declared with a known return type, shall use the return
>     type
>     from the declaration.
>
>     Example:
>
>       // foo.h
>       struct { int id; double value; } foo();
>
>       // foo.cpp
>       auto foo()
>       {
>         ...
>         return { id, value };
>       }
>
>     Initial copies attached. Online version at:
>     https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-t=
ype/PXXXX%20Implicit%20Return%20Type.rst
>     <https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-=
type/PXXXX%20Implicit%20Return%20Type.rst>
>
>     (As with my previous draft paper, updates posted here will be
>     sporadic
>     at best. Use the github link to always access the current version.)
>
>     Please let me know what you think.
>
>     --=20
>     Matthew
>
>
>
> Does this apply to function templates, whose signature *does* include=20
> the return type?
Could you give an example?
>
> Also, given
>
> |
> struct{inti;}a,foo();
> struct{inti;}bar();
> |
>
> can you write `a =3D bar();`? In C, you can't, because the two anonymous=
=20
> structs are distinct, incompatible types. In fact, in C you can't even do
>
> |
> struct{inti;}foo();
> struct{inti;}foo(){abort();}
> |
>
> in the same translation unit.
I know. Please, let discuss this subject on the other thread.

Vicente

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------010206070306090702070409
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 30/12/2015 23:49, T. C. a =C3=A9crit=
=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:96b4bcd6-5bc2-4906-bb6e-fd60d684bb4a@isocpp.org"
      type=3D"cite"><br>
      <br>
      On Wednesday, December 30, 2015 at 3:54:38 PM UTC-5, Matthew
      Woehlke wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This came
        up in Vicente's recent thread on N4560. Since it seems like an
        <br>
        obvious and good idea, and received some initial positive
        feedback, I
        <br>
        wrote a quick paper.
        <br>
        <br>
        The short form is: A function definition whose return type is
        given as
        <br>
        'auto', which does not specify a trailing return type, and which
        was
        <br>
        previously declared with a known return type, shall use the
        return type
        <br>
        from the declaration.
        <br>
        <br>
        Example:
        <br>
        <br>
        =C2=A0 // foo.h
        <br>
        =C2=A0 struct { int id; double value; } foo();
        <br>
        <br>
        =C2=A0 // foo.cpp
        <br>
        =C2=A0 auto foo()
        <br>
        =C2=A0 {
        <br>
        =C2=A0 =C2=A0 ...
        <br>
        =C2=A0 =C2=A0 return { id, value };
        <br>
        =C2=A0 }
        <br>
        <br>
        Initial copies attached. Online version at:
        <br>
        <a moz-do-not-send=3D"true"
href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return=
-type/PXXXX%20Implicit%20Return%20Type.rst"
          target=3D"_blank" rel=3D"nofollow"
          onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-return=
-type%2FPXXXX%2520Implicit%2520Return%2520Type.rst\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNGw8_hhMkrYXTozwkr0GFtwtwd1QA';return
          true;"
          onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-implicit-return-typ=
e%2FPXXXX%2520Implicit%2520Return%2520Type.rst\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNGw8_hhMkrYXTozwkr0GFtwtwd1QA';return
          true;">https://github.com/mwoehlke/<wbr>cpp-proposals/blob/Pxxx-<=
wbr>implicit-return-type/PXXXX%<wbr>20Implicit%20Return%20Type.rst</a>
        <br>
        (As with my previous draft paper, updates posted here will be
        sporadic
        <br>
        at best. Use the github link to always access the current
        version.)
        <br>
        <br>
        Please let me know what you think.
        <br>
        <br>
        -- <br>
        Matthew
        <br>
      </blockquote>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>Does this apply to function templates, whose signature *does*
        include the return type?</div>
    </blockquote>
    Could you give an example?<br>
    <blockquote
      cite=3D"mid:96b4bcd6-5bc2-4906-bb6e-fd60d684bb4a@isocpp.org"
      type=3D"cite">
      <div><br>
      </div>
      <div>Also, given</div>
      <div><br>
      </div>
      <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
        187); word-wrap: break-word; background-color: rgb(250, 250,
        250);"><code class=3D"prettyprint">
          <div class=3D"subprettyprint"><span style=3D"color: #008;"
              class=3D"styled-by-prettify">struct</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"> </span><=
span
              style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> i</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: #660;" class=3D"styled-by-prettify">}</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> a</span>=
<span
              style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><span
              style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">struct</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"> </span><=
span
              style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> i</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: #660;" class=3D"styled-by-prettify">}</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> bar</spa=
n><span
              style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
></div>
        </code></div>
      <div><br>
      </div>
      <div>can you write `a =3D bar();`? In C, you can't, because the two
        anonymous structs are distinct, incompatible types. In fact, in
        C you can't even do</div>
      <div><br>
      </div>
      <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
        187); word-wrap: break-word; background-color: rgb(250, 250,
        250);"><code class=3D"prettyprint">
          <div class=3D"subprettyprint"><span style=3D"color: #008;"
              class=3D"styled-by-prettify">struct</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"> </span><=
span
              style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> i</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: #660;" class=3D"styled-by-prettify">}</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><span
              style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">struct</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"> </span><=
span
              style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> i</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: #660;" class=3D"styled-by-prettify">}</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><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: #660;" class=3D"styled-by-prettify">{</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> abort</s=
pan><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: #660;" class=3D"styled-by-prettify">}</span><=
/div>
        </code></div>
      <div><br>
      </div>
      <div>in the same translation unit.</div>
    </blockquote>
    I know. Please, let discuss this subject on the other thread.<br>
    <br>
    Vicente<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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------010206070306090702070409--

.

This is a multi-part message in MIME format.
--------------090000010301080706020404
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 31/12/2015 00:21, Bengt Gustafsson a =C3=A9crit :
> Matthew: I think you are obscuring the subject of your proposal by=20
> using an unnamed struct as the return type in your example. While I=20
> would like this to work, it is a separate proposal subject. There are=20
> plenty of other hard to spell return types out there that we'd like to=20
> not have to repeat, especially with templates and enable_if constructs.
>
> Also, I think that the wording needs to get rid of the ordering idea=20
> of 'previous' declaration and instead be worded similarly to how=20
> defaulted argument values are handled, i.e. at least one of the=20
> visible declarations must have a non-auto return type. In contrast=20
> with default value expressions the return type must be allowed to be=20
> stated on any number of declarations, as this is the current way of=20
> repeating declarations.
>
> This seems to imply that /if/ anonymous struct return is introduced it=20
> also has to be /allowed/ to be stated explicitly on more than one=20
> delaration, for reasons of orthogonality. This reasoning should=20
> however be part of that proposal.
>
I agree and believed that it was clear that this feature is independent=20
of allowing the definition of structs in the return type of a functions,=20
even if the last would benefit from the first.

Vicente

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------090000010301080706020404
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 31/12/2015 00:21, Bengt Gustafsson a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:38b3a3be-a662-43bc-844d-30019c3f4713@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Matthew: I think you are obscuring the subject of
        your proposal by using an unnamed struct as the return type in
        your example. While I would like this to work, it is a separate
        proposal subject. There are plenty of other hard to spell return
        types out there that we'd like to not have to repeat, especially
        with templates and enable_if constructs.
        <div><br>
        </div>
        <div>Also, I think that the wording needs to get rid of the
          ordering idea of 'previous' declaration and instead be worded
          similarly to how defaulted argument values are handled, i.e.
          at least one of the visible declarations must have a non-auto
          return type. In contrast with default value expressions the
          return type must be allowed to be stated on any number of
          declarations, as this is the current way of repeating
          declarations.</div>
        <div><br>
        </div>
        <div>This seems to imply that <i>if</i>=C2=A0anonymous struct retur=
n
          is introduced it also has to be <i>allowed</i>=C2=A0to be stated
          explicitly on more than one delaration, for reasons of
          orthogonality. This reasoning should however be part of that
          proposal.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    I agree and believed that it was clear that this feature is
    independent of allowing the definition of structs in the return type
    of a functions, even if the last would benefit from the first.<br>
    <br>
    Vicente<br>
    <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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------090000010301080706020404--

.

------=_Part_6716_493632422.1451565854571
Content-Type: multipart/alternative;
 boundary="----=_Part_6717_476477681.1451565854571"

------=_Part_6717_476477681.1451565854571
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 30/12/2015 23:49, T. C. a =C3=A9crit :
>
>
> Does this apply to function templates, whose signature *does* include the=
=20
> return type?
>
> Could you give an example?
>

This is currently legal and declares two separate function templates:

template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
template<class T> auto foo();

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

------=_Part_6717_476477681.1451565854571
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, December 31, 2015 at 1:06:13 AM UTC-5=
, Vicente J. Botet Escriba wrote:<blockquote class=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">
    <div>Le 30/12/2015 23:49, T. C. a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"><div><br>
      </div>
      <div>Does this apply to function templates, whose signature *does*
        include the return type?</div>
    </blockquote>
    Could you give an example?<br></div></blockquote><div><br></div><div>Th=
is is currently legal and declares two separate function templates:</div><d=
iv><br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187,=
 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
nable_if_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" class=3D"=
styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&gt;{}&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6717_476477681.1451565854571--
------=_Part_6716_493632422.1451565854571--

.

On 2015-12-30 17:24, T. C. wrote:
> On Wednesday, December 30, 2015 at 5:20:57 PM UTC-5, Nicol Bolas wrote:
>> I realize that there's kinda a parser here here. Namely, that the above
>> already has a well-defined meaning: it declares a variable named `foo` of
>> an anonymous type, and default initializes it.
>
> No, it doesn't. This is currently unambiguously parsed as an (ill-formed)
> function declaration, because `()` is not a valid *initializer *in the
> grammar.

FWIW, GCC agrees; given:

  struct { int result; } foo();

....it complains about a new type defined as a return type.

(Also, I could've sworn I'd tested GCC and it *did* allow new types as
return types... huh... replaced GCC with MSVC in the relevant sentence.)

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-30 17:49, T. C. wrote:
> Also, given
>
> struct { int i; } a, foo();
> struct { int i; } bar();
>
> can you write `a = bar();`?

No. (See also Vicente's thread for further discussion.) This has been
requested, but TBH I don't find this behavior desirable.

> In fact, in C you can't even do
>
> struct { int i; } foo();
> struct { int i; } foo() { abort(); }
>
> in the same translation unit.

Nor in C++, even with this proposal. This is specifically the problem
that the implied return type portion of the proposal (which I still
consider the "main" part) is intended to address, by providing a way to
write the return type the second time that avoids creating a second new
type.

>> We additionally note that this prohibition is already not enforced by at
>> least one major compiler (GCC).
>
> This is wrong. All versions of GCC on Wandbox enforce [dcl.fct]/11, even
> without -pedantic. The one claimed to work in GCC 4.5.2 involves lambda
> return types, not regular functions.

Yes, my mistake. Fixed.

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-30 18:21, Bengt Gustafsson wrote:
> Matthew: I think you are obscuring the subject of your proposal by using =
an=20
> unnamed struct as the return type in your example. While I would like thi=
s=20
> to work, it is a separate proposal subject. There are plenty of other har=
d=20
> to spell return types out there that we'd like to not have to repeat,=20
> especially with templates and enable_if constructs.

As noted, I considered this point. I'm also open to considering it more.
However, the case of anonymous structs is currently the most motivating
in my mind, probably because it's an obvious example, and I lack an
obvious example that does *not* use anonymous structs. Perhaps you or
someone else could provide one?

> Also, I think that the wording needs to get rid of the ordering idea of=
=20
> 'previous' declaration and instead be worded similarly to how defaulted=
=20
> argument values are handled, i.e. at least one of the visible declaration=
s=20
> must have a non-auto return type.

I understand your desire, but I am concerned this would make things very
difficult for the compiler. The compiler would have to either implement
an additional parsing pass in order to resolve the return type, or else
delay compiling anything that uses the incomplete declaration until it
finds a complete declaration.

> In contrast with default value=20
> expressions the return type must be allowed to be stated on any number of=
=20
> declarations, as this is the current way of repeating declarations.

Um... I don't think it works this way... Consider:

  int foo(int x) { return x; }
  int bar() { return foo(); } // error: too few parameters
  int foo(int x =3D 0);

Maybe it would work to allow a declaration with 'auto' return type (and
no trailing return type specification), but to make such a declaration
"incomplete"? However, I don't see what benefit this would provide.
(Maybe some template corner case? Again, an example would be helpful...)

I'm open to changes that are simply *wording* improvements without
changing the requirement that an inferred return type is only legal when
the compiler has already parsed a declaration that provided a concrete
return type.

> This seems to imply that *if* anonymous struct return is introduced it al=
so=20
> has to be *allowed* to be stated explicitly on more than one delaration,=
=20
> for reasons of orthogonality. This reasoning should however be part of th=
at=20
> proposal.

....why? The whole point of IRTVPDUA=C2=B9 with anonymous structs is to work
around that you *can't* define the return type more than once.

I've tried to make it clear that relaxing [dcl.fct]/11 is dependent (at
least from a practical standpoint) on IRTVPDUA, but not vice versa.

(=C2=B9 That's "Inferred Return Type Via Previous Declaration, Using Auto" =
if
you aren't reading the other thread also.)

--=20
Matthew

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_396_824196757.1451577637559
Content-Type: multipart/alternative;
 boundary="----=_Part_397_1407440290.1451577637559"

------=_Part_397_1407440290.1451577637559
Content-Type: text/plain; charset=UTF-8

On Thursday, December 31, 2015 at 10:45:08 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-30 18:21, Bengt Gustafsson wrote:
> > Matthew: I think you are obscuring the subject of your proposal by using
> an
> > unnamed struct as the return type in your example. While I would like
> this
> > to work, it is a separate proposal subject. There are plenty of other
> hard
> > to spell return types out there that we'd like to not have to repeat,
> > especially with templates and enable_if constructs.
>
> As noted, I considered this point. I'm also open to considering it more.
> However, the case of anonymous structs is currently the most motivating
> in my mind, probably because it's an obvious example, and I lack an
> obvious example that does *not* use anonymous structs. Perhaps you or
> someone else could provide one?
>

Really, anything with a long typename that you don't intend to inline in a
header file is a reasonable example. For instance:

std::vector<MyNamespace::MyType>::const_iterator FuncName(...);

Even for short names, Don't Repeat Yourself is a good thing. It's part of
the reason why we have auto-deduced return types to begin with.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_397_1407440290.1451577637559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 31, 2015 at 10:45:08 AM UTC-5, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-30 18:21, Bengt Gus=
tafsson wrote:
<br>&gt; Matthew: I think you are obscuring the subject of your proposal by=
 using an=20
<br>&gt; unnamed struct as the return type in your example. While I would l=
ike this=20
<br>&gt; to work, it is a separate proposal subject. There are plenty of ot=
her hard=20
<br>&gt; to spell return types out there that we&#39;d like to not have to =
repeat,=20
<br>&gt; especially with templates and enable_if constructs.
<br>
<br>As noted, I considered this point. I&#39;m also open to considering it =
more.
<br>However, the case of anonymous structs is currently the most motivating
<br>in my mind, probably because it&#39;s an obvious example, and I lack an
<br>obvious example that does *not* use anonymous structs. Perhaps you or
<br>someone else could provide one?<br></blockquote><div><br>Really, anythi=
ng with a long typename that you don&#39;t intend to inline in a header fil=
e is a reasonable example. For instance:<br><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;"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">MyNamespace</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">MyType</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cons=
t_iterator </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>FuncName</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
....);</span></div></code></div><br>Even for short names, Don&#39;t Repeat Y=
ourself is a good thing. It&#39;s part of the reason why we have auto-deduc=
ed return types to begin with.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_397_1407440290.1451577637559--
------=_Part_396_824196757.1451577637559--

.

On 2015-12-31 07:44, T. C. wrote:
> This is currently legal and declares two separate function templates:
>
> template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
> template<class T> auto foo();

Okay, wow... now my head hurts... Just *how* exactly am I supposed to
distinguish between these?

This... seems broken.

Suggestions how to address this welcome...

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------060701090101000404030807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 31/12/2015 13:44, T. C. a =C3=A9crit :
>
>
> On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 30/12/2015 23:49, T. C. a =C3=A9crit :
>>
>>     Does this apply to function templates, whose signature *does*
>>     include the return type?
>     Could you give an example?
>
>
> This is currently legal and declares two separate function templates:
>
> |
> template<classT>std::enable_if_t<std::is_same<T,int>{}>foo();
> template<classT>autofoo();
> |
>
>
With concepts this would be

|
template<classT>requires std::is_same<T,int>{}void foo();
template<classT>|requires std::is_same<T,int>{}|autofoo();
|

Would this define two templates? I don't think so.

Do you have another example?

Vicente

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------060701090101000404030807
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 31/12/2015 13:44, T. C. a =C3=A9crit=
=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:115ea92e-fb51-47c0-8a0d-67516dca0675@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J.
        Botet Escriba 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">
            <div>Le 30/12/2015 23:49, T. C. a =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div><br>
              </div>
              <div>Does this apply to function templates, whose
                signature *does* include the return type?</div>
            </blockquote>
            Could you give an example?<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>This is currently legal and declares two separate function
          templates:</div>
        <div><br>
        </div>
        <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
          187); word-wrap: break-word; background-color: rgb(250, 250,
          250);"><code class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #008;" class=3D"styled-by-prettify">class</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span
                style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span
                style=3D"color: #000;" class=3D"styled-by-prettify">enable_=
if_t</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify">std</sp=
an><span
                style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span
                style=3D"color: #000;" class=3D"styled-by-prettify">is_same=
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" class=3D"styled-by-prettify">int</sp=
an><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}&=
gt;</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span
                style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #008;" class=3D"styled-by-prettify">class</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span
                style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span></div>
          </code></div>
        <div><br>
        </div>
      </div>
      <br>
    </blockquote>
    With concepts this would be<br>
    <br>
    <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
      187); word-wrap: break-word; background-color: rgb(250, 250,
      250);"><code class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #008;"
            class=3D"styled-by-prettify">template</span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span
            style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><s=
pan
            style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span
            style=3D"color: #000;" class=3D"styled-by-prettify"> requires <=
/span><span
            style=3D"color: #000;" class=3D"styled-by-prettify">std</span><=
span
            style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan
            style=3D"color: #000;" class=3D"styled-by-prettify">is_same</sp=
an><span
            style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span
            style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span
            style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}</spa=
n><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> void foo</=
span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">();</span><=
span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
template</span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span
            style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><s=
pan
            style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><co=
de
            class=3D"prettyprint"><span style=3D"color: #000;"
              class=3D"styled-by-prettify">requires </span><span
              style=3D"color: #000;" class=3D"styled-by-prettify">std</span=
><span
              style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span
              style=3D"color: #000;" class=3D"styled-by-prettify">is_same</=
span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}</s=
pan><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
/code><span
            style=3D"color: #008;" class=3D"styled-by-prettify">auto</span>=
<span
            style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span>=
<span
            style=3D"color: #660;" class=3D"styled-by-prettify">();</span><=
span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span></div>
      </code></div>
    <div><br>
    </div>
    Would this define two templates? I don't think so.<br>
    <br>
    Do you have another example?<br>
    <br>
    Vicente<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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------060701090101000404030807--

.

------=_Part_363_476017945.1451584190157
Content-Type: multipart/alternative;
 boundary="----=_Part_364_695993502.1451584190158"

------=_Part_364_695993502.1451584190158
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, December 31, 2015 at 12:39:33 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 31/12/2015 13:44, T. C. a =C3=A9crit :
>
>
>
> On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:=20
>>
>> Le 30/12/2015 23:49, T. C. a =C3=A9crit :
>>
>>
>> Does this apply to function templates, whose signature *does* include th=
e=20
>> return type?
>>
>> Could you give an example?
>>
>
> This is currently legal and declares two separate function templates:
>
> template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
> template<class T> auto foo();
>
>
> With concepts this would be
>
> template<class T> requires std::is_same<T, int>{} void foo();
> template<class T> requires std::is_same<T, int>{} auto foo();
>
>
The second foo wasn't constrained. You added one.
=20
Regardless, GCC trunk - the only concepts implementation I know of - is=20
perfectly happy to compile
#include <type_traits>
template<class T> requires std::is_same<T, int>::value void foo() { }
template<class T> requires std::is_same<T, int>::value auto foo() { return =
1
; }

int (*p)() =3D foo<int>;
void (*pp)() =3D foo<int>;

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

------=_Part_364_695993502.1451584190158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, December 31, 2015 at 12:39:33 PM UTC-5, Vicente J. Bot=
et Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 31/12/2015 13:44, T. C. a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 30/12/2015 23:49, T. C. a =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div><br>
              </div>
              <div>Does this apply to function templates, whose
                signature *does* include the return type?</div>
            </blockquote>
            Could you give an example?<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>This is currently legal and declares two separate function
          templates:</div>
        <div><br>
        </div>
        <div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wor=
d;background-color:rgb(250,250,250)"><code>
            <div><span style=3D"color:#008">template</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#008">class</span><span style=3D=
"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"=
color:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"c=
olor:#000">enable_if_t</span><span style=3D"color:#660">&lt;</span><span st=
yle=3D"color:#000">std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">is_same</span><span style=3D"color:#660">&lt;</span><span =
style=3D"color:#000"><wbr>T</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#660">&gt;{}&gt;</span><span style=3D"color:#000"> foo</span><s=
pan style=3D"color:#660">();</span><span style=3D"color:#000"><br>
              </span><span style=3D"color:#008">template</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> foo</span><span style=3D"color:#660">();</span><span style=
=3D"color:#000"><br>
              </span></div>
          </code></div>
        <div><br>
        </div>
      </div>
      <br>
    </blockquote>
    With concepts this would be<br>
    <br>
    <div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code>
        <div><span style=3D"color:#008">template</span><span style=3D"color=
:#660">&lt;</span><span style=3D"color:#008">class</span><span style=3D"col=
or:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"colo=
r:#000"> requires </span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">is_same</span><span sty=
le=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">int</span><span style=3D"color:#660">&gt;{}</span><span style=3D=
"color:#000"> void foo</span><span style=3D"color:#660">();</span><span sty=
le=3D"color:#000"><br>
          </span><span style=3D"color:#008">template</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#008">class</span><span style=3D=
"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"=
color:#000"> </span><code><span style=3D"color:#000">requires </span><span =
style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span st=
yle=3D"color:#000">is_same</span><span style=3D"color:#660">&lt;</span><spa=
n style=3D"color:#000">T</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=
=3D"color:#660">&gt;{}</span><span style=3D"color:#000"> </span></code><spa=
n style=3D"color:#008">auto</span><span style=3D"color:#000"> foo</span><sp=
an style=3D"color:#660">();</span><span style=3D"color:#000"><br>
          </span></div>
      </code></div>
    <div><br></div></div></blockquote><div><br></div><div>The second foo wa=
sn&#39;t constrained. You added one.</div><div>=C2=A0</div><div>Regardless,=
 GCC trunk - the only concepts implementation I know of - is perfectly happ=
y to compile</div><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250=
);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">&lt;type_traits&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> requires std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">is_same</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">value </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> foo</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: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> requires std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">is_same</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">T</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: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">value </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> foo</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: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #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><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
p</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">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color:=
 #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>pp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)()</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span></div></code></div><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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_364_695993502.1451584190158--
------=_Part_363_476017945.1451584190157--

.

On 2015-12-31 11:16, Matthew Woehlke wrote:
> On 2015-12-31 07:44, T. C. wrote:
>> This is currently legal and declares two separate function templates:
>>
>> template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
>> template<class T> auto foo();
>
> Okay, wow... now my head hurts... Just *how* exactly am I supposed to
> distinguish between these?
>
> This... seems broken.
>
> Suggestions how to address this welcome...

Better question: if those declare two separate templates, you are never
going to be able to use either one due to ambiguity. Would it be
acceptable to just say that, no, the second one repeats the first?
(Actually, I believe this is what my current proposed wording would do;
if that's not acceptable, a) why not? and b) can someone propose wording
to avoid this particular issue?)

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------030403040308090000070304
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2015-12-30 15:54, Matthew Woehlke wrote:
> This came up in Vicente's recent thread on N4560. Since it seems like an
> obvious and good idea, and received some initial positive feedback, I
> wrote a quick paper.
>=20
> The short form is: A function definition whose return type is given as
> 'auto', which does not specify a trailing return type, and which was
> previously declared with a known return type, shall use the return type
> from the declaration.

Updated. Included in the changes, I have (proposed to) remove(d) the
restriction in [dcl.spec.auto]/13 against replacing a placeholder type
with a concrete type. I think this addresses Bengt's concerns regarding
declaration ordering, and is IMHO important for the sake of consistency.
(Also, because I don't see why that restriction exists in the first place.)

I have also added proposed wording. Comments (ignoring for now the
question whether to make it a separate proposal) re: [dcl.fct]/11 are
especially welcome, as the entire change is the removal of two words.
Offhand, it seems like this is all that's needed, but I would very much
appreciate others' input.

As always, the most recent version=C2=B9 can be found at
https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-implicit-return-type/PX=
XXX%20Implicit%20Return%20Type.rst

(=C2=B9 Caveat: github unfortunately strips some reST elements that are
critical to the formatting of the proposed wording section, making it
effectively impossible to read this section without looking at the reST
source. The attached HTML is generated offline and does not have this
issue.)

--=20
Matthew

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------030403040308090000070304
Content-Type: text/prs.fallenstein.rst;
 name="PXXXX Implicit Return Type.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.rst"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Implicit Return Type
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

:Document:  PXXXX (TBD)
:Date:      2015-12-31
:Author:    Matthew Woehlke (mwoehlke.floss@gmail.com)

=2E. raw:: html

  <style>
    html { color: black; background: white; }
    table.docinfo { margin: 2em 0; }
    .literal-block { background: #eee; border: 1px solid #ddd; padding: 0=
=2E5em; }
    .addition { color: #2c2; text-decoration: underline; }
    .removal { color: #e22; text-decoration: line-through; }
    .literal-block .literal-block { background: none; border: none; }
    .block-addition { background: #cfc; text-decoration: underline; }
  </style>

=2E. role:: add
    :class: addition

=2E. role:: del
    :class: removal

Abstract
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal recommends an enhancement to return type deduction to allow=
 the return type of a function definition to be inferred from a previous =
declaration of the same.

(Note: references made to the existing draft standard are made against N4=
567_.)

=2E. contents::


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

The concept of multiple return values is well known. At present, however,=
 C++ lacks a good mechanism for implementing the same. ``std::tuple`` is =
considered clunky by many and, critically, creates sub-optimal API by vir=
tue of the returned values being unnamed, forcing developers to rely on s=
upplemental documentation to explain their purpose. Aggregates represent =
an improvement, being self-documenting, but the need to provide external =
definitions of the same is awkward and, worse, pollutes their correspondi=
ng namespace with entities that may be single use. Proposals such as N456=
0_ present a complicated mechanism for providing tagged (self-documenting=
) tuple-like types, which may be necessary in some cases, but still repre=
sent a non-trivial amount of complexity that ideally should not be requir=
ed.

Proposals such as P0144_ (or its competitor P0151_) in particular would r=
epresent a significant step toward support of multiple return values as f=
irst class citizens. These proposals and other current directions show an=
 encouraging movement away from the traditional ``std::pair`` and ``std::=
tuple`` towards comparable concepts without requiring the explicit types.=
 (We expect, however, that these will remain useful for algorithms where =
the identity of the elements is unimportant, while it *is* important to b=
e able to name at least the outer, if not complete, type. In that respect=
, we hypothesize that we may in the future see the ability to construct a=
 ``std::tuple`` from any tuple-like.) On their own, however, these propos=
als risk exacerbating the problem that this proposal aims to address.

It has been suggested on multiple occasions that the optimal solution to =
the above issues is to return an anonymous ``struct``. This solves the pr=
oblems of clutter and self-documentation, but runs afoul of a much worse =
issue; because the ``struct`` is *anonymous*, it can be difficult to impo=
ssible to give its name a second time in order to separate the declaratio=
n and definition of the function that wishes to use it.

However, in C++, functions cannot be overloaded by their return value. Th=
is leads to an obvious question: **why is it necessary to repeat the retu=
rn value at all?**

Even in the case of return types that can be named, it may be that repeat=
ing the type name is excessively verbose or otherwise undesirable. Some m=
ight even call this a violation of the `Don't Repeat Yourself <https://en=
=2Ewikipedia.org/wiki/Don't_repeat_yourself>`_ principle, similar to some=
 of the issues that ``auto`` for variable declaration was introduced to s=
olve. (On the flip side, one could see the ability to elide the return ty=
pe as subject to many abuses, again in much the manner of ``auto``. Howev=
er, many language features can be abused; this should not prevent the add=
ition of a feature that would provide an important benefit when used corr=
ectly.)

We would be remiss not to note that this is already possible in simple ca=
ses using ``decltype`` and a sample invocation of the function. However, =
while this may be adequate in simple cases, it is nevertheless needlessly=
 verbose, and as the argument list grows longer, and/or gains arguments f=
or which providing a legal value is non-trivial, it can quickly become un=
wieldy and unfeasible.


Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

Recent changes to the language have progressively relaxed the requirement=
s for how return types are specified. We began with trailing return type =
specification, and have progressed to inferred return types in certain ca=
ses.

This proposal is to continue this direction by adding an additional use o=
f ``auto`` as a return specifier, meaning "use the return type seen when =
this function was previously declared". This provides an optimal solution=
 to the following problem:

=2E. code:: c++

  // foo.h
  struct { int id; double value; } foo();

How does one now provide an external definition for ``foo()``? We propose=
:

=2E. code:: c++

  // foo.cpp
  auto foo()
  {
    ...
    return { id, value };
  }

The use of ``auto`` as the return type specifier, with no trailing return=
 type, and for a function that has been previously declared with a known =
return type, shall instruct the compiler to define the function using the=
 return type from the previous declaration. (Note that this works for *an=
y* type, not just anonymous ``struct``\ s.)

Naturally, "previous declaration" here means a declaration having the sam=
e name and argument list. This, for example, would remain illegal:

=2E. code:: c++

  struct { int id; int value; } foo(int);
  struct { int id; float value; } foo(float);

  auto foo(double input) // does not match any previous declaration
  {
    ...
    return { id, result };
  }

Since this has implications with respect to return type deduction, we add=
itionally propose an alteration to [dcl.spec.auto]/13; specifically, a pr=
evious declaration that used a placeholder type for the return type may n=
ow be redeclared or defined using a concrete type (iff the concrete type =
is compatible with the placeholder type). Doing so shall resolve the plac=
eholder type to the concrete type.

Additionally, and for obvious reasons, we propose to remove the prohibiti=
on ([dcl.fct]/11) against defining types in return type specifications. W=
e additionally note that this prohibition is already not enforced by at l=
east one major compiler (MSVC). We further believe this prohibition to be=
 outdated; it made sense in C++98, but with recent changes such as the ad=
dition of ``decltype`` and the ability to omit the type name in a ``retur=
n`` statement returning an in-place constructed class, the reasons for th=
e prohibition have been greatly mitigated. This other part of this propos=
al would largely remove any remaining motivation for the prohibition.


Proposed Wording
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(Proposed changes are specified relative N4567_.)

Change [dcl.spec.auto]/13 (7.1.6.4.13) as follows:

=2E. compound::
  :class: literal-block

  Redeclarations or specializations of a function or function template wi=
th a declared return type that uses a placeholder type shall :del:`also u=
se that placeholder` :add:`use either that placeholder or a compatible co=
ncrete type`, not a deduced type. :add:`If the return type has previously=
 been deduced, a declaration using a concrete type shall use the deduced =
type.`
  [*Example:*

  .. parsed-literal::

    auto f();
    auto f() { return 42; } // return type is int
    auto f(); // OK
    :del:`int f(); // error, cannot be overloaded with auto f()`
    :add:`int f(); // OK, deduced type is also int`
    decltype(auto) f(); // error, auto and decltype(auto) don't match

    :add:`auto f(int);`
    :add:`int f(int); // OK, return type of f(int) is now int`
    :add:`float f(int); // error, redeclared with different return type`

Add a new section to [dcl.spec.auto] (7.1.6.4) as follows:

=2E. compound::
  :class: literal-block block-addition

  When a function is declared or defined using a placeholder type for the=
 return type, and a previous declaration or definition having a concrete =
return type exists, the return type shall be inferred to be the previousl=
y seen concrete type.
  [*Example:*

  .. parsed-literal::

    std::string f();
    auto f(); // OK, return type is std::string

  |--| *end example*]

Change [dcl.fct]/11 (8.3.5.11) as follows:

=2E. compound::
  :class: literal-block

  Types shall not be defined in :del:`return or` parameter types.

Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

An obvious follow-on question is, should we also lift the prohibition aga=
inst types defined in parameter specifications? There have been suggestio=
ns floated to implement the much requested named parameters in something =
like this manner. However, there are significant (in our opinion) reasons=
 to not address this, at least initially. First, it is widely contested t=
hat this is not an optimal solution to the problem (named parameters) in =
the first place. Second, it depends on named initializers, which is an ar=
ea of ongoing work. Third, this proposal works largely because C++ forbid=
s overloading on return type, which may be leveraged to eliminate any amb=
iguity as to the deduction of the actual type of ``auto``; this is not th=
e case for parameters, and so permitting ``auto`` as a parameter type spe=
cifier would quickly run into issues that can be avoided for the return t=
ype case.

While we do not wish to categorically rule out future changes in this dir=
ection, we feel that it is not appropriate for this proposal to attempt t=
o address these issues.

On a related note, it is not strictly necessary for the sake of the added=
 utility of implied return type to relax [dcl.fct]/11. However, much of t=
he benefit is lost with this prohibition in place. Conversely, simply rel=
axing the prohibition is of significantly less benefit without the propos=
ed implied return type feature. Accordingly, while we considered splittin=
g the two changes into separate proposals, we have decided for now to kee=
p them together.

Another question that has come up is if something like this should be all=
owed:

=2E. code:: c++

  struct { int result; } foo() { ... }
  struct { int result; } bar()
  {
    return foo();
  }

Under the current rules (plus relaxed [dcl.fct]/11), these two definition=
s have different return types which are not convertible. It is our opinio=
n that the rules making these types different are in fact correct and des=
irable, and this proposal specifically does *not* include any changes whi=
ch would make the types compatible. We would, however, encourage a future=
 (orthogonal) proposal which would allow something like this:

=2E. code:: c++

  struct { int result; } bar()
  {
    // The '[*]' operator here causes the compiler to store the input as =
a
    // temporary and generate an expression list from the unpacked member=
s of
    // the same; it can be used anywhere an expression list is accepted
    return { [*]foo() };
  }


=2E. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..=
 .. ..

=2E. _N4567: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
7.pdf
=2E. _N4560: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
0.pdf
=2E. _P0144: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p014=
4r0.pdf
=2E. _P0151: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p015=
1r0.pdf

=2E. |--| unicode:: U+02014 .. em dash

--------------030403040308090000070304
Content-Type: text/html; charset=UTF-8;
 name="PXXXX Implicit Return Type.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.html"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiID8+CjwhRE9DVFlQRSBodG1s
IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRw
Oi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4K
PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJl
biIgbGFuZz0iZW4iPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+CjxtZXRhIG5hbWU9ImdlbmVy
YXRvciIgY29udGVudD0iRG9jdXRpbHMgMC4xMTogaHR0cDovL2RvY3V0aWxzLnNvdXJjZWZv
cmdlLm5ldC8iIC8+Cjx0aXRsZT5JbXBsaWNpdCBSZXR1cm4gVHlwZTwvdGl0bGU+CjxtZXRh
IG5hbWU9ImRhdGUiIGNvbnRlbnQ9IjIwMTUtMTItMzEiIC8+CjxtZXRhIG5hbWU9ImF1dGhv
ciIgY29udGVudD0iTWF0dGhldyBXb2VobGtlIChtd29laGxrZS5mbG9zcyYjNjQ7Z21haWwu
Y29tKSIgLz4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KCi8qCjpBdXRob3I6IERhdmlkIEdv
b2RnZXIgKGdvb2RnZXJAcHl0aG9uLm9yZykKOklkOiAkSWQ6IGh0bWw0Y3NzMS5jc3MgNzYx
NCAyMDEzLTAyLTIxIDE1OjU1OjUxWiBtaWxkZSAkCjpDb3B5cmlnaHQ6IFRoaXMgc3R5bGVz
aGVldCBoYXMgYmVlbiBwbGFjZWQgaW4gdGhlIHB1YmxpYyBkb21haW4uCgpEZWZhdWx0IGNh
c2NhZGluZyBzdHlsZSBzaGVldCBmb3IgdGhlIEhUTUwgb3V0cHV0IG9mIERvY3V0aWxzLgoK
U2VlIGh0dHA6Ly9kb2N1dGlscy5zZi5uZXQvZG9jcy9ob3d0by9odG1sLXN0eWxlc2hlZXRz
Lmh0bWwgZm9yIGhvdyB0bwpjdXN0b21pemUgdGhpcyBzdHlsZSBzaGVldC4KKi8KCi8qIHVz
ZWQgdG8gcmVtb3ZlIGJvcmRlcnMgZnJvbSB0YWJsZXMgYW5kIGltYWdlcyAqLwouYm9yZGVy
bGVzcywgdGFibGUuYm9yZGVybGVzcyB0ZCwgdGFibGUuYm9yZGVybGVzcyB0aCB7CiAgYm9y
ZGVyOiAwIH0KCnRhYmxlLmJvcmRlcmxlc3MgdGQsIHRhYmxlLmJvcmRlcmxlc3MgdGggewog
IC8qIE92ZXJyaWRlIHBhZGRpbmcgZm9yICJ0YWJsZS5kb2N1dGlscyB0ZCIgd2l0aCAiISBp
bXBvcnRhbnQiLgogICAgIFRoZSByaWdodCBwYWRkaW5nIHNlcGFyYXRlcyB0aGUgdGFibGUg
Y2VsbHMuICovCiAgcGFkZGluZzogMCAwLjVlbSAwIDAgISBpbXBvcnRhbnQgfQoKLmZpcnN0
IHsKICAvKiBPdmVycmlkZSBtb3JlIHNwZWNpZmljIG1hcmdpbiBzdHlsZXMgd2l0aCAiISBp
bXBvcnRhbnQiLiAqLwogIG1hcmdpbi10b3A6IDAgISBpbXBvcnRhbnQgfQoKLmxhc3QsIC53
aXRoLXN1YnRpdGxlIHsKICBtYXJnaW4tYm90dG9tOiAwICEgaW1wb3J0YW50IH0KCi5oaWRk
ZW4gewogIGRpc3BsYXk6IG5vbmUgfQoKYS50b2MtYmFja3JlZiB7CiAgdGV4dC1kZWNvcmF0
aW9uOiBub25lIDsKICBjb2xvcjogYmxhY2sgfQoKYmxvY2txdW90ZS5lcGlncmFwaCB7CiAg
bWFyZ2luOiAyZW0gNWVtIDsgfQoKZGwuZG9jdXRpbHMgZGQgewogIG1hcmdpbi1ib3R0b206
IDAuNWVtIH0KCm9iamVjdFt0eXBlPSJpbWFnZS9zdmcreG1sIl0sIG9iamVjdFt0eXBlPSJh
cHBsaWNhdGlvbi94LXNob2Nrd2F2ZS1mbGFzaCJdIHsKICBvdmVyZmxvdzogaGlkZGVuOwp9
CgovKiBVbmNvbW1lbnQgKGFuZCByZW1vdmUgdGhpcyB0ZXh0ISkgdG8gZ2V0IGJvbGQtZmFj
ZWQgZGVmaW5pdGlvbiBsaXN0IHRlcm1zCmRsLmRvY3V0aWxzIGR0IHsKICBmb250LXdlaWdo
dDogYm9sZCB9CiovCgpkaXYuYWJzdHJhY3QgewogIG1hcmdpbjogMmVtIDVlbSB9CgpkaXYu
YWJzdHJhY3QgcC50b3BpYy10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIHRleHQt
YWxpZ246IGNlbnRlciB9CgpkaXYuYWRtb25pdGlvbiwgZGl2LmF0dGVudGlvbiwgZGl2LmNh
dXRpb24sIGRpdi5kYW5nZXIsIGRpdi5lcnJvciwKZGl2LmhpbnQsIGRpdi5pbXBvcnRhbnQs
IGRpdi5ub3RlLCBkaXYudGlwLCBkaXYud2FybmluZyB7CiAgbWFyZ2luOiAyZW0gOwogIGJv
cmRlcjogbWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIH0KCmRpdi5hZG1vbml0aW9u
IHAuYWRtb25pdGlvbi10aXRsZSwgZGl2LmhpbnQgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYu
aW1wb3J0YW50IHAuYWRtb25pdGlvbi10aXRsZSwgZGl2Lm5vdGUgcC5hZG1vbml0aW9uLXRp
dGxlLApkaXYudGlwIHAuYWRtb25pdGlvbi10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQg
OwogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0KCmRpdi5hdHRlbnRpb24gcC5hZG1vbml0
aW9uLXRpdGxlLCBkaXYuY2F1dGlvbiBwLmFkbW9uaXRpb24tdGl0bGUsCmRpdi5kYW5nZXIg
cC5hZG1vbml0aW9uLXRpdGxlLCBkaXYuZXJyb3IgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYu
d2FybmluZyBwLmFkbW9uaXRpb24tdGl0bGUsIC5jb2RlIC5lcnJvciB7CiAgY29sb3I6IHJl
ZCA7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0K
Ci8qIFVuY29tbWVudCAoYW5kIHJlbW92ZSB0aGlzIHRleHQhKSB0byBnZXQgcmVkdWNlZCB2
ZXJ0aWNhbCBzcGFjZSBpbgogICBjb21wb3VuZCBwYXJhZ3JhcGhzLgpkaXYuY29tcG91bmQg
LmNvbXBvdW5kLWZpcnN0LCBkaXYuY29tcG91bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFy
Z2luLWJvdHRvbTogMC41ZW0gfQoKZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1sYXN0LCBkaXYu
Y29tcG91bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFyZ2luLXRvcDogMC41ZW0gfQoqLwoK
ZGl2LmRlZGljYXRpb24gewogIG1hcmdpbjogMmVtIDVlbSA7CiAgdGV4dC1hbGlnbjogY2Vu
dGVyIDsKICBmb250LXN0eWxlOiBpdGFsaWMgfQoKZGl2LmRlZGljYXRpb24gcC50b3BpYy10
aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc3R5bGU6IG5vcm1hbCB9Cgpk
aXYuZmlndXJlIHsKICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9
CgpkaXYuZm9vdGVyLCBkaXYuaGVhZGVyIHsKICBjbGVhcjogYm90aDsKICBmb250LXNpemU6
IHNtYWxsZXIgfQoKZGl2LmxpbmUtYmxvY2sgewogIGRpc3BsYXk6IGJsb2NrIDsKICBtYXJn
aW4tdG9wOiAxZW0gOwogIG1hcmdpbi1ib3R0b206IDFlbSB9CgpkaXYubGluZS1ibG9jayBk
aXYubGluZS1ibG9jayB7CiAgbWFyZ2luLXRvcDogMCA7CiAgbWFyZ2luLWJvdHRvbTogMCA7
CiAgbWFyZ2luLWxlZnQ6IDEuNWVtIH0KCmRpdi5zaWRlYmFyIHsKICBtYXJnaW46IDAgMCAw
LjVlbSAxZW0gOwogIGJvcmRlcjogbWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIDsK
ICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmVlIDsKICB3aWR0aDogNDAlIDsKICBmbG9hdDog
cmlnaHQgOwogIGNsZWFyOiByaWdodCB9CgpkaXYuc2lkZWJhciBwLnJ1YnJpYyB7CiAgZm9u
dC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtc2l6ZTogbWVkaXVtIH0KCmRpdi5zeXN0
ZW0tbWVzc2FnZXMgewogIG1hcmdpbjogNWVtIH0KCmRpdi5zeXN0ZW0tbWVzc2FnZXMgaDEg
ewogIGNvbG9yOiByZWQgfQoKZGl2LnN5c3RlbS1tZXNzYWdlIHsKICBib3JkZXI6IG1lZGl1
bSBvdXRzZXQgOwogIHBhZGRpbmc6IDFlbSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2UgcC5zeXN0
ZW0tbWVzc2FnZS10aXRsZSB7CiAgY29sb3I6IHJlZCA7CiAgZm9udC13ZWlnaHQ6IGJvbGQg
fQoKZGl2LnRvcGljIHsKICBtYXJnaW46IDJlbSB9CgpoMS5zZWN0aW9uLXN1YnRpdGxlLCBo
Mi5zZWN0aW9uLXN1YnRpdGxlLCBoMy5zZWN0aW9uLXN1YnRpdGxlLApoNC5zZWN0aW9uLXN1
YnRpdGxlLCBoNS5zZWN0aW9uLXN1YnRpdGxlLCBoNi5zZWN0aW9uLXN1YnRpdGxlIHsKICBt
YXJnaW4tdG9wOiAwLjRlbSB9CgpoMS50aXRsZSB7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0K
CmgyLnN1YnRpdGxlIHsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKaHIuZG9jdXRpbHMgewog
IHdpZHRoOiA3NSUgfQoKaW1nLmFsaWduLWxlZnQsIC5maWd1cmUuYWxpZ24tbGVmdCwgb2Jq
ZWN0LmFsaWduLWxlZnQgewogIGNsZWFyOiBsZWZ0IDsKICBmbG9hdDogbGVmdCA7CiAgbWFy
Z2luLXJpZ2h0OiAxZW0gfQoKaW1nLmFsaWduLXJpZ2h0LCAuZmlndXJlLmFsaWduLXJpZ2h0
LCBvYmplY3QuYWxpZ24tcmlnaHQgewogIGNsZWFyOiByaWdodCA7CiAgZmxvYXQ6IHJpZ2h0
IDsKICBtYXJnaW4tbGVmdDogMWVtIH0KCmltZy5hbGlnbi1jZW50ZXIsIC5maWd1cmUuYWxp
Z24tY2VudGVyLCBvYmplY3QuYWxpZ24tY2VudGVyIHsKICBkaXNwbGF5OiBibG9jazsKICBt
YXJnaW4tbGVmdDogYXV0bzsKICBtYXJnaW4tcmlnaHQ6IGF1dG87Cn0KCi5hbGlnbi1sZWZ0
IHsKICB0ZXh0LWFsaWduOiBsZWZ0IH0KCi5hbGlnbi1jZW50ZXIgewogIGNsZWFyOiBib3Ro
IDsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKLmFsaWduLXJpZ2h0IHsKICB0ZXh0LWFsaWdu
OiByaWdodCB9CgovKiByZXNldCBpbm5lciBhbGlnbm1lbnQgaW4gZmlndXJlcyAqLwpkaXYu
YWxpZ24tcmlnaHQgewogIHRleHQtYWxpZ246IGluaGVyaXQgfQoKLyogZGl2LmFsaWduLWNl
bnRlciAqIHsgKi8KLyogICB0ZXh0LWFsaWduOiBsZWZ0IH0gKi8KCm9sLnNpbXBsZSwgdWwu
c2ltcGxlIHsKICBtYXJnaW4tYm90dG9tOiAxZW0gfQoKb2wuYXJhYmljIHsKICBsaXN0LXN0
eWxlOiBkZWNpbWFsIH0KCm9sLmxvd2VyYWxwaGEgewogIGxpc3Qtc3R5bGU6IGxvd2VyLWFs
cGhhIH0KCm9sLnVwcGVyYWxwaGEgewogIGxpc3Qtc3R5bGU6IHVwcGVyLWFscGhhIH0KCm9s
Lmxvd2Vycm9tYW4gewogIGxpc3Qtc3R5bGU6IGxvd2VyLXJvbWFuIH0KCm9sLnVwcGVycm9t
YW4gewogIGxpc3Qtc3R5bGU6IHVwcGVyLXJvbWFuIH0KCnAuYXR0cmlidXRpb24gewogIHRl
eHQtYWxpZ246IHJpZ2h0IDsKICBtYXJnaW4tbGVmdDogNTAlIH0KCnAuY2FwdGlvbiB7CiAg
Zm9udC1zdHlsZTogaXRhbGljIH0KCnAuY3JlZGl0cyB7CiAgZm9udC1zdHlsZTogaXRhbGlj
IDsKICBmb250LXNpemU6IHNtYWxsZXIgfQoKcC5sYWJlbCB7CiAgd2hpdGUtc3BhY2U6IG5v
d3JhcCB9CgpwLnJ1YnJpYyB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc2l6ZTog
bGFyZ2VyIDsKICBjb2xvcjogbWFyb29uIDsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKcC5z
aWRlYmFyLXRpdGxlIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC13ZWln
aHQ6IGJvbGQgOwogIGZvbnQtc2l6ZTogbGFyZ2VyIH0KCnAuc2lkZWJhci1zdWJ0aXRsZSB7
CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnAu
dG9waWMtdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnByZS5hZGRyZXNzIHsKICBt
YXJnaW4tYm90dG9tOiAwIDsKICBtYXJnaW4tdG9wOiAwIDsKICBmb250OiBpbmhlcml0IH0K
CnByZS5saXRlcmFsLWJsb2NrLCBwcmUuZG9jdGVzdC1ibG9jaywgcHJlLm1hdGgsIHByZS5j
b2RlIHsKICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9CgpwcmUu
Y29kZSAubG4geyBjb2xvcjogZ3JleTsgfSAvKiBsaW5lIG51bWJlcnMgKi8KcHJlLmNvZGUs
IGNvZGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjZWVlZWVlIH0KcHJlLmNvZGUgLmNvbW1lbnQs
IGNvZGUgLmNvbW1lbnQgeyBjb2xvcjogIzVDNjU3NiB9CnByZS5jb2RlIC5rZXl3b3JkLCBj
b2RlIC5rZXl3b3JkIHsgY29sb3I6ICMzQjBEMDY7IGZvbnQtd2VpZ2h0OiBib2xkIH0KcHJl
LmNvZGUgLmxpdGVyYWwuc3RyaW5nLCBjb2RlIC5saXRlcmFsLnN0cmluZyB7IGNvbG9yOiAj
MEM1NDA0IH0KcHJlLmNvZGUgLm5hbWUuYnVpbHRpbiwgY29kZSAubmFtZS5idWlsdGluIHsg
Y29sb3I6ICMzNTJCODQgfQpwcmUuY29kZSAuZGVsZXRlZCwgY29kZSAuZGVsZXRlZCB7IGJh
Y2tncm91bmQtY29sb3I6ICNERUIwQTF9CnByZS5jb2RlIC5pbnNlcnRlZCwgY29kZSAuaW5z
ZXJ0ZWQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQTNEMjg5fQoKc3Bhbi5jbGFzc2lmaWVyIHsK
ICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC1zdHlsZTogb2JsaXF1ZSB9Cgpz
cGFuLmNsYXNzaWZpZXItZGVsaW1pdGVyIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7
CiAgZm9udC13ZWlnaHQ6IGJvbGQgfQoKc3Bhbi5pbnRlcnByZXRlZCB7CiAgZm9udC1mYW1p
bHk6IHNhbnMtc2VyaWYgfQoKc3Bhbi5vcHRpb24gewogIHdoaXRlLXNwYWNlOiBub3dyYXAg
fQoKc3Bhbi5wcmUgewogIHdoaXRlLXNwYWNlOiBwcmUgfQoKc3Bhbi5wcm9ibGVtYXRpYyB7
CiAgY29sb3I6IHJlZCB9CgpzcGFuLnNlY3Rpb24tc3VidGl0bGUgewogIC8qIGZvbnQtc2l6
ZSByZWxhdGl2ZSB0byBwYXJlbnQgKGgxLi5oNiBlbGVtZW50KSAqLwogIGZvbnQtc2l6ZTog
ODAlIH0KCnRhYmxlLmNpdGF0aW9uIHsKICBib3JkZXItbGVmdDogc29saWQgMXB4IGdyYXk7
CiAgbWFyZ2luLWxlZnQ6IDFweCB9Cgp0YWJsZS5kb2NpbmZvIHsKICBtYXJnaW46IDJlbSA0
ZW0gfQoKdGFibGUuZG9jdXRpbHMgewogIG1hcmdpbi10b3A6IDAuNWVtIDsKICBtYXJnaW4t
Ym90dG9tOiAwLjVlbSB9Cgp0YWJsZS5mb290bm90ZSB7CiAgYm9yZGVyLWxlZnQ6IHNvbGlk
IDFweCBibGFjazsKICBtYXJnaW4tbGVmdDogMXB4IH0KCnRhYmxlLmRvY3V0aWxzIHRkLCB0
YWJsZS5kb2N1dGlscyB0aCwKdGFibGUuZG9jaW5mbyB0ZCwgdGFibGUuZG9jaW5mbyB0aCB7
CiAgcGFkZGluZy1sZWZ0OiAwLjVlbSA7CiAgcGFkZGluZy1yaWdodDogMC41ZW0gOwogIHZl
cnRpY2FsLWFsaWduOiB0b3AgfQoKdGFibGUuZG9jdXRpbHMgdGguZmllbGQtbmFtZSwgdGFi
bGUuZG9jaW5mbyB0aC5kb2NpbmZvLW5hbWUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICB0
ZXh0LWFsaWduOiBsZWZ0IDsKICB3aGl0ZS1zcGFjZTogbm93cmFwIDsKICBwYWRkaW5nLWxl
ZnQ6IDAgfQoKLyogImJvb2t0YWJzIiBzdHlsZSAobm8gdmVydGljYWwgbGluZXMpICovCnRh
YmxlLmRvY3V0aWxzLmJvb2t0YWJzIHsKICBib3JkZXI6IDBweDsKICBib3JkZXItdG9wOiAy
cHggc29saWQ7CiAgYm9yZGVyLWJvdHRvbTogMnB4IHNvbGlkOwogIGJvcmRlci1jb2xsYXBz
ZTogY29sbGFwc2U7Cn0KdGFibGUuZG9jdXRpbHMuYm9va3RhYnMgKiB7CiAgYm9yZGVyOiAw
cHg7Cn0KdGFibGUuZG9jdXRpbHMuYm9va3RhYnMgdGggewogIGJvcmRlci1ib3R0b206IHRo
aW4gc29saWQ7CiAgdGV4dC1hbGlnbjogbGVmdDsKfQoKaDEgdHQuZG9jdXRpbHMsIGgyIHR0
LmRvY3V0aWxzLCBoMyB0dC5kb2N1dGlscywKaDQgdHQuZG9jdXRpbHMsIGg1IHR0LmRvY3V0
aWxzLCBoNiB0dC5kb2N1dGlscyB7CiAgZm9udC1zaXplOiAxMDAlIH0KCnVsLmF1dG8tdG9j
IHsKICBsaXN0LXN0eWxlLXR5cGU6IG5vbmUgfQoKPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4K
PGRpdiBjbGFzcz0iZG9jdW1lbnQiIGlkPSJpbXBsaWNpdC1yZXR1cm4tdHlwZSI+CjxoMSBj
bGFzcz0idGl0bGUiPkltcGxpY2l0IFJldHVybiBUeXBlPC9oMT4KPHRhYmxlIGNsYXNzPSJk
b2NpbmZvIiBmcmFtZT0idm9pZCIgcnVsZXM9Im5vbmUiPgo8Y29sIGNsYXNzPSJkb2NpbmZv
LW5hbWUiIC8+Cjxjb2wgY2xhc3M9ImRvY2luZm8tY29udGVudCIgLz4KPHRib2R5IHZhbGln
bj0idG9wIj4KPHRyIGNsYXNzPSJmaWVsZCI+PHRoIGNsYXNzPSJkb2NpbmZvLW5hbWUiPkRv
Y3VtZW50OjwvdGg+PHRkIGNsYXNzPSJmaWVsZC1ib2R5Ij5QWFhYWCAoVEJEKTwvdGQ+Cjwv
dHI+Cjx0cj48dGggY2xhc3M9ImRvY2luZm8tbmFtZSI+RGF0ZTo8L3RoPgo8dGQ+MjAxNS0x
Mi0zMTwvdGQ+PC90cj4KPHRyPjx0aCBjbGFzcz0iZG9jaW5mby1uYW1lIj5BdXRob3I6PC90
aD4KPHRkPk1hdHRoZXcgV29laGxrZSAoPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIg
aHJlZj0ibWFpbHRvOm13b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5jb20iPm13b2VobGtlLmZs
b3NzJiM2NDtnbWFpbC5jb208L2E+KTwvdGQ+PC90cj4KPC90Ym9keT4KPC90YWJsZT4KPHN0
eWxlPgogIGh0bWwgeyBjb2xvcjogYmxhY2s7IGJhY2tncm91bmQ6IHdoaXRlOyB9CiAgdGFi
bGUuZG9jaW5mbyB7IG1hcmdpbjogMmVtIDA7IH0KICAubGl0ZXJhbC1ibG9jayB7IGJhY2tn
cm91bmQ6ICNlZWU7IGJvcmRlcjogMXB4IHNvbGlkICNkZGQ7IHBhZGRpbmc6IDAuNWVtOyB9
CiAgLmFkZGl0aW9uIHsgY29sb3I6ICMyYzI7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l
OyB9CiAgLnJlbW92YWwgeyBjb2xvcjogI2UyMjsgdGV4dC1kZWNvcmF0aW9uOiBsaW5lLXRo
cm91Z2g7IH0KICAubGl0ZXJhbC1ibG9jayAubGl0ZXJhbC1ibG9jayB7IGJhY2tncm91bmQ6
IG5vbmU7IGJvcmRlcjogbm9uZTsgfQogIC5ibG9jay1hZGRpdGlvbiB7IGJhY2tncm91bmQ6
ICNjZmM7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyB9Cjwvc3R5bGU+PGRpdiBjbGFz
cz0ic2VjdGlvbiIgaWQ9ImFic3RyYWN0Ij4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIg
aHJlZj0iI2lkMSI+QWJzdHJhY3Q8L2E+PC9oMT4KPHA+VGhpcyBwcm9wb3NhbCByZWNvbW1l
bmRzIGFuIGVuaGFuY2VtZW50IHRvIHJldHVybiB0eXBlIGRlZHVjdGlvbiB0byBhbGxvdyB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBmdW5jdGlvbiBkZWZpbml0aW9uIHRvIGJlIGluZmVycmVk
IGZyb20gYSBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiB0aGUgc2FtZS48L3A+CjxwPihOb3Rl
OiByZWZlcmVuY2VzIG1hZGUgdG8gdGhlIGV4aXN0aW5nIGRyYWZ0IHN0YW5kYXJkIGFyZSBt
YWRlIGFnYWluc3QgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDov
L3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2
Ny5wZGYiPk40NTY3PC9hPi4pPC9wPgo8ZGl2IGNsYXNzPSJjb250ZW50cyB0b3BpYyIgaWQ9
ImNvbnRlbnRzIj4KPHAgY2xhc3M9InRvcGljLXRpdGxlIGZpcnN0Ij5Db250ZW50czwvcD4K
PHVsIGNsYXNzPSJzaW1wbGUiPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIg
aHJlZj0iI2Fic3RyYWN0IiBpZD0iaWQxIj5BYnN0cmFjdDwvYT48L2xpPgo8bGk+PGEgY2xh
c3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3JhdGlvbmFsZSIgaWQ9ImlkMiI+UmF0
aW9uYWxlPC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVm
PSIjcHJvcG9zYWwiIGlkPSJpZDMiPlByb3Bvc2FsPC9hPjwvbGk+CjxsaT48YSBjbGFzcz0i
cmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjcHJvcG9zZWQtd29yZGluZyIgaWQ9ImlkNCI+
UHJvcG9zZWQgV29yZGluZzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRl
cm5hbCIgaHJlZj0iI2Rpc2N1c3Npb24iIGlkPSJpZDUiPkRpc2N1c3Npb248L2E+PC9saT4K
PC91bD4KPC9kaXY+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0icmF0aW9uYWxl
Ij4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkMiI+UmF0aW9uYWxlPC9h
PjwvaDE+CjxwPlRoZSBjb25jZXB0IG9mIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgaXMgd2Vs
bCBrbm93bi4gQXQgcHJlc2VudCwgaG93ZXZlciwgQysrIGxhY2tzIGEgZ29vZCBtZWNoYW5p
c20gZm9yIGltcGxlbWVudGluZyB0aGUgc2FtZS4gPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRl
cmFsIj48c3BhbiBjbGFzcz0icHJlIj5zdGQ6OnR1cGxlPC9zcGFuPjwvdHQ+IGlzIGNvbnNp
ZGVyZWQgY2x1bmt5IGJ5IG1hbnkgYW5kLCBjcml0aWNhbGx5LCBjcmVhdGVzIHN1Yi1vcHRp
bWFsIEFQSSBieSB2aXJ0dWUgb2YgdGhlIHJldHVybmVkIHZhbHVlcyBiZWluZyB1bm5hbWVk
LCBmb3JjaW5nIGRldmVsb3BlcnMgdG8gcmVseSBvbiBzdXBwbGVtZW50YWwgZG9jdW1lbnRh
dGlvbiB0byBleHBsYWluIHRoZWlyIHB1cnBvc2UuIEFnZ3JlZ2F0ZXMgcmVwcmVzZW50IGFu
IGltcHJvdmVtZW50LCBiZWluZyBzZWxmLWRvY3VtZW50aW5nLCBidXQgdGhlIG5lZWQgdG8g
cHJvdmlkZSBleHRlcm5hbCBkZWZpbml0aW9ucyBvZiB0aGUgc2FtZSBpcyBhd2t3YXJkIGFu
ZCwgd29yc2UsIHBvbGx1dGVzIHRoZWlyIGNvcnJlc3BvbmRpbmcgbmFtZXNwYWNlIHdpdGgg
ZW50aXRpZXMgdGhhdCBtYXkgYmUgc2luZ2xlIHVzZS4gUHJvcG9zYWxzIHN1Y2ggYXMgPGEg
Y2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5v
cmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2MC5wZGYiPk40NTYwPC9h
PiBwcmVzZW50IGEgY29tcGxpY2F0ZWQgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgdGFnZ2Vk
IChzZWxmLWRvY3VtZW50aW5nKSB0dXBsZS1saWtlIHR5cGVzLCB3aGljaCBtYXkgYmUgbmVj
ZXNzYXJ5IGluIHNvbWUgY2FzZXMsIGJ1dCBzdGlsbCByZXByZXNlbnQgYSBub24tdHJpdmlh
bCBhbW91bnQgb2YgY29tcGxleGl0eSB0aGF0IGlkZWFsbHkgc2hvdWxkIG5vdCBiZSByZXF1
aXJlZC48L3A+CjxwPlByb3Bvc2FscyBzdWNoIGFzIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0
ZXJuYWwiIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2Rv
Y3MvcGFwZXJzLzIwMTUvcDAxNDRyMC5wZGYiPlAwMTQ0PC9hPiAob3IgaXRzIGNvbXBldGl0
b3IgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVu
LXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZiI+
UDAxNTE8L2E+KSBpbiBwYXJ0aWN1bGFyIHdvdWxkIHJlcHJlc2VudCBhIHNpZ25pZmljYW50
IHN0ZXAgdG93YXJkIHN1cHBvcnQgb2YgbXVsdGlwbGUgcmV0dXJuIHZhbHVlcyBhcyBmaXJz
dCBjbGFzcyBjaXRpemVucy4gVGhlc2UgcHJvcG9zYWxzIGFuZCBvdGhlciBjdXJyZW50IGRp
cmVjdGlvbnMgc2hvdyBhbiBlbmNvdXJhZ2luZyBtb3ZlbWVudCBhd2F5IGZyb20gdGhlIHRy
YWRpdGlvbmFsIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9InBy
ZSI+c3RkOjpwYWlyPC9zcGFuPjwvdHQ+IGFuZCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVy
YWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gdG93YXJkcyBj
b21wYXJhYmxlIGNvbmNlcHRzIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBleHBsaWNpdCB0eXBl
cy4gKFdlIGV4cGVjdCwgaG93ZXZlciwgdGhhdCB0aGVzZSB3aWxsIHJlbWFpbiB1c2VmdWwg
Zm9yIGFsZ29yaXRobXMgd2hlcmUgdGhlIGlkZW50aXR5IG9mIHRoZSBlbGVtZW50cyBpcyB1
bmltcG9ydGFudCwgd2hpbGUgaXQgPGVtPmlzPC9lbT4gaW1wb3J0YW50IHRvIGJlIGFibGUg
dG8gbmFtZSBhdCBsZWFzdCB0aGUgb3V0ZXIsIGlmIG5vdCBjb21wbGV0ZSwgdHlwZS4gSW4g
dGhhdCByZXNwZWN0LCB3ZSBoeXBvdGhlc2l6ZSB0aGF0IHdlIG1heSBpbiB0aGUgZnV0dXJl
IHNlZSB0aGUgYWJpbGl0eSB0byBjb25zdHJ1Y3QgYSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxp
dGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gZnJvbSBh
bnkgdHVwbGUtbGlrZS4pIE9uIHRoZWlyIG93biwgaG93ZXZlciwgdGhlc2UgcHJvcG9zYWxz
IHJpc2sgZXhhY2VyYmF0aW5nIHRoZSBwcm9ibGVtIHRoYXQgdGhpcyBwcm9wb3NhbCBhaW1z
IHRvIGFkZHJlc3MuPC9wPgo8cD5JdCBoYXMgYmVlbiBzdWdnZXN0ZWQgb24gbXVsdGlwbGUg
b2NjYXNpb25zIHRoYXQgdGhlIG9wdGltYWwgc29sdXRpb24gdG8gdGhlIGFib3ZlIGlzc3Vl
cyBpcyB0byByZXR1cm4gYW4gYW5vbnltb3VzIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJh
bCI+c3RydWN0PC90dD4uIFRoaXMgc29sdmVzIHRoZSBwcm9ibGVtcyBvZiBjbHV0dGVyIGFu
ZCBzZWxmLWRvY3VtZW50YXRpb24sIGJ1dCBydW5zIGFmb3VsIG9mIGEgbXVjaCB3b3JzZSBp
c3N1ZTsgYmVjYXVzZSB0aGUgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5zdHJ1Y3Q8
L3R0PiBpcyA8ZW0+YW5vbnltb3VzPC9lbT4sIGl0IGNhbiBiZSBkaWZmaWN1bHQgdG8gaW1w
b3NzaWJsZSB0byBnaXZlIGl0cyBuYW1lIGEgc2Vjb25kIHRpbWUgaW4gb3JkZXIgdG8gc2Vw
YXJhdGUgdGhlIGRlY2xhcmF0aW9uIGFuZCBkZWZpbml0aW9uIG9mIHRoZSBmdW5jdGlvbiB0
aGF0IHdpc2hlcyB0byB1c2UgaXQuPC9wPgo8cD5Ib3dldmVyLCBpbiBDKyssIGZ1bmN0aW9u
cyBjYW5ub3QgYmUgb3ZlcmxvYWRlZCBieSB0aGVpciByZXR1cm4gdmFsdWUuIFRoaXMgbGVh
ZHMgdG8gYW4gb2J2aW91cyBxdWVzdGlvbjogPHN0cm9uZz53aHkgaXMgaXQgbmVjZXNzYXJ5
IHRvIHJlcGVhdCB0aGUgcmV0dXJuIHZhbHVlIGF0IGFsbD88L3N0cm9uZz48L3A+CjxwPkV2
ZW4gaW4gdGhlIGNhc2Ugb2YgcmV0dXJuIHR5cGVzIHRoYXQgY2FuIGJlIG5hbWVkLCBpdCBt
YXkgYmUgdGhhdCByZXBlYXRpbmcgdGhlIHR5cGUgbmFtZSBpcyBleGNlc3NpdmVseSB2ZXJi
b3NlIG9yIG90aGVyd2lzZSB1bmRlc2lyYWJsZS4gU29tZSBtaWdodCBldmVuIGNhbGwgdGhp
cyBhIHZpb2xhdGlvbiBvZiB0aGUgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJl
Zj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRG9uJ3RfcmVwZWF0X3lvdXJzZWxm
Ij5Eb24ndCBSZXBlYXQgWW91cnNlbGY8L2E+IHByaW5jaXBsZSwgc2ltaWxhciB0byBzb21l
IG9mIHRoZSBpc3N1ZXMgdGhhdCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88
L3R0PiBmb3IgdmFyaWFibGUgZGVjbGFyYXRpb24gd2FzIGludHJvZHVjZWQgdG8gc29sdmUu
IChPbiB0aGUgZmxpcCBzaWRlLCBvbmUgY291bGQgc2VlIHRoZSBhYmlsaXR5IHRvIGVsaWRl
IHRoZSByZXR1cm4gdHlwZSBhcyBzdWJqZWN0IHRvIG1hbnkgYWJ1c2VzLCBhZ2FpbiBpbiBt
dWNoIHRoZSBtYW5uZXIgb2YgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRvPC90
dD4uIEhvd2V2ZXIsIG1hbnkgbGFuZ3VhZ2UgZmVhdHVyZXMgY2FuIGJlIGFidXNlZDsgdGhp
cyBzaG91bGQgbm90IHByZXZlbnQgdGhlIGFkZGl0aW9uIG9mIGEgZmVhdHVyZSB0aGF0IHdv
dWxkIHByb3ZpZGUgYW4gaW1wb3J0YW50IGJlbmVmaXQgd2hlbiB1c2VkIGNvcnJlY3RseS4p
PC9wPgo8cD5XZSB3b3VsZCBiZSByZW1pc3Mgbm90IHRvIG5vdGUgdGhhdCB0aGlzIGlzIGFs
cmVhZHkgcG9zc2libGUgaW4gc2ltcGxlIGNhc2VzIHVzaW5nIDx0dCBjbGFzcz0iZG9jdXRp
bHMgbGl0ZXJhbCI+ZGVjbHR5cGU8L3R0PiBhbmQgYSBzYW1wbGUgaW52b2NhdGlvbiBvZiB0
aGUgZnVuY3Rpb24uIEhvd2V2ZXIsIHdoaWxlIHRoaXMgbWF5IGJlIGFkZXF1YXRlIGluIHNp
bXBsZSBjYXNlcywgaXQgaXMgbmV2ZXJ0aGVsZXNzIG5lZWRsZXNzbHkgdmVyYm9zZSwgYW5k
IGFzIHRoZSBhcmd1bWVudCBsaXN0IGdyb3dzIGxvbmdlciwgYW5kL29yIGdhaW5zIGFyZ3Vt
ZW50cyBmb3Igd2hpY2ggcHJvdmlkaW5nIGEgbGVnYWwgdmFsdWUgaXMgbm9uLXRyaXZpYWws
IGl0IGNhbiBxdWlja2x5IGJlY29tZSB1bndpZWxkeSBhbmQgdW5mZWFzaWJsZS48L3A+Cjwv
ZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0icHJvcG9zYWwiPgo8aDE+PGEgY2xhc3M9
InRvYy1iYWNrcmVmIiBocmVmPSIjaWQzIj5Qcm9wb3NhbDwvYT48L2gxPgo8cD5SZWNlbnQg
Y2hhbmdlcyB0byB0aGUgbGFuZ3VhZ2UgaGF2ZSBwcm9ncmVzc2l2ZWx5IHJlbGF4ZWQgdGhl
IHJlcXVpcmVtZW50cyBmb3IgaG93IHJldHVybiB0eXBlcyBhcmUgc3BlY2lmaWVkLiBXZSBi
ZWdhbiB3aXRoIHRyYWlsaW5nIHJldHVybiB0eXBlIHNwZWNpZmljYXRpb24sIGFuZCBoYXZl
IHByb2dyZXNzZWQgdG8gaW5mZXJyZWQgcmV0dXJuIHR5cGVzIGluIGNlcnRhaW4gY2FzZXMu
PC9wPgo8cD5UaGlzIHByb3Bvc2FsIGlzIHRvIGNvbnRpbnVlIHRoaXMgZGlyZWN0aW9uIGJ5
IGFkZGluZyBhbiBhZGRpdGlvbmFsIHVzZSBvZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVy
YWwiPmF1dG88L3R0PiBhcyBhIHJldHVybiBzcGVjaWZpZXIsIG1lYW5pbmcgJnF1b3Q7dXNl
IHRoZSByZXR1cm4gdHlwZSBzZWVuIHdoZW4gdGhpcyBmdW5jdGlvbiB3YXMgcHJldmlvdXNs
eSBkZWNsYXJlZCZxdW90Oy4gVGhpcyBwcm92aWRlcyBhbiBvcHRpbWFsIHNvbHV0aW9uIHRv
IHRoZSBmb2xsb3dpbmcgcHJvYmxlbTo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVy
YWwtYmxvY2siPgo8c3BhbiBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIGZvby5oCjwvc3Bh
bj48c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im5hbWUiPmlkPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+ZG91YmxlPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibmFtZSI+dmFsdWU8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNs
YXNzPSJuYW1lIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8L3Nw
YW4+CjwvcHJlPgo8cD5Ib3cgZG9lcyBvbmUgbm93IHByb3ZpZGUgYW4gZXh0ZXJuYWwgZGVm
aW5pdGlvbiBmb3IgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5mb28oKTwvdHQ+PyBX
ZSBwcm9wb3NlOjwvcD4KPHByZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+Cjxz
cGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gZm9vLmNwcAo8L3NwYW4+PHNwYW4gY2xh
c3M9ImtleXdvcmQiPmF1dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5m
b288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogIDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
Li4uPC9zcGFuPgogIDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmlkPC9z
cGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5h
bWUiPnZhbHVlPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFuPgo8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8cD5UaGUgdXNlIG9m
IDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+IGFzIHRoZSByZXR1cm4g
dHlwZSBzcGVjaWZpZXIsIHdpdGggbm8gdHJhaWxpbmcgcmV0dXJuIHR5cGUsIGFuZCBmb3Ig
YSBmdW5jdGlvbiB0aGF0IGhhcyBiZWVuIHByZXZpb3VzbHkgZGVjbGFyZWQgd2l0aCBhIGtu
b3duIHJldHVybiB0eXBlLCBzaGFsbCBpbnN0cnVjdCB0aGUgY29tcGlsZXIgdG8gZGVmaW5l
IHRoZSBmdW5jdGlvbiB1c2luZyB0aGUgcmV0dXJuIHR5cGUgZnJvbSB0aGUgcHJldmlvdXMg
ZGVjbGFyYXRpb24uIChOb3RlIHRoYXQgdGhpcyB3b3JrcyBmb3IgPGVtPmFueTwvZW0+IHR5
cGUsIG5vdCBqdXN0IGFub255bW91cyA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnN0
cnVjdDwvdHQ+cy4pPC9wPgo8cD5OYXR1cmFsbHksICZxdW90O3ByZXZpb3VzIGRlY2xhcmF0
aW9uJnF1b3Q7IGhlcmUgbWVhbnMgYSBkZWNsYXJhdGlvbiBoYXZpbmcgdGhlIHNhbWUgbmFt
ZSBhbmQgYXJndW1lbnQgbGlzdC4gVGhpcywgZm9yIGV4YW1wbGUsIHdvdWxkIHJlbWFpbiBp
bGxlZ2FsOjwvcD4KPHByZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFu
IGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3Bh
biBjbGFzcz0ibmFtZSI+aWQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9z
cGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj52YWx1ZTwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+
IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
PmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xh
c3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
KTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+
aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+aWQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5mbG9hdDwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8
c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
KDwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPik7PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1
dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUi
PmRvdWJsZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmlucHV0PC9zcGFuPjxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj4gPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xl
Ij4vLyBkb2VzIG5vdCBtYXRjaCBhbnkgcHJldmlvdXMgZGVjbGFyYXRpb24KPC9zcGFuPjxz
cGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPi4uLjwvc3Bhbj4KICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFu
PiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1l
Ij5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNs
YXNzPSJuYW1lIj5yZXN1bHQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTs8
L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPlNp
bmNlIHRoaXMgaGFzIGltcGxpY2F0aW9ucyB3aXRoIHJlc3BlY3QgdG8gcmV0dXJuIHR5cGUg
ZGVkdWN0aW9uLCB3ZSBhZGRpdGlvbmFsbHkgcHJvcG9zZSBhbiBhbHRlcmF0aW9uIHRvIFtk
Y2wuc3BlYy5hdXRvXS8xMzsgc3BlY2lmaWNhbGx5LCBhIHByZXZpb3VzIGRlY2xhcmF0aW9u
IHRoYXQgdXNlZCBhIHBsYWNlaG9sZGVyIHR5cGUgZm9yIHRoZSByZXR1cm4gdHlwZSBtYXkg
bm93IGJlIHJlZGVjbGFyZWQgb3IgZGVmaW5lZCB1c2luZyBhIGNvbmNyZXRlIHR5cGUgKGlm
ZiB0aGUgY29uY3JldGUgdHlwZSBpcyBjb21wYXRpYmxlIHdpdGggdGhlIHBsYWNlaG9sZGVy
IHR5cGUpLiBEb2luZyBzbyBzaGFsbCByZXNvbHZlIHRoZSBwbGFjZWhvbGRlciB0eXBlIHRv
IHRoZSBjb25jcmV0ZSB0eXBlLjwvcD4KPHA+QWRkaXRpb25hbGx5LCBhbmQgZm9yIG9idmlv
dXMgcmVhc29ucywgd2UgcHJvcG9zZSB0byByZW1vdmUgdGhlIHByb2hpYml0aW9uIChbZGNs
LmZjdF0vMTEpIGFnYWluc3QgZGVmaW5pbmcgdHlwZXMgaW4gcmV0dXJuIHR5cGUgc3BlY2lm
aWNhdGlvbnMuIFdlIGFkZGl0aW9uYWxseSBub3RlIHRoYXQgdGhpcyBwcm9oaWJpdGlvbiBp
cyBhbHJlYWR5IG5vdCBlbmZvcmNlZCBieSBhdCBsZWFzdCBvbmUgbWFqb3IgY29tcGlsZXIg
KE1TVkMpLiBXZSBmdXJ0aGVyIGJlbGlldmUgdGhpcyBwcm9oaWJpdGlvbiB0byBiZSBvdXRk
YXRlZDsgaXQgbWFkZSBzZW5zZSBpbiBDKys5OCwgYnV0IHdpdGggcmVjZW50IGNoYW5nZXMg
c3VjaCBhcyB0aGUgYWRkaXRpb24gb2YgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5k
ZWNsdHlwZTwvdHQ+IGFuZCB0aGUgYWJpbGl0eSB0byBvbWl0IHRoZSB0eXBlIG5hbWUgaW4g
YSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnJldHVybjwvdHQ+IHN0YXRlbWVudCBy
ZXR1cm5pbmcgYW4gaW4tcGxhY2UgY29uc3RydWN0ZWQgY2xhc3MsIHRoZSByZWFzb25zIGZv
ciB0aGUgcHJvaGliaXRpb24gaGF2ZSBiZWVuIGdyZWF0bHkgbWl0aWdhdGVkLiBUaGlzIG90
aGVyIHBhcnQgb2YgdGhpcyBwcm9wb3NhbCB3b3VsZCBsYXJnZWx5IHJlbW92ZSBhbnkgcmVt
YWluaW5nIG1vdGl2YXRpb24gZm9yIHRoZSBwcm9oaWJpdGlvbi48L3A+CjwvZGl2Pgo8ZGl2
IGNsYXNzPSJzZWN0aW9uIiBpZD0icHJvcG9zZWQtd29yZGluZyI+CjxoMT48YSBjbGFzcz0i
dG9jLWJhY2tyZWYiIGhyZWY9IiNpZDQiPlByb3Bvc2VkIFdvcmRpbmc8L2E+PC9oMT4KPHA+
KFByb3Bvc2VkIGNoYW5nZXMgYXJlIHNwZWNpZmllZCByZWxhdGl2ZSA8YSBjbGFzcz0icmVm
ZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3Nj
MjIvd2cyMS9kb2NzL3BhcGVycy8yMDE1L240NTY3LnBkZiI+TjQ1Njc8L2E+Lik8L3A+Cjxw
PkNoYW5nZSBbZGNsLnNwZWMuYXV0b10vMTMgKDcuMS42LjQuMTMpIGFzIGZvbGxvd3M6PC9w
Pgo8ZGl2IGNsYXNzPSJsaXRlcmFsLWJsb2NrIGNvbXBvdW5kIj4KPHAgY2xhc3M9ImNvbXBv
dW5kLWZpcnN0Ij5SZWRlY2xhcmF0aW9ucyBvciBzcGVjaWFsaXphdGlvbnMgb2YgYSBmdW5j
dGlvbiBvciBmdW5jdGlvbiB0ZW1wbGF0ZSB3aXRoIGEgZGVjbGFyZWQgcmV0dXJuIHR5cGUg
dGhhdCB1c2VzIGEgcGxhY2Vob2xkZXIgdHlwZSBzaGFsbCA8c3BhbiBjbGFzcz0icmVtb3Zh
bCI+YWxzbyB1c2UgdGhhdCBwbGFjZWhvbGRlcjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImFkZGl0
aW9uIj51c2UgZWl0aGVyIHRoYXQgcGxhY2Vob2xkZXIgb3IgYSBjb21wYXRpYmxlIGNvbmNy
ZXRlIHR5cGU8L3NwYW4+LCBub3QgYSBkZWR1Y2VkIHR5cGUuIDxzcGFuIGNsYXNzPSJhZGRp
dGlvbiI+SWYgdGhlIHJldHVybiB0eXBlIGhhcyBwcmV2aW91c2x5IGJlZW4gZGVkdWNlZCwg
YSBkZWNsYXJhdGlvbiB1c2luZyBhIGNvbmNyZXRlIHR5cGUgc2hhbGwgdXNlIHRoZSBkZWR1
Y2VkIHR5cGUuPC9zcGFuPgpbPGVtPkV4YW1wbGU6PC9lbT48L3A+CjxwcmUgY2xhc3M9ImNv
bXBvdW5kLWxhc3QgbGl0ZXJhbC1ibG9jayI+CmF1dG8gZigpOwphdXRvIGYoKSB7IHJldHVy
biA0MjsgfSAvLyByZXR1cm4gdHlwZSBpcyBpbnQKYXV0byBmKCk7IC8vIE9LCjxzcGFuIGNs
YXNzPSJyZW1vdmFsIj5pbnQgZigpOyAvLyBlcnJvciwgY2Fubm90IGJlIG92ZXJsb2FkZWQg
d2l0aCBhdXRvIGYoKTwvc3Bhbj4KPHNwYW4gY2xhc3M9ImFkZGl0aW9uIj5pbnQgZigpOyAv
LyBPSywgZGVkdWNlZCB0eXBlIGlzIGFsc28gaW50PC9zcGFuPgpkZWNsdHlwZShhdXRvKSBm
KCk7IC8vIGVycm9yLCBhdXRvIGFuZCBkZWNsdHlwZShhdXRvKSBkb24ndCBtYXRjaAoKPHNw
YW4gY2xhc3M9ImFkZGl0aW9uIj5hdXRvIGYoaW50KTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJh
ZGRpdGlvbiI+aW50IGYoaW50KTsgLy8gT0ssIHJldHVybiB0eXBlIG9mIGYoaW50KSBpcyBu
b3cgaW50PC9zcGFuPgo8c3BhbiBjbGFzcz0iYWRkaXRpb24iPmZsb2F0IGYoaW50KTsgLy8g
ZXJyb3IsIHJlZGVjbGFyZWQgd2l0aCBkaWZmZXJlbnQgcmV0dXJuIHR5cGU8L3NwYW4+Cjwv
cHJlPgo8L2Rpdj4KPHA+QWRkIGEgbmV3IHNlY3Rpb24gdG8gW2RjbC5zcGVjLmF1dG9dICg3
LjEuNi40KSBhcyBmb2xsb3dzOjwvcD4KPGRpdiBjbGFzcz0ibGl0ZXJhbC1ibG9jayBibG9j
ay1hZGRpdGlvbiBjb21wb3VuZCI+CjxwIGNsYXNzPSJjb21wb3VuZC1maXJzdCI+V2hlbiBh
IGZ1bmN0aW9uIGlzIGRlY2xhcmVkIG9yIGRlZmluZWQgdXNpbmcgYSBwbGFjZWhvbGRlciB0
eXBlIGZvciB0aGUgcmV0dXJuIHR5cGUsIGFuZCBhIHByZXZpb3VzIGRlY2xhcmF0aW9uIG9y
IGRlZmluaXRpb24gaGF2aW5nIGEgY29uY3JldGUgcmV0dXJuIHR5cGUgZXhpc3RzLCB0aGUg
cmV0dXJuIHR5cGUgc2hhbGwgYmUgaW5mZXJyZWQgdG8gYmUgdGhlIHByZXZpb3VzbHkgc2Vl
biBjb25jcmV0ZSB0eXBlLgpbPGVtPkV4YW1wbGU6PC9lbT48L3A+CjxwcmUgY2xhc3M9ImNv
bXBvdW5kLW1pZGRsZSBsaXRlcmFsLWJsb2NrIj4Kc3RkOjpzdHJpbmcgZigpOwphdXRvIGYo
KTsgLy8gT0ssIHJldHVybiB0eXBlIGlzIHN0ZDo6c3RyaW5nCjwvcHJlPgo8cCBjbGFzcz0i
Y29tcG91bmQtbGFzdCI+4oCUIDxlbT5lbmQgZXhhbXBsZTwvZW0+XTwvcD4KPC9kaXY+Cjxw
PkNoYW5nZSBbZGNsLmZjdF0vMTEgKDguMy41LjExKSBhcyBmb2xsb3dzOjwvcD4KPGRpdiBj
bGFzcz0ibGl0ZXJhbC1ibG9jayBjb21wb3VuZCI+CjxwPlR5cGVzIHNoYWxsIG5vdCBiZSBk
ZWZpbmVkIGluIDxzcGFuIGNsYXNzPSJyZW1vdmFsIj5yZXR1cm4gb3I8L3NwYW4+IHBhcmFt
ZXRlciB0eXBlcy48L3A+CjwvZGl2Pgo8L2Rpdj4KPGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9
ImRpc2N1c3Npb24iPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ1Ij5E
aXNjdXNzaW9uPC9hPjwvaDE+CjxwPkFuIG9idmlvdXMgZm9sbG93LW9uIHF1ZXN0aW9uIGlz
LCBzaG91bGQgd2UgYWxzbyBsaWZ0IHRoZSBwcm9oaWJpdGlvbiBhZ2FpbnN0IHR5cGVzIGRl
ZmluZWQgaW4gcGFyYW1ldGVyIHNwZWNpZmljYXRpb25zPyBUaGVyZSBoYXZlIGJlZW4gc3Vn
Z2VzdGlvbnMgZmxvYXRlZCB0byBpbXBsZW1lbnQgdGhlIG11Y2ggcmVxdWVzdGVkIG5hbWVk
IHBhcmFtZXRlcnMgaW4gc29tZXRoaW5nIGxpa2UgdGhpcyBtYW5uZXIuIEhvd2V2ZXIsIHRo
ZXJlIGFyZSBzaWduaWZpY2FudCAoaW4gb3VyIG9waW5pb24pIHJlYXNvbnMgdG8gbm90IGFk
ZHJlc3MgdGhpcywgYXQgbGVhc3QgaW5pdGlhbGx5LiBGaXJzdCwgaXQgaXMgd2lkZWx5IGNv
bnRlc3RlZCB0aGF0IHRoaXMgaXMgbm90IGFuIG9wdGltYWwgc29sdXRpb24gdG8gdGhlIHBy
b2JsZW0gKG5hbWVkIHBhcmFtZXRlcnMpIGluIHRoZSBmaXJzdCBwbGFjZS4gU2Vjb25kLCBp
dCBkZXBlbmRzIG9uIG5hbWVkIGluaXRpYWxpemVycywgd2hpY2ggaXMgYW4gYXJlYSBvZiBv
bmdvaW5nIHdvcmsuIFRoaXJkLCB0aGlzIHByb3Bvc2FsIHdvcmtzIGxhcmdlbHkgYmVjYXVz
ZSBDKysgZm9yYmlkcyBvdmVybG9hZGluZyBvbiByZXR1cm4gdHlwZSwgd2hpY2ggbWF5IGJl
IGxldmVyYWdlZCB0byBlbGltaW5hdGUgYW55IGFtYmlndWl0eSBhcyB0byB0aGUgZGVkdWN0
aW9uIG9mIHRoZSBhY3R1YWwgdHlwZSBvZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwi
PmF1dG88L3R0PjsgdGhpcyBpcyBub3QgdGhlIGNhc2UgZm9yIHBhcmFtZXRlcnMsIGFuZCBz
byBwZXJtaXR0aW5nIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+IGFz
IGEgcGFyYW1ldGVyIHR5cGUgc3BlY2lmaWVyIHdvdWxkIHF1aWNrbHkgcnVuIGludG8gaXNz
dWVzIHRoYXQgY2FuIGJlIGF2b2lkZWQgZm9yIHRoZSByZXR1cm4gdHlwZSBjYXNlLjwvcD4K
PHA+V2hpbGUgd2UgZG8gbm90IHdpc2ggdG8gY2F0ZWdvcmljYWxseSBydWxlIG91dCBmdXR1
cmUgY2hhbmdlcyBpbiB0aGlzIGRpcmVjdGlvbiwgd2UgZmVlbCB0aGF0IGl0IGlzIG5vdCBh
cHByb3ByaWF0ZSBmb3IgdGhpcyBwcm9wb3NhbCB0byBhdHRlbXB0IHRvIGFkZHJlc3MgdGhl
c2UgaXNzdWVzLjwvcD4KPHA+T24gYSByZWxhdGVkIG5vdGUsIGl0IGlzIG5vdCBzdHJpY3Rs
eSBuZWNlc3NhcnkgZm9yIHRoZSBzYWtlIG9mIHRoZSBhZGRlZCB1dGlsaXR5IG9mIGltcGxp
ZWQgcmV0dXJuIHR5cGUgdG8gcmVsYXggW2RjbC5mY3RdLzExLiBIb3dldmVyLCBtdWNoIG9m
IHRoZSBiZW5lZml0IGlzIGxvc3Qgd2l0aCB0aGlzIHByb2hpYml0aW9uIGluIHBsYWNlLiBD
b252ZXJzZWx5LCBzaW1wbHkgcmVsYXhpbmcgdGhlIHByb2hpYml0aW9uIGlzIG9mIHNpZ25p
ZmljYW50bHkgbGVzcyBiZW5lZml0IHdpdGhvdXQgdGhlIHByb3Bvc2VkIGltcGxpZWQgcmV0
dXJuIHR5cGUgZmVhdHVyZS4gQWNjb3JkaW5nbHksIHdoaWxlIHdlIGNvbnNpZGVyZWQgc3Bs
aXR0aW5nIHRoZSB0d28gY2hhbmdlcyBpbnRvIHNlcGFyYXRlIHByb3Bvc2Fscywgd2UgaGF2
ZSBkZWNpZGVkIGZvciBub3cgdG8ga2VlcCB0aGVtIHRvZ2V0aGVyLjwvcD4KPHA+QW5vdGhl
ciBxdWVzdGlvbiB0aGF0IGhhcyBjb21lIHVwIGlzIGlmIHNvbWV0aGluZyBsaWtlIHRoaXMg
c2hvdWxkIGJlIGFsbG93ZWQ6PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFsLWJs
b2NrIj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8
L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+
IDxzcGFuIGNsYXNzPSJuYW1lIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij4oKTwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij59PC9zcGFuPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUi
PmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmJhcjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPigpPC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+CiAg
PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
PmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigpOzwvc3Bhbj4KPHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+VW5kZXIgdGhlIGN1cnJl
bnQgcnVsZXMgKHBsdXMgcmVsYXhlZCBbZGNsLmZjdF0vMTEpLCB0aGVzZSB0d28gZGVmaW5p
dGlvbnMgaGF2ZSBkaWZmZXJlbnQgcmV0dXJuIHR5cGVzIHdoaWNoIGFyZSBub3QgY29udmVy
dGlibGUuIEl0IGlzIG91ciBvcGluaW9uIHRoYXQgdGhlIHJ1bGVzIG1ha2luZyB0aGVzZSB0
eXBlcyBkaWZmZXJlbnQgYXJlIGluIGZhY3QgY29ycmVjdCBhbmQgZGVzaXJhYmxlLCBhbmQg
dGhpcyBwcm9wb3NhbCBzcGVjaWZpY2FsbHkgZG9lcyA8ZW0+bm90PC9lbT4gaW5jbHVkZSBh
bnkgY2hhbmdlcyB3aGljaCB3b3VsZCBtYWtlIHRoZSB0eXBlcyBjb21wYXRpYmxlLiBXZSB3
b3VsZCwgaG93ZXZlciwgZW5jb3VyYWdlIGEgZnV0dXJlIChvcnRob2dvbmFsKSBwcm9wb3Nh
bCB3aGljaCB3b3VsZCBhbGxvdyBzb21ldGhpbmcgbGlrZSB0aGlzOjwvcD4KPHByZSBjbGFz
cz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1
Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xh
c3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+cmVzdWx0
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+YmFyPC9zcGFuPjxz
cGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIFRoZSAn
WypdJyBvcGVyYXRvciBoZXJlIGNhdXNlcyB0aGUgY29tcGlsZXIgdG8gc3RvcmUgdGhlIGlu
cHV0IGFzIGEKPC9zcGFuPiAgPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyB0ZW1w
b3JhcnkgYW5kIGdlbmVyYXRlIGFuIGV4cHJlc3Npb24gbGlzdCBmcm9tIHRoZSB1bnBhY2tl
ZCBtZW1iZXJzIG9mCjwvc3Bhbj4gIDxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8g
dGhlIHNhbWU7IGl0IGNhbiBiZSB1c2VkIGFueXdoZXJlIGFuIGV4cHJlc3Npb24gbGlzdCBp
cyBhY2NlcHRlZAo8L3NwYW4+ICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFu
PiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+Wzwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPio8L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj5dPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj5mb288L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj59Ozwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFu
Pgo8L3ByZT4KPCEtLSAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAu
LiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAtLT4KPC9kaXY+CjwvZGl2Pgo8
L2JvZHk+CjwvaHRtbD4K
--------------030403040308090000070304--


.

------=_Part_6930_865459106.1451585522290
Content-Type: multipart/alternative;
 boundary="----=_Part_6931_1188934840.1451585522291"

------=_Part_6931_1188934840.1451585522291
Content-Type: text/plain; charset=UTF-8



On Thursday, December 31, 2015 at 12:50:39 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-31 11:16, Matthew Woehlke wrote:
> > On 2015-12-31 07:44, T. C. wrote:
> >> This is currently legal and declares two separate function templates:
> >>
> >> template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
> >> template<class T> auto foo();
> >
> > Okay, wow... now my head hurts... Just *how* exactly am I supposed to
> > distinguish between these?
> >
> > This... seems broken.
> >
> > Suggestions how to address this welcome...
>
> Better question: if those declare two separate templates, you are never
> going to be able to use either one due to ambiguity.


Unless you explicitly disambiguate, e.g., by converting to a function
pointer.


> Would it be acceptable to just say that, no, the second one repeats the
> first?
>

Perhaps. But it should be discussed rather than glossed over. You started
from the premise that "in C++, functions cannot be overloaded by their
return
value", which is not true for function templates.

You'll also need wording to handle ambiguities.

template<class T> std::enable_if_t<std::is_integral<T>{}> foo();
template<class T> std::enable_if_t<!std::is_integral<T>{}> foo();
template<class T> auto foo(); // which one?

Also, your draft wording applies to declarations returning decltype(auto)
as well. Is that intended?

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6931_1188934840.1451585522291
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, December 31, 2015 at 12:50:39 PM UTC-=
5, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20=
15-12-31 11:16, Matthew Woehlke wrote:
<br>&gt; On 2015-12-31 07:44, T. C. wrote:
<br>&gt;&gt; This is currently legal and declares two separate function tem=
plates:
<br>&gt;&gt;
<br>&gt;&gt; template&lt;class T&gt; std::enable_if_t&lt;std::is_same&lt;<w=
br>T, int&gt;{}&gt; foo();
<br>&gt;&gt; template&lt;class T&gt; auto foo();
<br>&gt;=20
<br>&gt; Okay, wow... now my head hurts... Just *how* exactly am I supposed=
 to
<br>&gt; distinguish between these?
<br>&gt;=20
<br>&gt; This... seems broken.
<br>&gt;=20
<br>&gt; Suggestions how to address this welcome...
<br>
<br>Better question: if those declare two separate templates, you are never
<br>going to be able to use either one due to ambiguity. </blockquote><div>=
<br></div><div>Unless you explicitly disambiguate, e.g., by converting to a=
 function pointer.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">Would it be
acceptable to just say that, no, the second one repeats the first?
<br></blockquote><div><br></div>Perhaps. But it should be discussed rather =
than glossed over. You started<div>from the premise that &quot;in C++, func=
tions cannot be overloaded by their return=C2=A0</div><div>value&quot;, whi=
ch is not true for function templates.</div><div><br></div><div>You&#39;ll =
also need wording to handle ambiguities.</div><div><br></div><div class=3D"=
prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">enable_if_t</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">is_integral</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;{}&gt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">enable_if_t</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;!</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">is_integral</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;{}&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fo=
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// which =
one?</span><font color=3D"#880000"></font></div></code></div><div><br></div=
><div><div><div>Also, your draft wording applies to declarations returning =
decltype(auto) as well. Is that intended?</div></div></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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6931_1188934840.1451585522291--
------=_Part_6930_865459106.1451585522290--

.

On 2015-12-31 13:12, T. C. wrote:
> On Thursday, December 31, 2015 at 12:50:39 PM UTC-5, Matthew Woehlke wrote:
>> On 2015-12-31 07:44, T. C. wrote:
>>> This is currently legal and declares two separate function templates:
>>>
>>> template<class T> std::enable_if_t<std::is_same<T, int>{}> foo();
>>> template<class T> auto foo();
>>
>> Would it be acceptable to just say that, no, the second one repeats the
>> first?
>
> Perhaps. But it should be discussed rather than glossed over. You started
> from the premise that "in C++, functions cannot be overloaded by their
> return value", which is not true for function templates.

Fair enough. Will try to get to it tomorrow or early next week.

> You'll also need wording to handle ambiguities.
>
> template<class T> std::enable_if_t<std::is_integral<T>{}> foo();
> template<class T> std::enable_if_t<!std::is_integral<T>{}> foo();
> template<class T> auto foo(); // which one?

Again, suggestions welcomed. I'd prefer to not have to simply exclude
templates, especially as templates seem to be a major use case. However
I don't offhand see *how* one would resolve this.

> Also, your draft wording applies to declarations returning decltype(auto)
> as well. Is that intended?

Inertia? Laziness? More importantly, is there a reason it shouldn't?

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6750_1629825731.1451587136449
Content-Type: multipart/alternative;
 boundary="----=_Part_6751_357426605.1451587136449"

------=_Part_6751_357426605.1451587136449
Content-Type: text/plain; charset=UTF-8



On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-31 13:12, T. C. wrote:
> > You'll also need wording to handle ambiguities.
> >
> > template<class T> std::enable_if_t<std::is_integral<T>{}> foo();
> > template<class T> std::enable_if_t<!std::is_integral<T>{}> foo();
> > template<class T> auto foo(); // which one?
>
> Again, suggestions welcomed. I'd prefer to not have to simply exclude
> templates, especially as templates seem to be a major use case. However
> I don't offhand see *how* one would resolve this.
>

The obvious choice is to make it ill-formed if auto can acquire a concrete
type
from more than one declaration.


>
> > Also, your draft wording applies to declarations returning
> decltype(auto)
> > as well. Is that intended?
>
> Inertia? Laziness? More importantly, is there a reason it shouldn't?
>

Because `decltype(auto)` is a strong indicator that the return type really
should
be deduced? Allowing it to be replaced is like saying "I'd like you to
deduce the
type using these special decltype rules......wait, never mind". It doesn't
make
much sense to me.

Note that only `auto` can introduce trailing return types, not
`decltype(auto)`.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6751_357426605.1451587136449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, December 31, 2015 at 1:27:56 PM UTC-5=
, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 201=
5-12-31 13:12, T. C. wrote:
<br>&gt; You&#39;ll also need wording to handle ambiguities.
<br>&gt;=20
<br>&gt; template&lt;class T&gt; std::enable_if_t&lt;std::is_<wbr>integral&=
lt;T&gt;{}&gt; foo();
<br>&gt; template&lt;class T&gt; std::enable_if_t&lt;!std::is_<wbr>integral=
&lt;T&gt;{}&gt; foo();
<br>&gt; template&lt;class T&gt; auto foo(); // which one?
<br>
<br>Again, suggestions welcomed. I&#39;d prefer to not have to simply exclu=
de
<br>templates, especially as templates seem to be a major use case. However
<br>I don&#39;t offhand see *how* one would resolve this.
<br></blockquote><div><br></div><div>The obvious choice is to make it ill-f=
ormed if auto can acquire a concrete type</div><div>from more than one decl=
aration.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
<br>&gt; Also, your draft wording applies to declarations returning decltyp=
e(auto)=20
<br>&gt; as well. Is that intended?
<br>
<br>Inertia? Laziness? More importantly, is there a reason it shouldn&#39;t=
?=C2=A0<br></blockquote><div><br></div><div>Because `decltype(auto)` is a s=
trong indicator that the return type really should</div><div>be deduced? Al=
lowing it to be replaced is like saying &quot;I&#39;d like you to deduce th=
e</div><div>type using these special decltype rules......wait, never mind&q=
uot;. It doesn&#39;t make</div><div>much sense to me.</div><div><br></div><=
div>Note that only `auto` can introduce trailing return types, not `decltyp=
e(auto)`.</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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6751_357426605.1451587136449--
------=_Part_6750_1629825731.1451587136449--

.

This is a multi-part message in MIME format.
--------------090709070000020705010309
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 31/12/2015 18:49, T. C. a =C3=A9crit :
>
>
> On Thursday, December 31, 2015 at 12:39:33 PM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 31/12/2015 13:44, T. C. a =C3=A9crit :
>>
>>
>>     On Thursday, December 31, 2015 at 1:06:13 AM UTC-5, Vicente J.
>>     Botet Escriba wrote:
>>
>>         Le 30/12/2015 23:49, T. C. a =C3=A9crit :
>>>
>>>         Does this apply to function templates, whose signature
>>>         *does* include the return type?
>>         Could you give an example?
>>
>>
>>     This is currently legal and declares two separate function templates=
:
>>
>>     |
>>     template<classT>std::enable_if_t<std::is_same<T,int>{}>foo();
>>     template<classT>autofoo();
>>     |
>>
>>
>     With concepts this would be
>
>     |
>     template<classT>requires std::is_same<T,int>{}void foo();
>     template<classT>|requires std::is_same<T,int>{}|autofoo();
>     |
>
>
> The second foo wasn't constrained. You added one.
Oh, I believed that the second one was the one that uses this feature.

I've got now the issue you were raising. This exclude any template=20
having template parameters that are not deduced :(
> Regardless, GCC trunk - the only concepts implementation I know of -=20
> is perfectly happy to compile
> |
> #include<type_traits>
> template<classT>requires std::is_same<T,int>::value voidfoo(){}
> template<classT>requires std::is_same<T,int>::value autofoo(){return1;}
>
> int(*p)()=3Dfoo<int>;
> void(*pp)()=3Dfoo<int>;
> |
>
>
This is really surprising.

Vicente

--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------090709070000020705010309
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 31/12/2015 18:49, T. C. a =C3=A9crit=
=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:43bc4027-1871-4c2b-812d-902255c8ffca@isocpp.org"
      type=3D"cite"><br>
      <br>
      On Thursday, December 31, 2015 at 12:39:33 PM UTC-5, Vicente J.
      Botet Escriba 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">
          <div>Le 31/12/2015 13:44, T. C. a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">
            <div dir=3D"ltr"><br>
              <br>
              On Thursday, December 31, 2015 at 1:06:13 AM UTC-5,
              Vicente J. Botet Escriba 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">
                  <div>Le 30/12/2015 23:49, T. C. a =C3=A9crit=C2=A0:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div><br>
                    </div>
                    <div>Does this apply to function templates, whose
                      signature *does* include the return type?</div>
                  </blockquote>
                  Could you give an example?<br>
                </div>
              </blockquote>
              <div><br>
              </div>
              <div>This is currently legal and declares two separate
                function templates:</div>
              <div><br>
              </div>
              <div style=3D"border:1px solid
                rgb(187,187,187);word-wrap:break-word;background-color:rgb(=
250,250,250)"><code>
                  <div><span style=3D"color:#008">template</span><span
                      style=3D"color:#660">&lt;</span><span
                      style=3D"color:#008">class</span><span
                      style=3D"color:#000"> T</span><span
                      style=3D"color:#660">&gt;</span><span
                      style=3D"color:#000"> std</span><span
                      style=3D"color:#660">::</span><span
                      style=3D"color:#000">enable_if_t</span><span
                      style=3D"color:#660">&lt;</span><span
                      style=3D"color:#000">std</span><span
                      style=3D"color:#660">::</span><span
                      style=3D"color:#000">is_same</span><span
                      style=3D"color:#660">&lt;</span><span
                      style=3D"color:#000"><wbr>T</span><span
                      style=3D"color:#660">,</span><span
                      style=3D"color:#000"> </span><span
                      style=3D"color:#008">int</span><span
                      style=3D"color:#660">&gt;{}&gt;</span><span
                      style=3D"color:#000"> foo</span><span
                      style=3D"color:#660">();</span><span
                      style=3D"color:#000"><br>
                    </span><span style=3D"color:#008">template</span><span
                      style=3D"color:#660">&lt;</span><span
                      style=3D"color:#008">class</span><span
                      style=3D"color:#000"> T</span><span
                      style=3D"color:#660">&gt;</span><span
                      style=3D"color:#000"> </span><span
                      style=3D"color:#008">auto</span><span
                      style=3D"color:#000"> foo</span><span
                      style=3D"color:#660">();</span><span
                      style=3D"color:#000"><br>
                    </span></div>
                </code></div>
              <div><br>
              </div>
            </div>
            <br>
          </blockquote>
          With concepts this would be<br>
          <br>
          <div style=3D"border:1px solid
            rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,=
250,250)"><code>
              <div><span style=3D"color:#008">template</span><span
                  style=3D"color:#660">&lt;</span><span style=3D"color:#008=
">class</span><span
                  style=3D"color:#000"> T</span><span style=3D"color:#660">=
&gt;</span><span
                  style=3D"color:#000"> requires </span><span
                  style=3D"color:#000">std</span><span style=3D"color:#660"=
>::</span><span
                  style=3D"color:#000">is_same</span><span
                  style=3D"color:#660">&lt;</span><span style=3D"color:#000=
">T</span><span
                  style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span
                  style=3D"color:#008">int</span><span style=3D"color:#660"=
>&gt;{}</span><span
                  style=3D"color:#000"> void foo</span><span
                  style=3D"color:#660">();</span><span style=3D"color:#000"=
><br>
                </span><span style=3D"color:#008">template</span><span
                  style=3D"color:#660">&lt;</span><span style=3D"color:#008=
">class</span><span
                  style=3D"color:#000"> T</span><span style=3D"color:#660">=
&gt;</span><span
                  style=3D"color:#000"> </span><code><span
                    style=3D"color:#000">requires </span><span
                    style=3D"color:#000">std</span><span
                    style=3D"color:#660">::</span><span style=3D"color:#000=
">is_same</span><span
                    style=3D"color:#660">&lt;</span><span
                    style=3D"color:#000">T</span><span style=3D"color:#660"=
>,</span><span
                    style=3D"color:#000"> </span><span style=3D"color:#008"=
>int</span><span
                    style=3D"color:#660">&gt;{}</span><span
                    style=3D"color:#000"> </span></code><span
                  style=3D"color:#008">auto</span><span style=3D"color:#000=
">
                  foo</span><span style=3D"color:#660">();</span><span
                  style=3D"color:#000"><br>
                </span></div>
            </code></div>
          <div><br>
          </div>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>The second foo wasn't constrained. You added one.</div>
    </blockquote>
    Oh, I believed that the second one was the one that uses this
    feature.<br>
    <br>
    I've got now the issue you were raising. This exclude any template
    having template parameters that are not deduced :(<br>
    <blockquote
      cite=3D"mid:43bc4027-1871-4c2b-812d-902255c8ffca@isocpp.org"
      type=3D"cite">
      <div>=C2=A0</div>
      <div>Regardless, GCC trunk - the only concepts implementation I
        know of - is perfectly happy to compile</div>
      <div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
        187); word-wrap: break-word; background-color: rgb(250, 250,
        250);"><code class=3D"prettyprint">
          <div class=3D"subprettyprint"><span style=3D"color: #800;"
              class=3D"styled-by-prettify">#include</span><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
              style=3D"color: #080;" class=3D"styled-by-prettify">&lt;type_=
traits&gt;</span><span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span
              style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> T</span>=
<span
              style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> requires
              std</span><span style=3D"color: #660;"
              class=3D"styled-by-prettify">::</span><span style=3D"color:
              #000;" class=3D"styled-by-prettify">is_same</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</s=
pan><span
              style=3D"color: #000;" class=3D"styled-by-prettify">value </s=
pan><span
              style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><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: #660;" class=3D"styled-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>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span
              style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> T</span>=
<span
              style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> requires
              std</span><span style=3D"color: #660;"
              class=3D"styled-by-prettify">::</span><span style=3D"color:
              #000;" class=3D"styled-by-prettify">is_same</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify">T</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: #008;" class=3D"styled-by-prettify">int</span=
><span
              style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</s=
pan><span
              style=3D"color: #000;" class=3D"styled-by-prettify">value </s=
pan><span
              style=3D"color: #008;" class=3D"styled-by-prettify">auto</spa=
n><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><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: #660;" class=3D"styled-by-prettify">{</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
              style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
              style=3D"color: #066;" class=3D"styled-by-prettify">1</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: #660;" class=3D"styled-by-prettify">}</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              <br>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</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">p</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: #660;" class=3D"styled-by-prettify">=3D</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><span
              style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&g=
t;</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span
              style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">void</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">pp</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: #660;" class=3D"styled-by-prettify">=3D</span=
><span
              style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><span
              style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&g=
t;</span><span
              style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
/div>
        </code></div>
      <div>
        <div><br>
        </div>
      </div>
      <br>
    </blockquote>
    This is really surprising.<br>
    <br>
    Vicente<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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------090709070000020705010309--

.

On 2015-12-31 13:38, T. C. wrote:
> On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlke wrote:
>> On 2015-12-31 13:12, T. C. wrote:
>>> You'll also need wording to handle ambiguities.
>>>
>>> template<class T> std::enable_if_t<std::is_integral<T>{}> foo();
>>> template<class T> std::enable_if_t<!std::is_integral<T>{}> foo();
>>> template<class T> auto foo(); // which one?
>>
>> Again, suggestions welcomed. I'd prefer to not have to simply exclude
>> templates, especially as templates seem to be a major use case. However
>> I don't offhand see *how* one would resolve this.
>
> The obvious choice is to make it ill-formed if auto can acquire a
> concrete type from more than one declaration.

Is it? As you pointed out, right now this is legal:

  template <class T> int foo();
  template <class T> auto foo();

....and declares two different functions. Are you suggesting that the
second should now be considered a redeclaration of the first rather than
a new declaration?

*That* is the problem as I see it. If "yes", the the other details, as
you note, lend themselves to obvious resolution.

>>> Also, your draft wording applies to declarations returning
>>> decltype(auto) as well. Is that intended?
>>
>> Inertia? Laziness? More importantly, is there a reason it shouldn't?
>
> Because `decltype(auto)` is a strong indicator that the return type
> really should be deduced?

Hmm... "inference" vs. "deduction"... I guess I can see it... Anyway, I
don't see an obvious benefit, so if it makes others feel better... :-)

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_7116_272503947.1451589096768
Content-Type: multipart/alternative;
 boundary="----=_Part_7117_127815257.1451589096768"

------=_Part_7117_127815257.1451589096768
Content-Type: text/plain; charset=UTF-8



On Thursday, December 31, 2015 at 2:01:04 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-31 13:38, T. C. wrote:
> > On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlke
> wrote:
> >> On 2015-12-31 13:12, T. C. wrote:
> >>> You'll also need wording to handle ambiguities.
> >>>
> >>> template<class T> std::enable_if_t<std::is_integral<T>{}> foo();
> >>> template<class T> std::enable_if_t<!std::is_integral<T>{}> foo();
> >>> template<class T> auto foo(); // which one?
> >>
> >> Again, suggestions welcomed. I'd prefer to not have to simply exclude
> >> templates, especially as templates seem to be a major use case. However
> >> I don't offhand see *how* one would resolve this.
> >
> > The obvious choice is to make it ill-formed if auto can acquire a
> > concrete type from more than one declaration.
>
> Is it? As you pointed out, right now this is legal:
>
>   template <class T> int foo();
>   template <class T> auto foo();
>
> ...and declares two different functions. Are you suggesting that the
> second should now be considered a redeclaration of the first rather than
> a new declaration?


> *That* is the problem as I see it. If "yes", the the other details, as
> you note, lend themselves to obvious resolution.
>

I don't see a way to get around it. If

int foo();
auto foo();

are redeclarations, then

  template <class T> int foo();
  template <class T> auto foo();

should be, too. Anything else would be even more surprising.

I think a good argument can probably be made that actual code
breakage would be minimal, because the type of code that would
change meaning declares function templates that are hard (though
not completely impossible) to actually use.


--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7117_127815257.1451589096768
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, December 31, 2015 at 2:01:04 PM UTC-5, Matthew Woehlke=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-31 13:38, T.=
 C. wrote:
<br>&gt; On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlk=
e wrote:
<br>&gt;&gt; On 2015-12-31 13:12, T. C. wrote:=20
<br>&gt;&gt;&gt; You&#39;ll also need wording to handle ambiguities.=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; template&lt;class T&gt; std::enable_if_t&lt;std::is_<wbr>i=
ntegral&lt;T&gt;{}&gt; foo();=20
<br>&gt;&gt;&gt; template&lt;class T&gt; std::enable_if_t&lt;!std::is_<wbr>=
integral&lt;T&gt;{}&gt; foo();=20
<br>&gt;&gt;&gt; template&lt;class T&gt; auto foo(); // which one?=20
<br>&gt;&gt;
<br>&gt;&gt; Again, suggestions welcomed. I&#39;d prefer to not have to sim=
ply exclude=20
<br>&gt;&gt; templates, especially as templates seem to be a major use case=
.. However=20
<br>&gt;&gt; I don&#39;t offhand see *how* one would resolve this.=20
<br>&gt;=20
<br>&gt; The obvious choice is to make it ill-formed if auto can acquire a
<br>&gt; concrete type from more than one declaration.
<br>
<br>Is it? As you pointed out, right now this is legal:
<br>
<br>=C2=A0 template &lt;class T&gt; int foo();
<br>=C2=A0 template &lt;class T&gt; auto foo();
<br>
<br>...and declares two different functions. Are you suggesting that the
<br>second should now be considered a redeclaration of the first rather tha=
n
<br>a new declaration?=C2=A0</blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
<br>*That* is the problem as I see it. If &quot;yes&quot;, the the other de=
tails, as
<br>you note, lend themselves to obvious resolution.
<br></blockquote><div><br></div><div>I don&#39;t see a way to get around it=
.. If</div><div><br>int foo();=C2=A0<br>auto foo();=C2=A0<br></div><div><br>=
</div><div>are redeclarations, then=C2=A0</div><div><br>=C2=A0 template &lt=
;class T&gt; int foo();=C2=A0<br>=C2=A0 template &lt;class T&gt; auto foo()=
;=C2=A0<br></div><div><br></div><div>should be, too. Anything else would be=
 even more surprising.</div><div><br></div><div>I think a good argument can=
 probably be made that actual code=C2=A0</div><div>breakage would be minima=
l, because the type of code that would</div><div>change meaning declares fu=
nction templates that are hard (though</div><div>not completely impossible)=
 to actually use.</div><div>=C2=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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_7117_127815257.1451589096768--
------=_Part_7116_272503947.1451589096768--

.

On 2015-12-31 14:00, Matthew Woehlke wrote:
> On 2015-12-31 13:38, T. C. wrote:
>> On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlke wrote:
>>> On 2015-12-31 13:12, T. C. wrote:
>>>> Also, your draft wording applies to declarations returning
>>>> decltype(auto) as well. Is that intended?
>>>
>>> Inertia? Laziness? More importantly, is there a reason it shouldn't?
>>
>> Because `decltype(auto)` is a strong indicator that the return type
>> really should be deduced?
>
> Hmm... "inference" vs. "deduction"... I guess I can see it... Anyway, I
> don't see an obvious benefit, so if it makes others feel better... :-)

Updated. However, I left the wording to allow:

  decltype(auto) foo();
  int foo();

This way the relaxing of the [dcl.spec.auto]/13 prohibition is
consistent. Is there a strong desire to also forbid this?

I could see where it might even be useful:

  decltype(auto) foo() { ... }
  int foo(); // enforce that return type was deduced to int

(Granted, you could also use a static_assert(is_same_type)...)

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6979_1892861816.1451589797270
Content-Type: multipart/alternative;
 boundary="----=_Part_6980_1399782384.1451589797270"

------=_Part_6980_1399782384.1451589797270
Content-Type: text/plain; charset=UTF-8



On Thursday, December 31, 2015 at 2:18:50 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-31 14:00, Matthew Woehlke wrote:
> > On 2015-12-31 13:38, T. C. wrote:
> >> On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Woehlke
> wrote:
> >>> On 2015-12-31 13:12, T. C. wrote:
> >>>> Also, your draft wording applies to declarations returning
> >>>> decltype(auto) as well. Is that intended?
> >>>
> >>> Inertia? Laziness? More importantly, is there a reason it shouldn't?
> >>
> >> Because `decltype(auto)` is a strong indicator that the return type
> >> really should be deduced?
> >
> > Hmm... "inference" vs. "deduction"... I guess I can see it... Anyway, I
> > don't see an obvious benefit, so if it makes others feel better... :-)
>
> Updated. However, I left the wording to allow:
>
>   decltype(auto) foo();
>   int foo();
>
> This way the relaxing of the [dcl.spec.auto]/13 prohibition is
> consistent. Is there a strong desire to also forbid this?
>
> I could see where it might even be useful:
>
>   decltype(auto) foo() { ... }
>   int foo(); // enforce that return type was deduced to int
>
> (Granted, you could also use a static_assert(is_same_type)...)
>

So, should

int i;
decltype(auto) foo();
int foo() { return i; }

compile? Note that

int i;
decltype(auto) foo()  { return i; }
int foo();

presumably won't.


--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6980_1399782384.1451589797270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, December 31, 2015 at 2:18:50 PM UTC-5, Matthew Woehlke=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-31 14:00, Ma=
tthew Woehlke wrote:
<br>&gt; On 2015-12-31 13:38, T. C. wrote:
<br>&gt;&gt; On Thursday, December 31, 2015 at 1:27:56 PM UTC-5, Matthew Wo=
ehlke wrote:
<br>&gt;&gt;&gt; On 2015-12-31 13:12, T. C. wrote:=20
<br>&gt;&gt;&gt;&gt; Also, your draft wording applies to declarations retur=
ning=20
<br>&gt;&gt;&gt;&gt; decltype(auto) as well. Is that intended?
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Inertia? Laziness? More importantly, is there a reason it =
shouldn&#39;t?=20
<br>&gt;&gt;
<br>&gt;&gt; Because `decltype(auto)` is a strong indicator that the return=
 type
<br>&gt;&gt; really should be deduced?
<br>&gt;=20
<br>&gt; Hmm... &quot;inference&quot; vs. &quot;deduction&quot;... I guess =
I can see it... Anyway, I
<br>&gt; don&#39;t see an obvious benefit, so if it makes others feel bette=
r... :-)
<br>
<br>Updated. However, I left the wording to allow:
<br>
<br>=C2=A0 decltype(auto) foo();
<br>=C2=A0 int foo();
<br>
<br>This way the relaxing of the [dcl.spec.auto]/13 prohibition is
<br>consistent. Is there a strong desire to also forbid this?
<br>
<br>I could see where it might even be useful:
<br>
<br>=C2=A0 decltype(auto) foo() { ... }
<br>=C2=A0 int foo(); // enforce that return type was deduced to int
<br>
<br>(Granted, you could also use a static_assert(is_same_type)...<wbr>)
<br></blockquote><div><br></div><div>So, should</div><div><br></div><div>in=
t i;</div><div>decltype(auto) foo();</div><div>int foo() { return i; }</div=
><div><br></div><div>compile? Note that </div><div><br></div><div><div>int =
i;</div><div>decltype(auto) foo() =C2=A0{ return i; }</div><div>int foo();<=
/div></div><div><br></div><div>presumably won&#39;t.</div><div><br></div><d=
iv><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6980_1399782384.1451589797270--
------=_Part_6979_1892861816.1451589797270--

.

On 2015-12-31 14:11, T. C. wrote:
> On Thursday, December 31, 2015 at 2:01:04 PM UTC-5, Matthew Woehlke wrote:
>> As you pointed out, right now this is legal:
>>
>>   template <class T> int foo();
>>   template <class T> auto foo();
>>
>> ...and declares two different functions. Are you suggesting that the
>> second should now be considered a redeclaration of the first rather than
>> a new declaration?
>>
>> *That* is the problem as I see it. If "yes", the the other details, as
>> you note, lend themselves to obvious resolution.
>
> I don't see a way to get around it. If
>
> int foo();
> auto foo();
>
> are redeclarations, then
>
>   template <class T> int foo();
>   template <class T> auto foo();
>
> should be, too. Anything else would be even more surprising.
>
> I think a good argument can probably be made that actual code
> breakage would be minimal, because the type of code that would
> change meaning declares function templates that are hard (though
> not completely impossible) to actually use.

Okay, I'll plan to write it up that way (probably not tonight yet,
but...). TBH, that's my preference as well (the current behavior makes
me go 'wtf?!'), though I'm concerned by it being a breaking change.

Thanks for all the feedback!

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-31 14:23, T. C. wrote:
> So, should
>
> int i;
> decltype(auto) foo();
> int foo() { return i; }
>
> compile?

Under the current proposed wording, yes. In this case, 'decltype(auto)'
is "just" a placeholder for "I haven't told you yet". In the definition,
you are "resolving" the placeholder to definitely be "int".

> Note that
>
> int i;
> decltype(auto) foo()  { return i; }
> int foo();
>
> presumably won't.

Ah... it won't?

I admit, I'm not familiar with the arcane details of decltype(auto) as a
return type. However, [dcl.spec.auto]/7 gives the type of 'int i;
decltype(auto) x = i' as 'int'. It's unclear why a return statement
would have a different result?

That's a tangent, however. I'll assume that your intent is for the
'decltype(auto)' in the above to be other than plain 'int', in which
case the example would indeed not compile.

That said, note that there is a critical difference between the two
examples. The first is merely deferring resolution of the return type.
This seems okay, even if the deduced type would have been different. The
second requests a deduced return type and then gives an incompatible
declaration. This has never been okay (for non-templates, at least) and
remains not-okay.

Consider a different example:

  auto foo();
  long foo() { return 42; }

If I had written 'auto' both times, the return type would be 'int'.
Because I specified it, however, I have implicitly caused a cast to
occur in the return statement. IOW, I have effectively written:

  auto foo() { return long{42}; }

The above can be considered similarly:

  int& i = ...;
  int foo() { return i; } // decltype(auto) foo() { return int{i}; }

FWIW, if this all proves too controversial, I believe it is okay to drop
this part of the proposal. Its main purpose is to address the possible
need to partially declare a function before the return type is known,
and so that there is symmetry with e.g.:

  // "Main" proposal
  int foo();
  auto foo();

....and:

  // Modification to [dcl.spec.auto]/13
  auto foo();
  int foo();

....because it seems likely to be confusing if the former works but the
latter does not. However, that isn't strictly necessary to use the main
(IRTVPDUA) feature; it just means that the first declaration *must* have
a concrete type.

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_643_1153540931.1451595316409
Content-Type: multipart/alternative;
 boundary="----=_Part_644_312787559.1451595316409"

------=_Part_644_312787559.1451595316409
Content-Type: text/plain; charset=UTF-8



On Thursday, December 31, 2015 at 3:46:29 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-31 14:23, T. C. wrote:
> > So, should
> >
> > int i;
> > decltype(auto) foo();
> > int foo() { return i; }
> >
> > compile?
>
> Under the current proposed wording, yes. In this case, 'decltype(auto)'
> is "just" a placeholder for "I haven't told you yet". In the definition,
> you are "resolving" the placeholder to definitely be "int".
>
> > Note that
> >
> > int i;
> > decltype(auto) foo()  { return i; }
> > int foo();
> >
> > presumably won't.
>
> Ah... it won't?
>
> I admit, I'm not familiar with the arcane details of decltype(auto) as a
> return type. However, [dcl.spec.auto]/7 gives the type of 'int i;
> decltype(auto) x = i' as 'int'. It's unclear why a return statement
> would have a different result?
>
> That's a tangent, however. I'll assume that your intent is for the
> 'decltype(auto)' in the above to be other than plain 'int', in which
> case the example would indeed not compile.
>

I typed that too fast. I meant to write return (i); in both, i.e., causing
decltype(auto) to deduce a int&.


>
> That said, note that there is a critical difference between the two
> examples. The first is merely deferring resolution of the return type.
> This seems okay, even if the deduced type would have been different. The
> second requests a deduced return type and then gives an incompatible
> declaration. This has never been okay (for non-templates, at least) and
> remains not-okay.
>
> Consider a different example:
>
>   auto foo();
>   long foo() { return 42; }
>
> If I had written 'auto' both times, the return type would be 'int'.
> Because I specified it, however, I have implicitly caused a cast to
> occur in the return statement. IOW, I have effectively written:
>
>   auto foo() { return long{42}; }
>
> The above can be considered similarly:
>
>   int& i = ...;
>   int foo() { return i; } // decltype(auto) foo() { return int{i}; }
>
> FWIW, if this all proves too controversial, I believe it is okay to drop
> this part of the proposal. Its main purpose is to address the possible
> need to partially declare a function before the return type is known,
> and so that there is symmetry with e.g.:
>
>   // "Main" proposal
>   int foo();
>   auto foo();
>
> ...and:
>
>   // Modification to [dcl.spec.auto]/13
>   auto foo();
>   int foo();
>
> ...because it seems likely to be confusing if the former works but the
> latter does not. However, that isn't strictly necessary to use the main
> (IRTVPDUA) feature; it just means that the first declaration *must* have
> a concrete type.
>

The first declaration already has special importance in other ways (e.g.,
=delete; must be in the first declaration).
This won't be the first.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_644_312787559.1451595316409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, December 31, 2015 at 3:46:29 PM UTC-5, Matthew Woehlke=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-31 14:23, T.=
 C. wrote:
<br>&gt; So, should
<br>&gt;=20
<br>&gt; int i;
<br>&gt; decltype(auto) foo();
<br>&gt; int foo() { return i; }
<br>&gt;=20
<br>&gt; compile?
<br>
<br>Under the current proposed wording, yes. In this case, &#39;decltype(au=
to)&#39;
<br>is &quot;just&quot; a placeholder for &quot;I haven&#39;t told you yet&=
quot;. In the definition,
<br>you are &quot;resolving&quot; the placeholder to definitely be &quot;in=
t&quot;.
<br>
<br>&gt; Note that=20
<br>&gt;=20
<br>&gt; int i;
<br>&gt; decltype(auto) foo() =C2=A0{ return i; }
<br>&gt; int foo();
<br>&gt;=20
<br>&gt; presumably won&#39;t.
<br>
<br>Ah... it won&#39;t?
<br>
<br>I admit, I&#39;m not familiar with the arcane details of decltype(auto)=
 as a
<br>return type. However, [dcl.spec.auto]/7 gives the type of &#39;int i;
<br>decltype(auto) x =3D i&#39; as &#39;int&#39;. It&#39;s unclear why a re=
turn statement
<br>would have a different result?
<br>
<br>That&#39;s a tangent, however. I&#39;ll assume that your intent is for =
the
<br>&#39;decltype(auto)&#39; in the above to be other than plain &#39;int&#=
39;, in which
<br>case the example would indeed not compile.
<br></blockquote><div><br></div><div>I typed that too fast. I meant to writ=
e=C2=A0<font face=3D"courier new, monospace">return (i);</font> in both, i.=
e., causing <font face=3D"courier new, monospace">decltype(auto)</font> to =
deduce a <font face=3D"courier new, monospace">int&amp;</font>.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>That said, note that there is a critical difference between the two
<br>examples. The first is merely deferring resolution of the return type.
<br>This seems okay, even if the deduced type would have been different. Th=
e
<br>second requests a deduced return type and then gives an incompatible
<br>declaration. This has never been okay (for non-templates, at least) and
<br>remains not-okay.
<br>
<br>Consider a different example:
<br>
<br>=C2=A0 auto foo();
<br>=C2=A0 long foo() { return 42; }
<br>
<br>If I had written &#39;auto&#39; both times, the return type would be &#=
39;int&#39;.
<br>Because I specified it, however, I have implicitly caused a cast to
<br>occur in the return statement. IOW, I have effectively written:
<br>
<br>=C2=A0 auto foo() { return long{42}; }
<br>
<br>The above can be considered similarly:
<br>
<br>=C2=A0 int&amp; i =3D ...;
<br>=C2=A0 int foo() { return i; } // decltype(auto) foo() { return int{i};=
 }
<br>
<br>FWIW, if this all proves too controversial, I believe it is okay to dro=
p
<br>this part of the proposal. Its main purpose is to address the possible
<br>need to partially declare a function before the return type is known,
<br>and so that there is symmetry with e.g.:
<br>
<br>=C2=A0 // &quot;Main&quot; proposal
<br>=C2=A0 int foo();
<br>=C2=A0 auto foo();
<br>
<br>...and:
<br>
<br>=C2=A0 // Modification to [dcl.spec.auto]/13
<br>=C2=A0 auto foo();
<br>=C2=A0 int foo();
<br>
<br>...because it seems likely to be confusing if the former works but the
<br>latter does not. However, that isn&#39;t strictly necessary to use the =
main
<br>(IRTVPDUA) feature; it just means that the first declaration *must* hav=
e
<br>a concrete type.
<br></blockquote><div><br></div><div>The first declaration already has spec=
ial importance in other ways (e.g., =3Ddelete; must be in the first declara=
tion).</div><div>This won&#39;t be the first.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_644_312787559.1451595316409--
------=_Part_643_1153540931.1451595316409--

.

------=_Part_65_1970873361.1451742446259
Content-Type: multipart/alternative;
 boundary="----=_Part_66_41693063.1451742446260"

------=_Part_66_41693063.1451742446260
Content-Type: text/plain; charset=UTF-8

I read the new proposal. The last section suggests to not require the
compiler to recognize that two equally declared anonymous struct types are
compatible. This made me think about overriding of functions. Two issues
arose:

- Should it be possible to override a function returning anonymous struct
by re-stating the struct definition in the subclass method declaration. If
so the compiler is burdened with checking the struct declaration for
consistency.

- Should it be possible to state the return type as 'auto' in the subclass
overriding declaration? This would save some typing for most return types.
On the other hand error messages may be more obscure or absent if the
baseclass return type is changed and the programmer forgets to change the
subclass implementation.

In general also: Has the proposal considered the possible interaction with
current use of auto return type (deduced from return statement in the
function body)? Well maybe these uses of auto are mutually exclusive: If
all declarations have auto return type we have the current scenario where
the implementation must be seen from all points where the function is
called, while in the new scenario there is always a fixed return type
somewhere so that the return type does not have to be deduced. The only
obscure case would be that the function is first defined with auto return
type and then later declared with a fixed type not compatible with the
deduction in the function body. Which one wins:

auto foo() { return 3.14; }   // Deduce to double
int foo();

I suggest that an auto-return declaration with an implementation causing
deduction to a particular type acts as if the type had been stated so this
would cause an error on the second declaration. With the rows in reverse
order the type would already been set to int at the point of definition so
the code would compile (with a possible warning for double->int conversion).

I don't really like this dependency on declaration order, which suggests
that maybe the rule that the first declaration seen must state the return
type explicitly if any declaration does is sound. As the first declaration
apparently has special meaning already that requirement is less unique than
I thought.

Den torsdag 31 december 2015 kl. 21:55:16 UTC+1 skrev T. C.:
>
>
>
> On Thursday, December 31, 2015 at 3:46:29 PM UTC-5, Matthew Woehlke wrote:
>>
>> On 2015-12-31 14:23, T. C. wrote:
>> > So, should
>> >
>> > int i;
>> > decltype(auto) foo();
>> > int foo() { return i; }
>> >
>> > compile?
>>
>> Under the current proposed wording, yes. In this case, 'decltype(auto)'
>> is "just" a placeholder for "I haven't told you yet". In the definition,
>> you are "resolving" the placeholder to definitely be "int".
>>
>> > Note that
>> >
>> > int i;
>> > decltype(auto) foo()  { return i; }
>> > int foo();
>> >
>> > presumably won't.
>>
>> Ah... it won't?
>>
>> I admit, I'm not familiar with the arcane details of decltype(auto) as a
>> return type. However, [dcl.spec.auto]/7 gives the type of 'int i;
>> decltype(auto) x = i' as 'int'. It's unclear why a return statement
>> would have a different result?
>>
>> That's a tangent, however. I'll assume that your intent is for the
>> 'decltype(auto)' in the above to be other than plain 'int', in which
>> case the example would indeed not compile.
>>
>
> I typed that too fast. I meant to write return (i); in both, i.e.,
> causing decltype(auto) to deduce a int&.
>
>
>>
>> That said, note that there is a critical difference between the two
>> examples. The first is merely deferring resolution of the return type.
>> This seems okay, even if the deduced type would have been different. The
>> second requests a deduced return type and then gives an incompatible
>> declaration. This has never been okay (for non-templates, at least) and
>> remains not-okay.
>>
>> Consider a different example:
>>
>>   auto foo();
>>   long foo() { return 42; }
>>
>> If I had written 'auto' both times, the return type would be 'int'.
>> Because I specified it, however, I have implicitly caused a cast to
>> occur in the return statement. IOW, I have effectively written:
>>
>>   auto foo() { return long{42}; }
>>
>> The above can be considered similarly:
>>
>>   int& i = ...;
>>   int foo() { return i; } // decltype(auto) foo() { return int{i}; }
>>
>> FWIW, if this all proves too controversial, I believe it is okay to drop
>> this part of the proposal. Its main purpose is to address the possible
>> need to partially declare a function before the return type is known,
>> and so that there is symmetry with e.g.:
>>
>>   // "Main" proposal
>>   int foo();
>>   auto foo();
>>
>> ...and:
>>
>>   // Modification to [dcl.spec.auto]/13
>>   auto foo();
>>   int foo();
>>
>> ...because it seems likely to be confusing if the former works but the
>> latter does not. However, that isn't strictly necessary to use the main
>> (IRTVPDUA) feature; it just means that the first declaration *must* have
>> a concrete type.
>>
>
> The first declaration already has special importance in other ways (e.g.,
> =delete; must be in the first declaration).
> This won't be the first.
>

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_66_41693063.1451742446260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I read the new proposal. The last section suggests to not =
require the compiler to recognize that two equally declared anonymous struc=
t types are compatible. This made me think about overriding of functions. T=
wo issues arose:<div><br></div><div>- Should it be possible to override a f=
unction returning anonymous struct by re-stating the struct definition in t=
he subclass method declaration. If so the compiler is burdened with checkin=
g the struct declaration for consistency.</div><div><br></div><div>- Should=
 it be possible to state the return type as &#39;auto&#39; in the subclass =
overriding declaration? This would save some typing for most return types. =
On the other hand error messages may be more obscure or absent if the basec=
lass return type is changed and the programmer forgets to change the subcla=
ss implementation.</div><div><br></div><div>In general also: Has the propos=
al considered the possible interaction with current use of auto return type=
 (deduced from return statement in the function body)? Well maybe these use=
s of auto are mutually exclusive: If all declarations have auto return type=
 we have the current scenario where the implementation must be seen from al=
l points where the function is called, while in the new scenario there is a=
lways a fixed return type somewhere so that the return type does not have t=
o be deduced. The only obscure case would be that the function is first def=
ined with auto return type and then later declared with a fixed type not co=
mpatible with the deduction in the function body. Which one wins:</div><div=
><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"=
#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><sp=
an 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=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">3.14</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: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Deduce to double</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span></font></div></code></div><b=
r>I suggest that an auto-return declaration with an implementation causing =
deduction to a particular type acts as if the type had been stated so this =
would cause an error on the second declaration. With the rows in reverse or=
der the type would already been set to int at the point of definition so th=
e code would compile (with a possible warning for double-&gt;int conversion=
).</div><div><br></div><div>I don&#39;t really like this dependency on decl=
aration order, which suggests that maybe the rule that the first declaratio=
n seen must state the return type explicitly if any declaration does is sou=
nd. As the first declaration apparently has special meaning already that re=
quirement is less unique than I thought.<br><br>Den torsdag 31 december 201=
5 kl. 21:55:16 UTC+1 skrev T. C.:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><br><br>On Thursday, December 31, 2015 at 3:46:29 PM UTC-5, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-12-31 14:23, T. C=
.. wrote:
<br>&gt; So, should
<br>&gt;=20
<br>&gt; int i;
<br>&gt; decltype(auto) foo();
<br>&gt; int foo() { return i; }
<br>&gt;=20
<br>&gt; compile?
<br>
<br>Under the current proposed wording, yes. In this case, &#39;decltype(au=
to)&#39;
<br>is &quot;just&quot; a placeholder for &quot;I haven&#39;t told you yet&=
quot;. In the definition,
<br>you are &quot;resolving&quot; the placeholder to definitely be &quot;in=
t&quot;.
<br>
<br>&gt; Note that=20
<br>&gt;=20
<br>&gt; int i;
<br>&gt; decltype(auto) foo() =C2=A0{ return i; }
<br>&gt; int foo();
<br>&gt;=20
<br>&gt; presumably won&#39;t.
<br>
<br>Ah... it won&#39;t?
<br>
<br>I admit, I&#39;m not familiar with the arcane details of decltype(auto)=
 as a
<br>return type. However, [dcl.spec.auto]/7 gives the type of &#39;int i;
<br>decltype(auto) x =3D i&#39; as &#39;int&#39;. It&#39;s unclear why a re=
turn statement
<br>would have a different result?
<br>
<br>That&#39;s a tangent, however. I&#39;ll assume that your intent is for =
the
<br>&#39;decltype(auto)&#39; in the above to be other than plain &#39;int&#=
39;, in which
<br>case the example would indeed not compile.
<br></blockquote><div><br></div><div>I typed that too fast. I meant to writ=
e=C2=A0<font face=3D"courier new, monospace">return (i);</font> in both, i.=
e., causing <font face=3D"courier new, monospace">decltype(auto)</font> to =
deduce a <font face=3D"courier new, monospace">int&amp;</font>.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>That said, note that there is a critical difference between the two
<br>examples. The first is merely deferring resolution of the return type.
<br>This seems okay, even if the deduced type would have been different. Th=
e
<br>second requests a deduced return type and then gives an incompatible
<br>declaration. This has never been okay (for non-templates, at least) and
<br>remains not-okay.
<br>
<br>Consider a different example:
<br>
<br>=C2=A0 auto foo();
<br>=C2=A0 long foo() { return 42; }
<br>
<br>If I had written &#39;auto&#39; both times, the return type would be &#=
39;int&#39;.
<br>Because I specified it, however, I have implicitly caused a cast to
<br>occur in the return statement. IOW, I have effectively written:
<br>
<br>=C2=A0 auto foo() { return long{42}; }
<br>
<br>The above can be considered similarly:
<br>
<br>=C2=A0 int&amp; i =3D ...;
<br>=C2=A0 int foo() { return i; } // decltype(auto) foo() { return int{i};=
 }
<br>
<br>FWIW, if this all proves too controversial, I believe it is okay to dro=
p
<br>this part of the proposal. Its main purpose is to address the possible
<br>need to partially declare a function before the return type is known,
<br>and so that there is symmetry with e.g.:
<br>
<br>=C2=A0 // &quot;Main&quot; proposal
<br>=C2=A0 int foo();
<br>=C2=A0 auto foo();
<br>
<br>...and:
<br>
<br>=C2=A0 // Modification to [dcl.spec.auto]/13
<br>=C2=A0 auto foo();
<br>=C2=A0 int foo();
<br>
<br>...because it seems likely to be confusing if the former works but the
<br>latter does not. However, that isn&#39;t strictly necessary to use the =
main
<br>(IRTVPDUA) feature; it just means that the first declaration *must* hav=
e
<br>a concrete type.
<br></blockquote><div><br></div><div>The first declaration already has spec=
ial importance in other ways (e.g., =3Ddelete; must be in the first declara=
tion).</div><div>This won&#39;t be the first.</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&quot; 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_66_41693063.1451742446260--
------=_Part_65_1970873361.1451742446259--

.

On 2016-01-02 08:47, Bengt Gustafsson wrote:
> I read the new proposal. The last section suggests to not require the
> compiler to recognize that two equally declared anonymous struct types are
> compatible. This made me think about overriding of functions. Two issues
> arose:
>
> - Should it be possible to override a function returning anonymous struct
> by re-stating the struct definition in the subclass method declaration. If
> so the compiler is burdened with checking the struct declaration for
> consistency.
>
> - Should it be possible to state the return type as 'auto' in the subclass
> overriding declaration? This would save some typing for most return types.
> On the other hand error messages may be more obscure or absent if the
> baseclass return type is changed and the programmer forgets to change the
> subclass implementation.

Ouch, that's a good point; thank you. I will add that an overloaded
method shall consider the method being overloaded for purposes of return
type inference.

I don't think error messages will be a problem. I'd expect an error to
be something like:

  'could not convert <initializer list> to 'anonymous struct {int, double}''

....or:

  'invalid conversion from 'A' to 'B'' (replace 'A' and 'B' with type names)

GCC already gives similar error messages depending on the context, and
clang "always" gives errors like the second. The only thing that would
need to change is to give the complete struct, since it has no name.
(Admittedly, it would be better if all compilers gave something like the
first error, but at least I'd expect already to know which initializer
is the problem, and what type was expected.)

> In general also: Has the proposal considered the possible interaction with
> current use of auto return type (deduced from return statement in the
> function body)? Well maybe these uses of auto are mutually exclusive:

Yes, I think so. IRTVPDUA only kicks in if there exists a previous
declaration with a concrete type. In such case, an override using type
deduction would be ill-formed.

> If all declarations have auto return type we have the current
> scenario where the implementation must be seen from all points where
> the function is called,

Right... and the return type is *deduced* (vs. *inferred*).

> while in the new scenario there is always a fixed return type
> somewhere so that the return type does not have to be deduced.

Right.

> The only obscure case would be that the function is first defined
> with auto return type and then later declared with a fixed type not
> compatible with the deduction in the function body. Which one wins:
>
> auto foo() { return 3.14; }   // Deduce to double
> int foo();

The first wins. Per the proposed standardese: "If the return type has
previously been deduced, a declaration using a concrete type shall use
the deduced type". The second declaration does not follow that (it uses
a type other than the deduced type, i.e. int != double) and so is
ill-formed exactly as it would be before the proposal.

> I don't really like this dependency on declaration order, which suggests
> that maybe the rule that the first declaration seen must state the return
> type explicitly if any declaration does is sound. As the first declaration
> apparently has special meaning already that requirement is less unique than
> I thought.

Okay. As your previous comments were the main reason I added that rule
in the first place :-), and because it also makes T.C. nervous, I will
probably remove it.

Thanks again.

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------050909090300080608090908
Content-Type: text/plain; charset=UTF-8

On 2015-12-30 15:54, Matthew Woehlke wrote:
> This came up in Vicente's recent thread on N4560. Since it seems like an
> obvious and good idea, and received some initial positive feedback, I
> wrote a quick paper.
>
> The short form is: A function definition whose return type is given as
> 'auto', which does not specify a trailing return type, and which was
> previously declared with a known return type, shall use the return type
> from the declaration.

I have "removed" the change to [dcl.spec.auto]/13 per discussion (it is
still explored in the discussion section, but is no longer part of the
actual proposal), and slightly strengthened the rationale for the main
(IRTVPDUA) part of the proposal. (I may yet add an additional example.)
I have also added wording to clarify this situation:

  template <class T> int foo();
  template <class T> auto foo();

....as recommended by T.C.

Bengt, T.C., if you have a chance to take another look, I would
appreciate if you can verify that your various comments have been addressed.

Thanks, all!

--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------050909090300080608090908
Content-Type: text/prs.fallenstein.rst;
 name="PXXXX Implicit Return Type.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.rst"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Implicit Return Type
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

:Document:  PXXXX (TBD)
:Date:      2015-12-31
:Author:    Matthew Woehlke (mwoehlke.floss@gmail.com)

=2E. raw:: html

  <style>
    html { color: black; background: white; }
    table.docinfo { margin: 2em 0; }
    .literal-block { background: #eee; border: 1px solid #ddd; padding: 0=
=2E5em; }
    .addition { color: #2c2; text-decoration: underline; }
    .removal { color: #e22; text-decoration: line-through; }
    .literal-block .literal-block { background: none; border: none; }
    .block-addition { background: #cfc; text-decoration: underline; }
  </style>

=2E. role:: add
    :class: addition

=2E. role:: del
    :class: removal

Abstract
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal recommends an enhancement to return type deduction to allow=
 the return type of a function definition to be inferred from a previous =
declaration of the same.

(Note: references made to the existing draft standard are made against N4=
567_.)

=2E. contents::


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

The concept of multiple return values is well known. At present, however,=
 C++ lacks a good mechanism for implementing the same. ``std::tuple`` is =
considered clunky by many and, critically, creates sub-optimal API by vir=
tue of the returned values being unnamed, forcing developers to rely on s=
upplemental documentation to explain their purpose. Aggregates represent =
an improvement, being self-documenting, but the need to provide external =
definitions of the same is awkward and, worse, pollutes their correspondi=
ng namespace with entities that may be single use. Proposals such as N456=
0_ present a complicated mechanism for providing tagged (self-documenting=
) tuple-like types, which may be necessary in some cases, but still repre=
sent a non-trivial amount of complexity that ideally should not be requir=
ed.

Proposals such as P0144_ (or its competitor P0151_) in particular would r=
epresent a significant step toward support of multiple return values as f=
irst class citizens. These proposals and other current directions show an=
 encouraging movement away from the traditional ``std::pair`` and ``std::=
tuple`` towards comparable concepts without requiring the explicit types.=
 (We expect, however, that these will remain useful for algorithms where =
the identity of the elements is unimportant, while it *is* important to b=
e able to name at least the outer, if not complete, type. In that respect=
, we hypothesize that we may in the future see the ability to construct a=
 ``std::tuple`` from any tuple-like.) On their own, however, these propos=
als risk exacerbating the problem that this proposal aims to address.

It has been suggested on multiple occasions that the optimal solution to =
the above issues is to return an anonymous ``struct``. This solves the pr=
oblems of clutter and self-documentation, but runs afoul of a much worse =
issue; because the ``struct`` is *anonymous*, it can be difficult to impo=
ssible to give its name a second time in order to separate the declaratio=
n and definition of the function that wishes to use it.

However, in C++, functions cannot be overloaded by their return value. Th=
is leads to an obvious question: **why is it necessary to repeat the retu=
rn value at all?**

Even in the case of return types that can be named, it may be that repeat=
ing the type name is excessively verbose or otherwise undesirable. Some m=
ight even call this a violation of the `Don't Repeat Yourself <https://en=
=2Ewikipedia.org/wiki/Don't_repeat_yourself>`_ principle, similar to some=
 of the issues that ``auto`` for variable declaration was introduced to s=
olve. (On the flip side, one could see the ability to elide the return ty=
pe as subject to many abuses, again in much the manner of ``auto``. Howev=
er, many language features can be abused; this should not prevent the add=
ition of a feature that would provide an important benefit when used corr=
ectly.)

We would be remiss not to note that this is already possible in simple ca=
ses using ``decltype`` and a sample invocation of the function. However, =
while this may be adequate in simple cases, it is nevertheless needlessly=
 verbose, and as the argument list grows longer, and/or gains arguments f=
or which providing a legal value is non-trivial, it can quickly become un=
wieldy and unfeasible.


Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

Recent changes to the language have progressively relaxed the requirement=
s for how return types are specified. We began with trailing return type =
specification, and have progressed to inferred return types in certain ca=
ses.

This proposal is to continue this direction by adding an additional use o=
f ``auto`` as a return specifier, meaning "use the return type seen when =
this function was previously declared". This provides an optimal solution=
 to the following problem:

=2E. code:: c++

  // foo.h
  struct { int id; double value; } foo();

How does one now provide an external definition for ``foo()``? We propose=
:

=2E. code:: c++

  // foo.cpp
  auto foo()
  {
    ...
    return { id, value };
  }

The use of ``auto`` as the return type specifier, with no trailing return=
 type, and for a function that has been previously declared with a known =
return type, shall instruct the compiler to define the function using the=
 return type from the previous declaration.

Note that this works for *any* type, not just anonymous ``struct``\ s. In=
 particular, it is equally usable for long and cumbersome template types,=
 or even simple types (see earlier comments regarding DRY).

Naturally, "previous declaration" here means a declaration having the sam=
e name and argument list. This, for example, would remain illegal:

=2E. code:: c++

  struct { int id; int value; } foo(int);
  struct { int id; float value; } foo(float);

  auto foo(double input) // does not match any previous declaration
  {
    ...
    return { id, result };
  }

Additionally, and for obvious reasons, we propose to remove the prohibiti=
on ([dcl.fct]/11) against defining types in return type specifications. W=
e additionally note that this prohibition is already not enforced by at l=
east one major compiler (MSVC). We further believe this prohibition to be=
 outdated; it made sense in C++98, but with recent changes such as the ad=
dition of ``decltype`` and the ability to omit the type name in a ``retur=
n`` statement returning an in-place constructed class, the reasons for th=
e prohibition have been greatly mitigated. This other part of this propos=
al would largely remove any remaining motivation for the prohibition.


Proposed Wording
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(Proposed changes are specified relative N4567_.)

Add a new section to [dcl.spec.auto] (7.1.6.4) as follows:

=2E. compound::
  :class: literal-block block-addition

  When a function is declared or defined using ``auto`` for the return ty=
pe, and a previous declaration or definition having a concrete return typ=
e exists, the return type shall be inferred to be the previously seen con=
crete type.
  [*Example:*

  .. parsed-literal::

    std::string f();
    auto f(); // OK, return type is std::string

  |--| *end example*]

Add a new section to [dcl.spec.auto] (7.1.6.4) as follows:

=2E. compound::
  :class: literal-block block-addition

  A template function redeclaration or specialization having a return typ=
e of ``auto`` shall match a previous declaration (or definition) if the f=
irst such declaration had a concrete return type. If the first such decla=
ration also had a return type of ``auto``, the declaration using return t=
ype deduction shall be matched instead.
  [*Example:*

  .. parsed-literal::

    template <typename T> T g(T t) { return t; } // #1
    template auto g(float); // matches #1

    template <typename T> auto g(T t) { return t; } // #2
    template <typename T> T g(T t) { return t; }
    template auto g(float); // matches #2

  |--| *end example*]

Change [dcl.fct]/11 (8.3.5.11) as follows:

=2E. compound::
  :class: literal-block

  Types shall not be defined in :del:`return or` parameter types.


Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

What about template return types?
---------------------------------

In C++14, the following code is legal and produces two distinct templates=
:

=2E. code:: c++

  template <class T> int foo();
  template <class T> auto foo();

This obviously conflicts with the proposed feature. After discussion on `=
`std-proposals``, it was decided that the proposed feature should take pr=
ecedence in this case. It should also be noted that it is unclear how, or=
 even if, the second function can be invoked according to the current rul=
es of the language. (To this end, it may be desirable to simply forbid th=
e opposite ordering. However, we feel that this would be better addressed=
 separately, perhaps even as a DR.)

Must the declaration providing the concrete type be the first declaration=
?
-------------------------------------------------------------------------=
-

This question was originally brought up by Bengt Gustafsson. Specifically=
, for the sake of symmetry, it seems initially desirable to allow:

=2E. code:: c++

  int foo(); // specified return type
  auto foo() { return 42; } // return type inferred from prior declaratio=
n

  auto bar(); // forward declaration, type not yet known
  int bar(); // specify the return type as 'int'
  auto bar() { return 0; } // return type inferred from prior declaration=


To that end, earlier drafts of the proposal included the following propos=
ed change to [dcl.spec.auto]/13 (7.1.6.4.13):

=2E. compound::
  :class: literal-block

  Redeclarations or specializations of a function or function template wi=
th a declared return type that uses a placeholder type shall :del:`also u=
se that placeholder` :add:`use either that placeholder or a compatible co=
ncrete type`, not a deduced type. :add:`If the return type has previously=
 been deduced, a declaration using a concrete type shall use the deduced =
type.`
  [*Example:*

  .. parsed-literal::

    auto f();
    auto f() { return 42; } // return type is int
    auto f(); // OK
    :del:`int f(); // error, cannot be overloaded with auto f()`
    :add:`int f(); // OK, deduced type is also int`
    decltype(auto) f(); // error, auto and decltype(auto) don't match

    :add:`auto f(int);`
    :add:`int f(int); // OK, return type of f(int) is now int`
    :add:`float f(int); // error, redeclared with different return type`

However, upon further discussion, reservations were expressed, and the ge=
neral consensus seems to be that it is okay for the first declaration to =
"set in stone" if the return type will be known (and possibly later infer=
red), or deduced. Accordingly, absent the above change:

=2E. code:: c++

  auto bar();
  int bar(); // error, violates [dcl.spec.auto]/13
  auto bar() { return 0; } // okay, but return type is deduced, not infer=
red

What about defining types in function pointer types?
----------------------------------------------------

An obvious consequence of relaxing [dcl.fct]/11 is the desire to permit f=
unction pointers which return an anonymous struct. For example:

=2E. code:: c++

  // Declare a function pointer type which returns an anonymous struct
  using ReturnsAnonymousStruct =3D struct { int result; } (*)();

  // Define a function using the same
  int bar(ReturnsAnonymousStruct f) { return ((*f)()).result; }

  // Provide a mechanism to obtain the return type of a function
  template <typename T> struct ReturnType;

  template <typename T, typename... Args>
  struct ReturnType<T (*)(Args...)>
  {
      using result_t =3D T;
  };

  // Declare a function that is a ReturnsAnonymousStruct
  ReturnType<ReturnsAnonymousStruct>::result_t foo() { return {0}; }

  // Use the function
  int main()
  {
      return bar(&foo);
  }

It is our opinion that the proposed changes are sufficient to allow the a=
bove. (In fact, this example is already accepted by both GCC and ICC (in =
C++11 mode even!), although it is rejected by clang per [dcl.fct]/11.) Ac=
cordingly, we feel that this proposal should be understood as intending t=
o allow the above example and that additional wording changes to specify =
this behavior are not required at this time.

What about defining types in parameter types?
---------------------------------------------

An obvious follow-on question is, should we also lift the prohibition aga=
inst types defined in parameter specifications? There have been suggestio=
ns floated to implement the much requested named parameters in something =
like this manner. However, there are significant (in our opinion) reasons=
 to not address this, at least initially. First, it is widely contested t=
hat this is not an optimal solution to the problem (named parameters) in =
the first place. Second, it depends on named initializers, which is an ar=
ea of ongoing work. Third, this proposal works largely because C++ forbid=
s overloading on return type, which may be leveraged to eliminate any amb=
iguity as to the deduction of the actual type of ``auto``; this is not th=
e case for parameters, and so permitting ``auto`` as a parameter type spe=
cifier would quickly run into issues that can be avoided for the return t=
ype case.

While we do not wish to categorically rule out future changes in this dir=
ection, we feel that it is not appropriate for this proposal to attempt t=
o address these issues.

On a related note, it is not strictly necessary for the sake of the added=
 utility of implied return type to relax [dcl.fct]/11. However, much of t=
he benefit is lost with this prohibition in place. Conversely, simply rel=
axing the prohibition is of significantly less benefit without the propos=
ed implied return type feature. Accordingly, while we considered splittin=
g the two changes into separate proposals, we have decided for now to kee=
p them together.

Another question that has come up is if something like this should be all=
owed:

=2E. code:: c++

  struct { int result; } foo() { ... }
  struct { int result; } bar()
  {
    return foo();
  }

Under the current rules (plus relaxed [dcl.fct]/11), these two definition=
s have different return types which are not convertible. It is our opinio=
n that the rules making these types different are in fact correct and des=
irable, and this proposal specifically does *not* include any changes whi=
ch would make the types compatible. We would, however, encourage a future=
 (orthogonal) proposal which would allow something like this:

=2E. code:: c++

  struct { int result; } bar()
  {
    // The '[*]' operator here causes the compiler to store the input as =
a
    // temporary and generate an expression list from the unpacked member=
s of
    // the same; it can be used anywhere an expression list is accepted
    return { [*]foo() };
  }

Conflicts with future "true" multiple return values?
----------------------------------------------------

There has been some discussion of "true" multiple return values, in parti=
cular with respect to RVO and similar issues. No doubt unpacking, if acce=
pted, will play a part. A point that bears consideration is if moving dow=
n the path of using anonymous (or not) structs for multiple return values=
 will "paint us into a corner" where future optimization potential is pre=
maturely eliminated.

It is our hope that these issues can be addressed with existing compound =
types (which will have further reaching benefit), and that it is accordin=
gly not necessary to hold back the features here proposed in the hope of =
something better coming along. As is often said, perfect is the enemy of =
good.


Future Directions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In the Discussion_ section above, we presented a utility for extracting t=
he return type from a function pointer type. The facility as presented ha=
s significant limitations; namely, it does not work on member functions a=
nd the several variations (e.g. CV-qualification) which apply to the same=
=2E We do not here propose a standard library implementation of this faci=
lity, which presumably would cover these cases, however there is room to =
imagine that such a facility could be useful, especially if the proposals=
 we present here are adopted. (David Krauss points out that ``std::refere=
nce_wrapper`` can be used to similar effect... on *some* compilers. Howev=
er, imperfect portability and the disparity between intended function and=
 use for this result suggest that this is not the optimal facility for th=
e problem.)

Another consideration that seems likely to come up is if we should furthe=
r simplify the syntax for returning multiple values (conceivably, this co=
uld apply to both anonymous structs and to ``std::pair`` / ``std::tuple``=
). Some have suggested allowing that the ``struct`` keyword may be omitte=
d. In light of P0151_, we can conceive that allowing the syntax ``<int x,=
 double y> foo()`` might be interesting. At this time, we prefer to focus=
 on the two features here presented rather than risk overextending the re=
ach of this proposal. However, if this proposal is accepted, it represent=
s an obvious first step to considering such features in the future.


Acknowledgments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We wish to thank everyone on the ``std-proposals`` forum, especially Beng=
t Gustafsson and Tim Song, for their valuable feedback and insights.

=2E. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..=
 .. ..

=2E. _N4560: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
0.pdf
=2E. _N4567: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
7.pdf
=2E. _P0144: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p014=
4r0.pdf
=2E. _P0151: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p015=
1r0.pdf

=2E. |--| unicode:: U+02014 .. em dash

--------------050909090300080608090908
Content-Type: text/html; charset=UTF-8;
 name="PXXXX Implicit Return Type.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="PXXXX Implicit Return Type.html"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiID8+CjwhRE9DVFlQRSBodG1s
IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRw
Oi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4K
PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJl
biIgbGFuZz0iZW4iPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+CjxtZXRhIG5hbWU9ImdlbmVy
YXRvciIgY29udGVudD0iRG9jdXRpbHMgMC4xMTogaHR0cDovL2RvY3V0aWxzLnNvdXJjZWZv
cmdlLm5ldC8iIC8+Cjx0aXRsZT5JbXBsaWNpdCBSZXR1cm4gVHlwZTwvdGl0bGU+CjxtZXRh
IG5hbWU9ImRhdGUiIGNvbnRlbnQ9IjIwMTUtMTItMzEiIC8+CjxtZXRhIG5hbWU9ImF1dGhv
ciIgY29udGVudD0iTWF0dGhldyBXb2VobGtlIChtd29laGxrZS5mbG9zcyYjNjQ7Z21haWwu
Y29tKSIgLz4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KCi8qCjpBdXRob3I6IERhdmlkIEdv
b2RnZXIgKGdvb2RnZXJAcHl0aG9uLm9yZykKOklkOiAkSWQ6IGh0bWw0Y3NzMS5jc3MgNzYx
NCAyMDEzLTAyLTIxIDE1OjU1OjUxWiBtaWxkZSAkCjpDb3B5cmlnaHQ6IFRoaXMgc3R5bGVz
aGVldCBoYXMgYmVlbiBwbGFjZWQgaW4gdGhlIHB1YmxpYyBkb21haW4uCgpEZWZhdWx0IGNh
c2NhZGluZyBzdHlsZSBzaGVldCBmb3IgdGhlIEhUTUwgb3V0cHV0IG9mIERvY3V0aWxzLgoK
U2VlIGh0dHA6Ly9kb2N1dGlscy5zZi5uZXQvZG9jcy9ob3d0by9odG1sLXN0eWxlc2hlZXRz
Lmh0bWwgZm9yIGhvdyB0bwpjdXN0b21pemUgdGhpcyBzdHlsZSBzaGVldC4KKi8KCi8qIHVz
ZWQgdG8gcmVtb3ZlIGJvcmRlcnMgZnJvbSB0YWJsZXMgYW5kIGltYWdlcyAqLwouYm9yZGVy
bGVzcywgdGFibGUuYm9yZGVybGVzcyB0ZCwgdGFibGUuYm9yZGVybGVzcyB0aCB7CiAgYm9y
ZGVyOiAwIH0KCnRhYmxlLmJvcmRlcmxlc3MgdGQsIHRhYmxlLmJvcmRlcmxlc3MgdGggewog
IC8qIE92ZXJyaWRlIHBhZGRpbmcgZm9yICJ0YWJsZS5kb2N1dGlscyB0ZCIgd2l0aCAiISBp
bXBvcnRhbnQiLgogICAgIFRoZSByaWdodCBwYWRkaW5nIHNlcGFyYXRlcyB0aGUgdGFibGUg
Y2VsbHMuICovCiAgcGFkZGluZzogMCAwLjVlbSAwIDAgISBpbXBvcnRhbnQgfQoKLmZpcnN0
IHsKICAvKiBPdmVycmlkZSBtb3JlIHNwZWNpZmljIG1hcmdpbiBzdHlsZXMgd2l0aCAiISBp
bXBvcnRhbnQiLiAqLwogIG1hcmdpbi10b3A6IDAgISBpbXBvcnRhbnQgfQoKLmxhc3QsIC53
aXRoLXN1YnRpdGxlIHsKICBtYXJnaW4tYm90dG9tOiAwICEgaW1wb3J0YW50IH0KCi5oaWRk
ZW4gewogIGRpc3BsYXk6IG5vbmUgfQoKYS50b2MtYmFja3JlZiB7CiAgdGV4dC1kZWNvcmF0
aW9uOiBub25lIDsKICBjb2xvcjogYmxhY2sgfQoKYmxvY2txdW90ZS5lcGlncmFwaCB7CiAg
bWFyZ2luOiAyZW0gNWVtIDsgfQoKZGwuZG9jdXRpbHMgZGQgewogIG1hcmdpbi1ib3R0b206
IDAuNWVtIH0KCm9iamVjdFt0eXBlPSJpbWFnZS9zdmcreG1sIl0sIG9iamVjdFt0eXBlPSJh
cHBsaWNhdGlvbi94LXNob2Nrd2F2ZS1mbGFzaCJdIHsKICBvdmVyZmxvdzogaGlkZGVuOwp9
CgovKiBVbmNvbW1lbnQgKGFuZCByZW1vdmUgdGhpcyB0ZXh0ISkgdG8gZ2V0IGJvbGQtZmFj
ZWQgZGVmaW5pdGlvbiBsaXN0IHRlcm1zCmRsLmRvY3V0aWxzIGR0IHsKICBmb250LXdlaWdo
dDogYm9sZCB9CiovCgpkaXYuYWJzdHJhY3QgewogIG1hcmdpbjogMmVtIDVlbSB9CgpkaXYu
YWJzdHJhY3QgcC50b3BpYy10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIHRleHQt
YWxpZ246IGNlbnRlciB9CgpkaXYuYWRtb25pdGlvbiwgZGl2LmF0dGVudGlvbiwgZGl2LmNh
dXRpb24sIGRpdi5kYW5nZXIsIGRpdi5lcnJvciwKZGl2LmhpbnQsIGRpdi5pbXBvcnRhbnQs
IGRpdi5ub3RlLCBkaXYudGlwLCBkaXYud2FybmluZyB7CiAgbWFyZ2luOiAyZW0gOwogIGJv
cmRlcjogbWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIH0KCmRpdi5hZG1vbml0aW9u
IHAuYWRtb25pdGlvbi10aXRsZSwgZGl2LmhpbnQgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYu
aW1wb3J0YW50IHAuYWRtb25pdGlvbi10aXRsZSwgZGl2Lm5vdGUgcC5hZG1vbml0aW9uLXRp
dGxlLApkaXYudGlwIHAuYWRtb25pdGlvbi10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQg
OwogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0KCmRpdi5hdHRlbnRpb24gcC5hZG1vbml0
aW9uLXRpdGxlLCBkaXYuY2F1dGlvbiBwLmFkbW9uaXRpb24tdGl0bGUsCmRpdi5kYW5nZXIg
cC5hZG1vbml0aW9uLXRpdGxlLCBkaXYuZXJyb3IgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYu
d2FybmluZyBwLmFkbW9uaXRpb24tdGl0bGUsIC5jb2RlIC5lcnJvciB7CiAgY29sb3I6IHJl
ZCA7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0K
Ci8qIFVuY29tbWVudCAoYW5kIHJlbW92ZSB0aGlzIHRleHQhKSB0byBnZXQgcmVkdWNlZCB2
ZXJ0aWNhbCBzcGFjZSBpbgogICBjb21wb3VuZCBwYXJhZ3JhcGhzLgpkaXYuY29tcG91bmQg
LmNvbXBvdW5kLWZpcnN0LCBkaXYuY29tcG91bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFy
Z2luLWJvdHRvbTogMC41ZW0gfQoKZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1sYXN0LCBkaXYu
Y29tcG91bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFyZ2luLXRvcDogMC41ZW0gfQoqLwoK
ZGl2LmRlZGljYXRpb24gewogIG1hcmdpbjogMmVtIDVlbSA7CiAgdGV4dC1hbGlnbjogY2Vu
dGVyIDsKICBmb250LXN0eWxlOiBpdGFsaWMgfQoKZGl2LmRlZGljYXRpb24gcC50b3BpYy10
aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc3R5bGU6IG5vcm1hbCB9Cgpk
aXYuZmlndXJlIHsKICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9
CgpkaXYuZm9vdGVyLCBkaXYuaGVhZGVyIHsKICBjbGVhcjogYm90aDsKICBmb250LXNpemU6
IHNtYWxsZXIgfQoKZGl2LmxpbmUtYmxvY2sgewogIGRpc3BsYXk6IGJsb2NrIDsKICBtYXJn
aW4tdG9wOiAxZW0gOwogIG1hcmdpbi1ib3R0b206IDFlbSB9CgpkaXYubGluZS1ibG9jayBk
aXYubGluZS1ibG9jayB7CiAgbWFyZ2luLXRvcDogMCA7CiAgbWFyZ2luLWJvdHRvbTogMCA7
CiAgbWFyZ2luLWxlZnQ6IDEuNWVtIH0KCmRpdi5zaWRlYmFyIHsKICBtYXJnaW46IDAgMCAw
LjVlbSAxZW0gOwogIGJvcmRlcjogbWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIDsK
ICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmVlIDsKICB3aWR0aDogNDAlIDsKICBmbG9hdDog
cmlnaHQgOwogIGNsZWFyOiByaWdodCB9CgpkaXYuc2lkZWJhciBwLnJ1YnJpYyB7CiAgZm9u
dC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtc2l6ZTogbWVkaXVtIH0KCmRpdi5zeXN0
ZW0tbWVzc2FnZXMgewogIG1hcmdpbjogNWVtIH0KCmRpdi5zeXN0ZW0tbWVzc2FnZXMgaDEg
ewogIGNvbG9yOiByZWQgfQoKZGl2LnN5c3RlbS1tZXNzYWdlIHsKICBib3JkZXI6IG1lZGl1
bSBvdXRzZXQgOwogIHBhZGRpbmc6IDFlbSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2UgcC5zeXN0
ZW0tbWVzc2FnZS10aXRsZSB7CiAgY29sb3I6IHJlZCA7CiAgZm9udC13ZWlnaHQ6IGJvbGQg
fQoKZGl2LnRvcGljIHsKICBtYXJnaW46IDJlbSB9CgpoMS5zZWN0aW9uLXN1YnRpdGxlLCBo
Mi5zZWN0aW9uLXN1YnRpdGxlLCBoMy5zZWN0aW9uLXN1YnRpdGxlLApoNC5zZWN0aW9uLXN1
YnRpdGxlLCBoNS5zZWN0aW9uLXN1YnRpdGxlLCBoNi5zZWN0aW9uLXN1YnRpdGxlIHsKICBt
YXJnaW4tdG9wOiAwLjRlbSB9CgpoMS50aXRsZSB7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0K
CmgyLnN1YnRpdGxlIHsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKaHIuZG9jdXRpbHMgewog
IHdpZHRoOiA3NSUgfQoKaW1nLmFsaWduLWxlZnQsIC5maWd1cmUuYWxpZ24tbGVmdCwgb2Jq
ZWN0LmFsaWduLWxlZnQgewogIGNsZWFyOiBsZWZ0IDsKICBmbG9hdDogbGVmdCA7CiAgbWFy
Z2luLXJpZ2h0OiAxZW0gfQoKaW1nLmFsaWduLXJpZ2h0LCAuZmlndXJlLmFsaWduLXJpZ2h0
LCBvYmplY3QuYWxpZ24tcmlnaHQgewogIGNsZWFyOiByaWdodCA7CiAgZmxvYXQ6IHJpZ2h0
IDsKICBtYXJnaW4tbGVmdDogMWVtIH0KCmltZy5hbGlnbi1jZW50ZXIsIC5maWd1cmUuYWxp
Z24tY2VudGVyLCBvYmplY3QuYWxpZ24tY2VudGVyIHsKICBkaXNwbGF5OiBibG9jazsKICBt
YXJnaW4tbGVmdDogYXV0bzsKICBtYXJnaW4tcmlnaHQ6IGF1dG87Cn0KCi5hbGlnbi1sZWZ0
IHsKICB0ZXh0LWFsaWduOiBsZWZ0IH0KCi5hbGlnbi1jZW50ZXIgewogIGNsZWFyOiBib3Ro
IDsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKLmFsaWduLXJpZ2h0IHsKICB0ZXh0LWFsaWdu
OiByaWdodCB9CgovKiByZXNldCBpbm5lciBhbGlnbm1lbnQgaW4gZmlndXJlcyAqLwpkaXYu
YWxpZ24tcmlnaHQgewogIHRleHQtYWxpZ246IGluaGVyaXQgfQoKLyogZGl2LmFsaWduLWNl
bnRlciAqIHsgKi8KLyogICB0ZXh0LWFsaWduOiBsZWZ0IH0gKi8KCm9sLnNpbXBsZSwgdWwu
c2ltcGxlIHsKICBtYXJnaW4tYm90dG9tOiAxZW0gfQoKb2wuYXJhYmljIHsKICBsaXN0LXN0
eWxlOiBkZWNpbWFsIH0KCm9sLmxvd2VyYWxwaGEgewogIGxpc3Qtc3R5bGU6IGxvd2VyLWFs
cGhhIH0KCm9sLnVwcGVyYWxwaGEgewogIGxpc3Qtc3R5bGU6IHVwcGVyLWFscGhhIH0KCm9s
Lmxvd2Vycm9tYW4gewogIGxpc3Qtc3R5bGU6IGxvd2VyLXJvbWFuIH0KCm9sLnVwcGVycm9t
YW4gewogIGxpc3Qtc3R5bGU6IHVwcGVyLXJvbWFuIH0KCnAuYXR0cmlidXRpb24gewogIHRl
eHQtYWxpZ246IHJpZ2h0IDsKICBtYXJnaW4tbGVmdDogNTAlIH0KCnAuY2FwdGlvbiB7CiAg
Zm9udC1zdHlsZTogaXRhbGljIH0KCnAuY3JlZGl0cyB7CiAgZm9udC1zdHlsZTogaXRhbGlj
IDsKICBmb250LXNpemU6IHNtYWxsZXIgfQoKcC5sYWJlbCB7CiAgd2hpdGUtc3BhY2U6IG5v
d3JhcCB9CgpwLnJ1YnJpYyB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc2l6ZTog
bGFyZ2VyIDsKICBjb2xvcjogbWFyb29uIDsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKcC5z
aWRlYmFyLXRpdGxlIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC13ZWln
aHQ6IGJvbGQgOwogIGZvbnQtc2l6ZTogbGFyZ2VyIH0KCnAuc2lkZWJhci1zdWJ0aXRsZSB7
CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnAu
dG9waWMtdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnByZS5hZGRyZXNzIHsKICBt
YXJnaW4tYm90dG9tOiAwIDsKICBtYXJnaW4tdG9wOiAwIDsKICBmb250OiBpbmhlcml0IH0K
CnByZS5saXRlcmFsLWJsb2NrLCBwcmUuZG9jdGVzdC1ibG9jaywgcHJlLm1hdGgsIHByZS5j
b2RlIHsKICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9CgpwcmUu
Y29kZSAubG4geyBjb2xvcjogZ3JleTsgfSAvKiBsaW5lIG51bWJlcnMgKi8KcHJlLmNvZGUs
IGNvZGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjZWVlZWVlIH0KcHJlLmNvZGUgLmNvbW1lbnQs
IGNvZGUgLmNvbW1lbnQgeyBjb2xvcjogIzVDNjU3NiB9CnByZS5jb2RlIC5rZXl3b3JkLCBj
b2RlIC5rZXl3b3JkIHsgY29sb3I6ICMzQjBEMDY7IGZvbnQtd2VpZ2h0OiBib2xkIH0KcHJl
LmNvZGUgLmxpdGVyYWwuc3RyaW5nLCBjb2RlIC5saXRlcmFsLnN0cmluZyB7IGNvbG9yOiAj
MEM1NDA0IH0KcHJlLmNvZGUgLm5hbWUuYnVpbHRpbiwgY29kZSAubmFtZS5idWlsdGluIHsg
Y29sb3I6ICMzNTJCODQgfQpwcmUuY29kZSAuZGVsZXRlZCwgY29kZSAuZGVsZXRlZCB7IGJh
Y2tncm91bmQtY29sb3I6ICNERUIwQTF9CnByZS5jb2RlIC5pbnNlcnRlZCwgY29kZSAuaW5z
ZXJ0ZWQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQTNEMjg5fQoKc3Bhbi5jbGFzc2lmaWVyIHsK
ICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC1zdHlsZTogb2JsaXF1ZSB9Cgpz
cGFuLmNsYXNzaWZpZXItZGVsaW1pdGVyIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7
CiAgZm9udC13ZWlnaHQ6IGJvbGQgfQoKc3Bhbi5pbnRlcnByZXRlZCB7CiAgZm9udC1mYW1p
bHk6IHNhbnMtc2VyaWYgfQoKc3Bhbi5vcHRpb24gewogIHdoaXRlLXNwYWNlOiBub3dyYXAg
fQoKc3Bhbi5wcmUgewogIHdoaXRlLXNwYWNlOiBwcmUgfQoKc3Bhbi5wcm9ibGVtYXRpYyB7
CiAgY29sb3I6IHJlZCB9CgpzcGFuLnNlY3Rpb24tc3VidGl0bGUgewogIC8qIGZvbnQtc2l6
ZSByZWxhdGl2ZSB0byBwYXJlbnQgKGgxLi5oNiBlbGVtZW50KSAqLwogIGZvbnQtc2l6ZTog
ODAlIH0KCnRhYmxlLmNpdGF0aW9uIHsKICBib3JkZXItbGVmdDogc29saWQgMXB4IGdyYXk7
CiAgbWFyZ2luLWxlZnQ6IDFweCB9Cgp0YWJsZS5kb2NpbmZvIHsKICBtYXJnaW46IDJlbSA0
ZW0gfQoKdGFibGUuZG9jdXRpbHMgewogIG1hcmdpbi10b3A6IDAuNWVtIDsKICBtYXJnaW4t
Ym90dG9tOiAwLjVlbSB9Cgp0YWJsZS5mb290bm90ZSB7CiAgYm9yZGVyLWxlZnQ6IHNvbGlk
IDFweCBibGFjazsKICBtYXJnaW4tbGVmdDogMXB4IH0KCnRhYmxlLmRvY3V0aWxzIHRkLCB0
YWJsZS5kb2N1dGlscyB0aCwKdGFibGUuZG9jaW5mbyB0ZCwgdGFibGUuZG9jaW5mbyB0aCB7
CiAgcGFkZGluZy1sZWZ0OiAwLjVlbSA7CiAgcGFkZGluZy1yaWdodDogMC41ZW0gOwogIHZl
cnRpY2FsLWFsaWduOiB0b3AgfQoKdGFibGUuZG9jdXRpbHMgdGguZmllbGQtbmFtZSwgdGFi
bGUuZG9jaW5mbyB0aC5kb2NpbmZvLW5hbWUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICB0
ZXh0LWFsaWduOiBsZWZ0IDsKICB3aGl0ZS1zcGFjZTogbm93cmFwIDsKICBwYWRkaW5nLWxl
ZnQ6IDAgfQoKLyogImJvb2t0YWJzIiBzdHlsZSAobm8gdmVydGljYWwgbGluZXMpICovCnRh
YmxlLmRvY3V0aWxzLmJvb2t0YWJzIHsKICBib3JkZXI6IDBweDsKICBib3JkZXItdG9wOiAy
cHggc29saWQ7CiAgYm9yZGVyLWJvdHRvbTogMnB4IHNvbGlkOwogIGJvcmRlci1jb2xsYXBz
ZTogY29sbGFwc2U7Cn0KdGFibGUuZG9jdXRpbHMuYm9va3RhYnMgKiB7CiAgYm9yZGVyOiAw
cHg7Cn0KdGFibGUuZG9jdXRpbHMuYm9va3RhYnMgdGggewogIGJvcmRlci1ib3R0b206IHRo
aW4gc29saWQ7CiAgdGV4dC1hbGlnbjogbGVmdDsKfQoKaDEgdHQuZG9jdXRpbHMsIGgyIHR0
LmRvY3V0aWxzLCBoMyB0dC5kb2N1dGlscywKaDQgdHQuZG9jdXRpbHMsIGg1IHR0LmRvY3V0
aWxzLCBoNiB0dC5kb2N1dGlscyB7CiAgZm9udC1zaXplOiAxMDAlIH0KCnVsLmF1dG8tdG9j
IHsKICBsaXN0LXN0eWxlLXR5cGU6IG5vbmUgfQoKPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4K
PGRpdiBjbGFzcz0iZG9jdW1lbnQiIGlkPSJpbXBsaWNpdC1yZXR1cm4tdHlwZSI+CjxoMSBj
bGFzcz0idGl0bGUiPkltcGxpY2l0IFJldHVybiBUeXBlPC9oMT4KPHRhYmxlIGNsYXNzPSJk
b2NpbmZvIiBmcmFtZT0idm9pZCIgcnVsZXM9Im5vbmUiPgo8Y29sIGNsYXNzPSJkb2NpbmZv
LW5hbWUiIC8+Cjxjb2wgY2xhc3M9ImRvY2luZm8tY29udGVudCIgLz4KPHRib2R5IHZhbGln
bj0idG9wIj4KPHRyIGNsYXNzPSJmaWVsZCI+PHRoIGNsYXNzPSJkb2NpbmZvLW5hbWUiPkRv
Y3VtZW50OjwvdGg+PHRkIGNsYXNzPSJmaWVsZC1ib2R5Ij5QWFhYWCAoVEJEKTwvdGQ+Cjwv
dHI+Cjx0cj48dGggY2xhc3M9ImRvY2luZm8tbmFtZSI+RGF0ZTo8L3RoPgo8dGQ+MjAxNS0x
Mi0zMTwvdGQ+PC90cj4KPHRyPjx0aCBjbGFzcz0iZG9jaW5mby1uYW1lIj5BdXRob3I6PC90
aD4KPHRkPk1hdHRoZXcgV29laGxrZSAoPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIg
aHJlZj0ibWFpbHRvOm13b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5jb20iPm13b2VobGtlLmZs
b3NzJiM2NDtnbWFpbC5jb208L2E+KTwvdGQ+PC90cj4KPC90Ym9keT4KPC90YWJsZT4KPHN0
eWxlPgogIGh0bWwgeyBjb2xvcjogYmxhY2s7IGJhY2tncm91bmQ6IHdoaXRlOyB9CiAgdGFi
bGUuZG9jaW5mbyB7IG1hcmdpbjogMmVtIDA7IH0KICAubGl0ZXJhbC1ibG9jayB7IGJhY2tn
cm91bmQ6ICNlZWU7IGJvcmRlcjogMXB4IHNvbGlkICNkZGQ7IHBhZGRpbmc6IDAuNWVtOyB9
CiAgLmFkZGl0aW9uIHsgY29sb3I6ICMyYzI7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l
OyB9CiAgLnJlbW92YWwgeyBjb2xvcjogI2UyMjsgdGV4dC1kZWNvcmF0aW9uOiBsaW5lLXRo
cm91Z2g7IH0KICAubGl0ZXJhbC1ibG9jayAubGl0ZXJhbC1ibG9jayB7IGJhY2tncm91bmQ6
IG5vbmU7IGJvcmRlcjogbm9uZTsgfQogIC5ibG9jay1hZGRpdGlvbiB7IGJhY2tncm91bmQ6
ICNjZmM7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyB9Cjwvc3R5bGU+PGRpdiBjbGFz
cz0ic2VjdGlvbiIgaWQ9ImFic3RyYWN0Ij4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIg
aHJlZj0iI2lkMSI+QWJzdHJhY3Q8L2E+PC9oMT4KPHA+VGhpcyBwcm9wb3NhbCByZWNvbW1l
bmRzIGFuIGVuaGFuY2VtZW50IHRvIHJldHVybiB0eXBlIGRlZHVjdGlvbiB0byBhbGxvdyB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBmdW5jdGlvbiBkZWZpbml0aW9uIHRvIGJlIGluZmVycmVk
IGZyb20gYSBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiB0aGUgc2FtZS48L3A+CjxwPihOb3Rl
OiByZWZlcmVuY2VzIG1hZGUgdG8gdGhlIGV4aXN0aW5nIGRyYWZ0IHN0YW5kYXJkIGFyZSBt
YWRlIGFnYWluc3QgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDov
L3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2
Ny5wZGYiPk40NTY3PC9hPi4pPC9wPgo8ZGl2IGNsYXNzPSJjb250ZW50cyB0b3BpYyIgaWQ9
ImNvbnRlbnRzIj4KPHAgY2xhc3M9InRvcGljLXRpdGxlIGZpcnN0Ij5Db250ZW50czwvcD4K
PHVsIGNsYXNzPSJzaW1wbGUiPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIg
aHJlZj0iI2Fic3RyYWN0IiBpZD0iaWQxIj5BYnN0cmFjdDwvYT48L2xpPgo8bGk+PGEgY2xh
c3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3JhdGlvbmFsZSIgaWQ9ImlkMiI+UmF0
aW9uYWxlPC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVm
PSIjcHJvcG9zYWwiIGlkPSJpZDMiPlByb3Bvc2FsPC9hPjwvbGk+CjxsaT48YSBjbGFzcz0i
cmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjcHJvcG9zZWQtd29yZGluZyIgaWQ9ImlkNCI+
UHJvcG9zZWQgV29yZGluZzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRl
cm5hbCIgaHJlZj0iI2Rpc2N1c3Npb24iIGlkPSJpZDUiPkRpc2N1c3Npb248L2E+PHVsPgo8
bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3doYXQtYWJvdXQtdGVt
cGxhdGUtcmV0dXJuLXR5cGVzIiBpZD0iaWQ2Ij5XaGF0IGFib3V0IHRlbXBsYXRlIHJldHVy
biB0eXBlcz88L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhy
ZWY9IiNtdXN0LXRoZS1kZWNsYXJhdGlvbi1wcm92aWRpbmctdGhlLWNvbmNyZXRlLXR5cGUt
YmUtdGhlLWZpcnN0LWRlY2xhcmF0aW9uIiBpZD0iaWQ3Ij5NdXN0IHRoZSBkZWNsYXJhdGlv
biBwcm92aWRpbmcgdGhlIGNvbmNyZXRlIHR5cGUgYmUgdGhlIGZpcnN0IGRlY2xhcmF0aW9u
PzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3do
YXQtYWJvdXQtZGVmaW5pbmctdHlwZXMtaW4tZnVuY3Rpb24tcG9pbnRlci10eXBlcyIgaWQ9
ImlkOCI+V2hhdCBhYm91dCBkZWZpbmluZyB0eXBlcyBpbiBmdW5jdGlvbiBwb2ludGVyIHR5
cGVzPzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0i
I3doYXQtYWJvdXQtZGVmaW5pbmctdHlwZXMtaW4tcGFyYW1ldGVyLXR5cGVzIiBpZD0iaWQ5
Ij5XaGF0IGFib3V0IGRlZmluaW5nIHR5cGVzIGluIHBhcmFtZXRlciB0eXBlcz88L2E+PC9s
aT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNjb25mbGljdHMt
d2l0aC1mdXR1cmUtdHJ1ZS1tdWx0aXBsZS1yZXR1cm4tdmFsdWVzIiBpZD0iaWQxMCI+Q29u
ZmxpY3RzIHdpdGggZnV0dXJlICZxdW90O3RydWUmcXVvdDsgbXVsdGlwbGUgcmV0dXJuIHZh
bHVlcz88L2E+PC9saT4KPC91bD4KPC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50
ZXJuYWwiIGhyZWY9IiNmdXR1cmUtZGlyZWN0aW9ucyIgaWQ9ImlkMTEiPkZ1dHVyZSBEaXJl
Y3Rpb25zPC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVm
PSIjYWNrbm93bGVkZ21lbnRzIiBpZD0iaWQxMiI+QWNrbm93bGVkZ21lbnRzPC9hPjwvbGk+
CjwvdWw+CjwvZGl2Pgo8L2Rpdj4KPGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9InJhdGlvbmFs
ZSI+CjxoMT48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDIiPlJhdGlvbmFsZTwv
YT48L2gxPgo8cD5UaGUgY29uY2VwdCBvZiBtdWx0aXBsZSByZXR1cm4gdmFsdWVzIGlzIHdl
bGwga25vd24uIEF0IHByZXNlbnQsIGhvd2V2ZXIsIEMrKyBsYWNrcyBhIGdvb2QgbWVjaGFu
aXNtIGZvciBpbXBsZW1lbnRpbmcgdGhlIHNhbWUuIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0
ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjp0dXBsZTwvc3Bhbj48L3R0PiBpcyBjb25z
aWRlcmVkIGNsdW5reSBieSBtYW55IGFuZCwgY3JpdGljYWxseSwgY3JlYXRlcyBzdWItb3B0
aW1hbCBBUEkgYnkgdmlydHVlIG9mIHRoZSByZXR1cm5lZCB2YWx1ZXMgYmVpbmcgdW5uYW1l
ZCwgZm9yY2luZyBkZXZlbG9wZXJzIHRvIHJlbHkgb24gc3VwcGxlbWVudGFsIGRvY3VtZW50
YXRpb24gdG8gZXhwbGFpbiB0aGVpciBwdXJwb3NlLiBBZ2dyZWdhdGVzIHJlcHJlc2VudCBh
biBpbXByb3ZlbWVudCwgYmVpbmcgc2VsZi1kb2N1bWVudGluZywgYnV0IHRoZSBuZWVkIHRv
IHByb3ZpZGUgZXh0ZXJuYWwgZGVmaW5pdGlvbnMgb2YgdGhlIHNhbWUgaXMgYXdrd2FyZCBh
bmQsIHdvcnNlLCBwb2xsdXRlcyB0aGVpciBjb3JyZXNwb25kaW5nIG5hbWVzcGFjZSB3aXRo
IGVudGl0aWVzIHRoYXQgbWF5IGJlIHNpbmdsZSB1c2UuIFByb3Bvc2FscyBzdWNoIGFzIDxh
IGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQu
b3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvbjQ1NjAucGRmIj5ONDU2MDwv
YT4gcHJlc2VudCBhIGNvbXBsaWNhdGVkIG1lY2hhbmlzbSBmb3IgcHJvdmlkaW5nIHRhZ2dl
ZCAoc2VsZi1kb2N1bWVudGluZykgdHVwbGUtbGlrZSB0eXBlcywgd2hpY2ggbWF5IGJlIG5l
Y2Vzc2FyeSBpbiBzb21lIGNhc2VzLCBidXQgc3RpbGwgcmVwcmVzZW50IGEgbm9uLXRyaXZp
YWwgYW1vdW50IG9mIGNvbXBsZXhpdHkgdGhhdCBpZGVhbGx5IHNob3VsZCBub3QgYmUgcmVx
dWlyZWQuPC9wPgo8cD5Qcm9wb3NhbHMgc3VjaCBhcyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4
dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9k
b2NzL3BhcGVycy8yMDE1L3AwMTQ0cjAucGRmIj5QMDE0NDwvYT4gKG9yIGl0cyBjb21wZXRp
dG9yIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93d3cub3Bl
bi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvcDAxNTFyMC5wZGYi
PlAwMTUxPC9hPikgaW4gcGFydGljdWxhciB3b3VsZCByZXByZXNlbnQgYSBzaWduaWZpY2Fu
dCBzdGVwIHRvd2FyZCBzdXBwb3J0IG9mIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgYXMgZmly
c3QgY2xhc3MgY2l0aXplbnMuIFRoZXNlIHByb3Bvc2FscyBhbmQgb3RoZXIgY3VycmVudCBk
aXJlY3Rpb25zIHNob3cgYW4gZW5jb3VyYWdpbmcgbW92ZW1lbnQgYXdheSBmcm9tIHRoZSB0
cmFkaXRpb25hbCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJw
cmUiPnN0ZDo6cGFpcjwvc3Bhbj48L3R0PiBhbmQgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRl
cmFsIj48c3BhbiBjbGFzcz0icHJlIj5zdGQ6OnR1cGxlPC9zcGFuPjwvdHQ+IHRvd2FyZHMg
Y29tcGFyYWJsZSBjb25jZXB0cyB3aXRob3V0IHJlcXVpcmluZyB0aGUgZXhwbGljaXQgdHlw
ZXMuIChXZSBleHBlY3QsIGhvd2V2ZXIsIHRoYXQgdGhlc2Ugd2lsbCByZW1haW4gdXNlZnVs
IGZvciBhbGdvcml0aG1zIHdoZXJlIHRoZSBpZGVudGl0eSBvZiB0aGUgZWxlbWVudHMgaXMg
dW5pbXBvcnRhbnQsIHdoaWxlIGl0IDxlbT5pczwvZW0+IGltcG9ydGFudCB0byBiZSBhYmxl
IHRvIG5hbWUgYXQgbGVhc3QgdGhlIG91dGVyLCBpZiBub3QgY29tcGxldGUsIHR5cGUuIElu
IHRoYXQgcmVzcGVjdCwgd2UgaHlwb3RoZXNpemUgdGhhdCB3ZSBtYXkgaW4gdGhlIGZ1dHVy
ZSBzZWUgdGhlIGFiaWxpdHkgdG8gY29uc3RydWN0IGEgPHR0IGNsYXNzPSJkb2N1dGlscyBs
aXRlcmFsIj48c3BhbiBjbGFzcz0icHJlIj5zdGQ6OnR1cGxlPC9zcGFuPjwvdHQ+IGZyb20g
YW55IHR1cGxlLWxpa2UuKSBPbiB0aGVpciBvd24sIGhvd2V2ZXIsIHRoZXNlIHByb3Bvc2Fs
cyByaXNrIGV4YWNlcmJhdGluZyB0aGUgcHJvYmxlbSB0aGF0IHRoaXMgcHJvcG9zYWwgYWlt
cyB0byBhZGRyZXNzLjwvcD4KPHA+SXQgaGFzIGJlZW4gc3VnZ2VzdGVkIG9uIG11bHRpcGxl
IG9jY2FzaW9ucyB0aGF0IHRoZSBvcHRpbWFsIHNvbHV0aW9uIHRvIHRoZSBhYm92ZSBpc3N1
ZXMgaXMgdG8gcmV0dXJuIGFuIGFub255bW91cyA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVy
YWwiPnN0cnVjdDwvdHQ+LiBUaGlzIHNvbHZlcyB0aGUgcHJvYmxlbXMgb2YgY2x1dHRlciBh
bmQgc2VsZi1kb2N1bWVudGF0aW9uLCBidXQgcnVucyBhZm91bCBvZiBhIG11Y2ggd29yc2Ug
aXNzdWU7IGJlY2F1c2UgdGhlIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+c3RydWN0
PC90dD4gaXMgPGVtPmFub255bW91czwvZW0+LCBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIGlt
cG9zc2libGUgdG8gZ2l2ZSBpdHMgbmFtZSBhIHNlY29uZCB0aW1lIGluIG9yZGVyIHRvIHNl
cGFyYXRlIHRoZSBkZWNsYXJhdGlvbiBhbmQgZGVmaW5pdGlvbiBvZiB0aGUgZnVuY3Rpb24g
dGhhdCB3aXNoZXMgdG8gdXNlIGl0LjwvcD4KPHA+SG93ZXZlciwgaW4gQysrLCBmdW5jdGlv
bnMgY2Fubm90IGJlIG92ZXJsb2FkZWQgYnkgdGhlaXIgcmV0dXJuIHZhbHVlLiBUaGlzIGxl
YWRzIHRvIGFuIG9idmlvdXMgcXVlc3Rpb246IDxzdHJvbmc+d2h5IGlzIGl0IG5lY2Vzc2Fy
eSB0byByZXBlYXQgdGhlIHJldHVybiB2YWx1ZSBhdCBhbGw/PC9zdHJvbmc+PC9wPgo8cD5F
dmVuIGluIHRoZSBjYXNlIG9mIHJldHVybiB0eXBlcyB0aGF0IGNhbiBiZSBuYW1lZCwgaXQg
bWF5IGJlIHRoYXQgcmVwZWF0aW5nIHRoZSB0eXBlIG5hbWUgaXMgZXhjZXNzaXZlbHkgdmVy
Ym9zZSBvciBvdGhlcndpc2UgdW5kZXNpcmFibGUuIFNvbWUgbWlnaHQgZXZlbiBjYWxsIHRo
aXMgYSB2aW9sYXRpb24gb2YgdGhlIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhy
ZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Rvbid0X3JlcGVhdF95b3Vyc2Vs
ZiI+RG9uJ3QgUmVwZWF0IFlvdXJzZWxmPC9hPiBwcmluY2lwbGUsIHNpbWlsYXIgdG8gc29t
ZSBvZiB0aGUgaXNzdWVzIHRoYXQgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRv
PC90dD4gZm9yIHZhcmlhYmxlIGRlY2xhcmF0aW9uIHdhcyBpbnRyb2R1Y2VkIHRvIHNvbHZl
LiAoT24gdGhlIGZsaXAgc2lkZSwgb25lIGNvdWxkIHNlZSB0aGUgYWJpbGl0eSB0byBlbGlk
ZSB0aGUgcmV0dXJuIHR5cGUgYXMgc3ViamVjdCB0byBtYW55IGFidXNlcywgYWdhaW4gaW4g
bXVjaCB0aGUgbWFubmVyIG9mIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwv
dHQ+LiBIb3dldmVyLCBtYW55IGxhbmd1YWdlIGZlYXR1cmVzIGNhbiBiZSBhYnVzZWQ7IHRo
aXMgc2hvdWxkIG5vdCBwcmV2ZW50IHRoZSBhZGRpdGlvbiBvZiBhIGZlYXR1cmUgdGhhdCB3
b3VsZCBwcm92aWRlIGFuIGltcG9ydGFudCBiZW5lZml0IHdoZW4gdXNlZCBjb3JyZWN0bHku
KTwvcD4KPHA+V2Ugd291bGQgYmUgcmVtaXNzIG5vdCB0byBub3RlIHRoYXQgdGhpcyBpcyBh
bHJlYWR5IHBvc3NpYmxlIGluIHNpbXBsZSBjYXNlcyB1c2luZyA8dHQgY2xhc3M9ImRvY3V0
aWxzIGxpdGVyYWwiPmRlY2x0eXBlPC90dD4gYW5kIGEgc2FtcGxlIGludm9jYXRpb24gb2Yg
dGhlIGZ1bmN0aW9uLiBIb3dldmVyLCB3aGlsZSB0aGlzIG1heSBiZSBhZGVxdWF0ZSBpbiBz
aW1wbGUgY2FzZXMsIGl0IGlzIG5ldmVydGhlbGVzcyBuZWVkbGVzc2x5IHZlcmJvc2UsIGFu
ZCBhcyB0aGUgYXJndW1lbnQgbGlzdCBncm93cyBsb25nZXIsIGFuZC9vciBnYWlucyBhcmd1
bWVudHMgZm9yIHdoaWNoIHByb3ZpZGluZyBhIGxlZ2FsIHZhbHVlIGlzIG5vbi10cml2aWFs
LCBpdCBjYW4gcXVpY2tseSBiZWNvbWUgdW53aWVsZHkgYW5kIHVuZmVhc2libGUuPC9wPgo8
L2Rpdj4KPGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9InByb3Bvc2FsIj4KPGgxPjxhIGNsYXNz
PSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkMyI+UHJvcG9zYWw8L2E+PC9oMT4KPHA+UmVjZW50
IGNoYW5nZXMgdG8gdGhlIGxhbmd1YWdlIGhhdmUgcHJvZ3Jlc3NpdmVseSByZWxheGVkIHRo
ZSByZXF1aXJlbWVudHMgZm9yIGhvdyByZXR1cm4gdHlwZXMgYXJlIHNwZWNpZmllZC4gV2Ug
YmVnYW4gd2l0aCB0cmFpbGluZyByZXR1cm4gdHlwZSBzcGVjaWZpY2F0aW9uLCBhbmQgaGF2
ZSBwcm9ncmVzc2VkIHRvIGluZmVycmVkIHJldHVybiB0eXBlcyBpbiBjZXJ0YWluIGNhc2Vz
LjwvcD4KPHA+VGhpcyBwcm9wb3NhbCBpcyB0byBjb250aW51ZSB0aGlzIGRpcmVjdGlvbiBi
eSBhZGRpbmcgYW4gYWRkaXRpb25hbCB1c2Ugb2YgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRl
cmFsIj5hdXRvPC90dD4gYXMgYSByZXR1cm4gc3BlY2lmaWVyLCBtZWFuaW5nICZxdW90O3Vz
ZSB0aGUgcmV0dXJuIHR5cGUgc2VlbiB3aGVuIHRoaXMgZnVuY3Rpb24gd2FzIHByZXZpb3Vz
bHkgZGVjbGFyZWQmcXVvdDsuIFRoaXMgcHJvdmlkZXMgYW4gb3B0aW1hbCBzb2x1dGlvbiB0
byB0aGUgZm9sbG93aW5nIHByb2JsZW06PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRl
cmFsLWJsb2NrIj4KPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBmb28uaAo8L3Nw
YW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im5hbWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBj
bGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk7PC9z
cGFuPgo8L3ByZT4KPHA+SG93IGRvZXMgb25lIG5vdyBwcm92aWRlIGFuIGV4dGVybmFsIGRl
ZmluaXRpb24gZm9yIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+Zm9vKCk8L3R0Pj8g
V2UgcHJvcG9zZTo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwtYmxvY2siPgo8
c3BhbiBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIGZvby5jcHAKPC9zcGFuPjxzcGFuIGNs
YXNzPSJrZXl3b3JkIj5hdXRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+
Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+CjxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pi4uLjwvc3Bhbj4KICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5pZDwv
c3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNsYXNzPSJu
YW1lIj52YWx1ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59Ozwvc3Bhbj4K
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+VGhlIHVzZSBv
ZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88L3R0PiBhcyB0aGUgcmV0dXJu
IHR5cGUgc3BlY2lmaWVyLCB3aXRoIG5vIHRyYWlsaW5nIHJldHVybiB0eXBlLCBhbmQgZm9y
IGEgZnVuY3Rpb24gdGhhdCBoYXMgYmVlbiBwcmV2aW91c2x5IGRlY2xhcmVkIHdpdGggYSBr
bm93biByZXR1cm4gdHlwZSwgc2hhbGwgaW5zdHJ1Y3QgdGhlIGNvbXBpbGVyIHRvIGRlZmlu
ZSB0aGUgZnVuY3Rpb24gdXNpbmcgdGhlIHJldHVybiB0eXBlIGZyb20gdGhlIHByZXZpb3Vz
IGRlY2xhcmF0aW9uLjwvcD4KPHA+Tm90ZSB0aGF0IHRoaXMgd29ya3MgZm9yIDxlbT5hbnk8
L2VtPiB0eXBlLCBub3QganVzdCBhbm9ueW1vdXMgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRl
cmFsIj5zdHJ1Y3Q8L3R0PnMuIEluIHBhcnRpY3VsYXIsIGl0IGlzIGVxdWFsbHkgdXNhYmxl
IGZvciBsb25nIGFuZCBjdW1iZXJzb21lIHRlbXBsYXRlIHR5cGVzLCBvciBldmVuIHNpbXBs
ZSB0eXBlcyAoc2VlIGVhcmxpZXIgY29tbWVudHMgcmVnYXJkaW5nIERSWSkuPC9wPgo8cD5O
YXR1cmFsbHksICZxdW90O3ByZXZpb3VzIGRlY2xhcmF0aW9uJnF1b3Q7IGhlcmUgbWVhbnMg
YSBkZWNsYXJhdGlvbiBoYXZpbmcgdGhlIHNhbWUgbmFtZSBhbmQgYXJndW1lbnQgbGlzdC4g
VGhpcywgZm9yIGV4YW1wbGUsIHdvdWxkIHJlbWFpbiBpbGxlZ2FsOjwvcD4KPHByZSBjbGFz
cz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1
Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xh
c3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+aWQ8L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5
d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj52YWx1ZTwvc3Bhbj48
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+fTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTs8L3NwYW4+CjxzcGFuIGNsYXNz
PSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwv
c3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFz
cz0ibmFtZSI+aWQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8
c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5h
bWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4gPHNw
YW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+Zm9v
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0i
a2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik7
PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4o
PC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im5hbWUiPmlucHV0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwv
c3Bhbj4gPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBkb2VzIG5vdCBtYXRjaCBh
bnkgcHJldmlvdXMgZGVjbGFyYXRpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj4KICA8
c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJw
dW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPkFkZGl0aW9uYWxseSwgYW5kIGZvciBv
YnZpb3VzIHJlYXNvbnMsIHdlIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZSBwcm9oaWJpdGlvbiAo
W2RjbC5mY3RdLzExKSBhZ2FpbnN0IGRlZmluaW5nIHR5cGVzIGluIHJldHVybiB0eXBlIHNw
ZWNpZmljYXRpb25zLiBXZSBhZGRpdGlvbmFsbHkgbm90ZSB0aGF0IHRoaXMgcHJvaGliaXRp
b24gaXMgYWxyZWFkeSBub3QgZW5mb3JjZWQgYnkgYXQgbGVhc3Qgb25lIG1ham9yIGNvbXBp
bGVyIChNU1ZDKS4gV2UgZnVydGhlciBiZWxpZXZlIHRoaXMgcHJvaGliaXRpb24gdG8gYmUg
b3V0ZGF0ZWQ7IGl0IG1hZGUgc2Vuc2UgaW4gQysrOTgsIGJ1dCB3aXRoIHJlY2VudCBjaGFu
Z2VzIHN1Y2ggYXMgdGhlIGFkZGl0aW9uIG9mIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJh
bCI+ZGVjbHR5cGU8L3R0PiBhbmQgdGhlIGFiaWxpdHkgdG8gb21pdCB0aGUgdHlwZSBuYW1l
IGluIGEgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5yZXR1cm48L3R0PiBzdGF0ZW1l
bnQgcmV0dXJuaW5nIGFuIGluLXBsYWNlIGNvbnN0cnVjdGVkIGNsYXNzLCB0aGUgcmVhc29u
cyBmb3IgdGhlIHByb2hpYml0aW9uIGhhdmUgYmVlbiBncmVhdGx5IG1pdGlnYXRlZC4gVGhp
cyBvdGhlciBwYXJ0IG9mIHRoaXMgcHJvcG9zYWwgd291bGQgbGFyZ2VseSByZW1vdmUgYW55
IHJlbWFpbmluZyBtb3RpdmF0aW9uIGZvciB0aGUgcHJvaGliaXRpb24uPC9wPgo8L2Rpdj4K
PGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9InByb3Bvc2VkLXdvcmRpbmciPgo8aDE+PGEgY2xh
c3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ0Ij5Qcm9wb3NlZCBXb3JkaW5nPC9hPjwvaDE+
CjxwPihQcm9wb3NlZCBjaGFuZ2VzIGFyZSBzcGVjaWZpZWQgcmVsYXRpdmUgPGEgY2xhc3M9
InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRj
MS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2Ny5wZGYiPk40NTY3PC9hPi4pPC9w
Pgo8cD5BZGQgYSBuZXcgc2VjdGlvbiB0byBbZGNsLnNwZWMuYXV0b10gKDcuMS42LjQpIGFz
IGZvbGxvd3M6PC9wPgo8ZGl2IGNsYXNzPSJsaXRlcmFsLWJsb2NrIGJsb2NrLWFkZGl0aW9u
IGNvbXBvdW5kIj4KPHAgY2xhc3M9ImNvbXBvdW5kLWZpcnN0Ij5XaGVuIGEgZnVuY3Rpb24g
aXMgZGVjbGFyZWQgb3IgZGVmaW5lZCB1c2luZyA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVy
YWwiPmF1dG88L3R0PiBmb3IgdGhlIHJldHVybiB0eXBlLCBhbmQgYSBwcmV2aW91cyBkZWNs
YXJhdGlvbiBvciBkZWZpbml0aW9uIGhhdmluZyBhIGNvbmNyZXRlIHJldHVybiB0eXBlIGV4
aXN0cywgdGhlIHJldHVybiB0eXBlIHNoYWxsIGJlIGluZmVycmVkIHRvIGJlIHRoZSBwcmV2
aW91c2x5IHNlZW4gY29uY3JldGUgdHlwZS4KWzxlbT5FeGFtcGxlOjwvZW0+PC9wPgo8cHJl
IGNsYXNzPSJjb21wb3VuZC1taWRkbGUgbGl0ZXJhbC1ibG9jayI+CnN0ZDo6c3RyaW5nIGYo
KTsKYXV0byBmKCk7IC8vIE9LLCByZXR1cm4gdHlwZSBpcyBzdGQ6OnN0cmluZwo8L3ByZT4K
PHAgY2xhc3M9ImNvbXBvdW5kLWxhc3QiPuKAlCA8ZW0+ZW5kIGV4YW1wbGU8L2VtPl08L3A+
CjwvZGl2Pgo8cD5BZGQgYSBuZXcgc2VjdGlvbiB0byBbZGNsLnNwZWMuYXV0b10gKDcuMS42
LjQpIGFzIGZvbGxvd3M6PC9wPgo8ZGl2IGNsYXNzPSJsaXRlcmFsLWJsb2NrIGJsb2NrLWFk
ZGl0aW9uIGNvbXBvdW5kIj4KPHAgY2xhc3M9ImNvbXBvdW5kLWZpcnN0Ij5BIHRlbXBsYXRl
IGZ1bmN0aW9uIHJlZGVjbGFyYXRpb24gb3Igc3BlY2lhbGl6YXRpb24gaGF2aW5nIGEgcmV0
dXJuIHR5cGUgb2YgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRvPC90dD4gc2hh
bGwgbWF0Y2ggYSBwcmV2aW91cyBkZWNsYXJhdGlvbiAob3IgZGVmaW5pdGlvbikgaWYgdGhl
IGZpcnN0IHN1Y2ggZGVjbGFyYXRpb24gaGFkIGEgY29uY3JldGUgcmV0dXJuIHR5cGUuIElm
IHRoZSBmaXJzdCBzdWNoIGRlY2xhcmF0aW9uIGFsc28gaGFkIGEgcmV0dXJuIHR5cGUgb2Yg
PHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRvPC90dD4sIHRoZSBkZWNsYXJhdGlv
biB1c2luZyByZXR1cm4gdHlwZSBkZWR1Y3Rpb24gc2hhbGwgYmUgbWF0Y2hlZCBpbnN0ZWFk
LgpbPGVtPkV4YW1wbGU6PC9lbT48L3A+CjxwcmUgY2xhc3M9ImNvbXBvdW5kLW1pZGRsZSBs
aXRlcmFsLWJsb2NrIj4KdGVtcGxhdGUgJmx0O3R5cGVuYW1lIFQmZ3Q7IFQgZyhUIHQpIHsg
cmV0dXJuIHQ7IH0gLy8gIzEKdGVtcGxhdGUgYXV0byBnKGZsb2F0KTsgLy8gbWF0Y2hlcyAj
MQoKdGVtcGxhdGUgJmx0O3R5cGVuYW1lIFQmZ3Q7IGF1dG8gZyhUIHQpIHsgcmV0dXJuIHQ7
IH0gLy8gIzIKdGVtcGxhdGUgJmx0O3R5cGVuYW1lIFQmZ3Q7IFQgZyhUIHQpIHsgcmV0dXJu
IHQ7IH0KdGVtcGxhdGUgYXV0byBnKGZsb2F0KTsgLy8gbWF0Y2hlcyAjMgo8L3ByZT4KPHAg
Y2xhc3M9ImNvbXBvdW5kLWxhc3QiPuKAlCA8ZW0+ZW5kIGV4YW1wbGU8L2VtPl08L3A+Cjwv
ZGl2Pgo8cD5DaGFuZ2UgW2RjbC5mY3RdLzExICg4LjMuNS4xMSkgYXMgZm9sbG93czo8L3A+
CjxkaXYgY2xhc3M9ImxpdGVyYWwtYmxvY2sgY29tcG91bmQiPgo8cD5UeXBlcyBzaGFsbCBu
b3QgYmUgZGVmaW5lZCBpbiA8c3BhbiBjbGFzcz0icmVtb3ZhbCI+cmV0dXJuIG9yPC9zcGFu
PiBwYXJhbWV0ZXIgdHlwZXMuPC9wPgo8L2Rpdj4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rp
b24iIGlkPSJkaXNjdXNzaW9uIj4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0i
I2lkNSI+RGlzY3Vzc2lvbjwvYT48L2gxPgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0id2hh
dC1hYm91dC10ZW1wbGF0ZS1yZXR1cm4tdHlwZXMiPgo8aDI+PGEgY2xhc3M9InRvYy1iYWNr
cmVmIiBocmVmPSIjaWQ2Ij5XaGF0IGFib3V0IHRlbXBsYXRlIHJldHVybiB0eXBlcz88L2E+
PC9oMj4KPHA+SW4gQysrMTQsIHRoZSBmb2xsb3dpbmcgY29kZSBpcyBsZWdhbCBhbmQgcHJv
ZHVjZXMgdHdvIGRpc3RpbmN0IHRlbXBsYXRlczo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysr
IGxpdGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+dGVtcGxhdGU8L3NwYW4+
IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29y
ZCI+Y2xhc3M8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGNsYXNzIj5UPC9zcGFuPjxzcGFu
IGNsYXNzPSJvcGVyYXRvciI+Jmd0Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlw
ZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+KCk7PC9zcGFuPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+dGVtcGxh
dGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFz
cz0ia2V5d29yZCI+Y2xhc3M8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGNsYXNzIj5UPC9z
cGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmd0Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9Imtl
eXdvcmQiPmF1dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5mb288L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8L3NwYW4+CjwvcHJlPgo8cD5UaGlzIG9idmlvdXNs
eSBjb25mbGljdHMgd2l0aCB0aGUgcHJvcG9zZWQgZmVhdHVyZS4gQWZ0ZXIgZGlzY3Vzc2lv
biBvbiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0
ZC1wcm9wb3NhbHM8L3NwYW4+PC90dD4sIGl0IHdhcyBkZWNpZGVkIHRoYXQgdGhlIHByb3Bv
c2VkIGZlYXR1cmUgc2hvdWxkIHRha2UgcHJlY2VkZW5jZSBpbiB0aGlzIGNhc2UuIEl0IHNo
b3VsZCBhbHNvIGJlIG5vdGVkIHRoYXQgaXQgaXMgdW5jbGVhciBob3csIG9yIGV2ZW4gaWYs
IHRoZSBzZWNvbmQgZnVuY3Rpb24gY2FuIGJlIGludm9rZWQgYWNjb3JkaW5nIHRvIHRoZSBj
dXJyZW50IHJ1bGVzIG9mIHRoZSBsYW5ndWFnZS4gKFRvIHRoaXMgZW5kLCBpdCBtYXkgYmUg
ZGVzaXJhYmxlIHRvIHNpbXBseSBmb3JiaWQgdGhlIG9wcG9zaXRlIG9yZGVyaW5nLiBIb3dl
dmVyLCB3ZSBmZWVsIHRoYXQgdGhpcyB3b3VsZCBiZSBiZXR0ZXIgYWRkcmVzc2VkIHNlcGFy
YXRlbHksIHBlcmhhcHMgZXZlbiBhcyBhIERSLik8L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJz
ZWN0aW9uIiBpZD0ibXVzdC10aGUtZGVjbGFyYXRpb24tcHJvdmlkaW5nLXRoZS1jb25jcmV0
ZS10eXBlLWJlLXRoZS1maXJzdC1kZWNsYXJhdGlvbiI+CjxoMj48YSBjbGFzcz0idG9jLWJh
Y2tyZWYiIGhyZWY9IiNpZDciPk11c3QgdGhlIGRlY2xhcmF0aW9uIHByb3ZpZGluZyB0aGUg
Y29uY3JldGUgdHlwZSBiZSB0aGUgZmlyc3QgZGVjbGFyYXRpb24/PC9hPjwvaDI+CjxwPlRo
aXMgcXVlc3Rpb24gd2FzIG9yaWdpbmFsbHkgYnJvdWdodCB1cCBieSBCZW5ndCBHdXN0YWZz
c29uLiBTcGVjaWZpY2FsbHksIGZvciB0aGUgc2FrZSBvZiBzeW1tZXRyeSwgaXQgc2VlbXMg
aW5pdGlhbGx5IGRlc2lyYWJsZSB0byBhbGxvdzo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysr
IGxpdGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+
IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj4oKTs8L3NwYW4+IDxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8g
c3BlY2lmaWVkIHJldHVybiB0eXBlCjwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCI+YXV0
bzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUgZnVuY3Rpb24iPmZvbzwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNs
YXNzPSJsaXRlcmFsIG51bWJlciBpbnRlZ2VyIj40Mjwvc3Bhbj48c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4g
PHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyByZXR1cm4gdHlwZSBpbmZlcnJlZCBm
cm9tIHByaW9yIGRlY2xhcmF0aW9uCjwvc3Bhbj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1
dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5iYXI8L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8L3NwYW4+IDxzcGFuIGNsYXNzPSJjb21tZW50IHNp
bmdsZSI+Ly8gZm9yd2FyZCBkZWNsYXJhdGlvbiwgdHlwZSBub3QgeWV0IGtub3duCjwvc3Bh
bj48c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJu
YW1lIGZ1bmN0aW9uIj5iYXI8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8
L3NwYW4+IDxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gc3BlY2lmeSB0aGUgcmV0
dXJuIHR5cGUgYXMgJ2ludCcKPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5hdXRvPC9z
cGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+YmFyPC9zcGFuPjxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwv
c3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9
ImxpdGVyYWwgbnVtYmVyIGludGVnZXIiPjA8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0
aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFu
IGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gcmV0dXJuIHR5cGUgaW5mZXJyZWQgZnJvbSBw
cmlvciBkZWNsYXJhdGlvbgo8L3NwYW4+CjwvcHJlPgo8cD5UbyB0aGF0IGVuZCwgZWFybGll
ciBkcmFmdHMgb2YgdGhlIHByb3Bvc2FsIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgcHJvcG9z
ZWQgY2hhbmdlIHRvIFtkY2wuc3BlYy5hdXRvXS8xMyAoNy4xLjYuNC4xMyk6PC9wPgo8ZGl2
IGNsYXNzPSJsaXRlcmFsLWJsb2NrIGNvbXBvdW5kIj4KPHAgY2xhc3M9ImNvbXBvdW5kLWZp
cnN0Ij5SZWRlY2xhcmF0aW9ucyBvciBzcGVjaWFsaXphdGlvbnMgb2YgYSBmdW5jdGlvbiBv
ciBmdW5jdGlvbiB0ZW1wbGF0ZSB3aXRoIGEgZGVjbGFyZWQgcmV0dXJuIHR5cGUgdGhhdCB1
c2VzIGEgcGxhY2Vob2xkZXIgdHlwZSBzaGFsbCA8c3BhbiBjbGFzcz0icmVtb3ZhbCI+YWxz
byB1c2UgdGhhdCBwbGFjZWhvbGRlcjwvc3Bhbj4gPHNwYW4gY2xhc3M9ImFkZGl0aW9uIj51
c2UgZWl0aGVyIHRoYXQgcGxhY2Vob2xkZXIgb3IgYSBjb21wYXRpYmxlIGNvbmNyZXRlIHR5
cGU8L3NwYW4+LCBub3QgYSBkZWR1Y2VkIHR5cGUuIDxzcGFuIGNsYXNzPSJhZGRpdGlvbiI+
SWYgdGhlIHJldHVybiB0eXBlIGhhcyBwcmV2aW91c2x5IGJlZW4gZGVkdWNlZCwgYSBkZWNs
YXJhdGlvbiB1c2luZyBhIGNvbmNyZXRlIHR5cGUgc2hhbGwgdXNlIHRoZSBkZWR1Y2VkIHR5
cGUuPC9zcGFuPgpbPGVtPkV4YW1wbGU6PC9lbT48L3A+CjxwcmUgY2xhc3M9ImNvbXBvdW5k
LWxhc3QgbGl0ZXJhbC1ibG9jayI+CmF1dG8gZigpOwphdXRvIGYoKSB7IHJldHVybiA0Mjsg
fSAvLyByZXR1cm4gdHlwZSBpcyBpbnQKYXV0byBmKCk7IC8vIE9LCjxzcGFuIGNsYXNzPSJy
ZW1vdmFsIj5pbnQgZigpOyAvLyBlcnJvciwgY2Fubm90IGJlIG92ZXJsb2FkZWQgd2l0aCBh
dXRvIGYoKTwvc3Bhbj4KPHNwYW4gY2xhc3M9ImFkZGl0aW9uIj5pbnQgZigpOyAvLyBPSywg
ZGVkdWNlZCB0eXBlIGlzIGFsc28gaW50PC9zcGFuPgpkZWNsdHlwZShhdXRvKSBmKCk7IC8v
IGVycm9yLCBhdXRvIGFuZCBkZWNsdHlwZShhdXRvKSBkb24ndCBtYXRjaAoKPHNwYW4gY2xh
c3M9ImFkZGl0aW9uIj5hdXRvIGYoaW50KTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJhZGRpdGlv
biI+aW50IGYoaW50KTsgLy8gT0ssIHJldHVybiB0eXBlIG9mIGYoaW50KSBpcyBub3cgaW50
PC9zcGFuPgo8c3BhbiBjbGFzcz0iYWRkaXRpb24iPmZsb2F0IGYoaW50KTsgLy8gZXJyb3Is
IHJlZGVjbGFyZWQgd2l0aCBkaWZmZXJlbnQgcmV0dXJuIHR5cGU8L3NwYW4+CjwvcHJlPgo8
L2Rpdj4KPHA+SG93ZXZlciwgdXBvbiBmdXJ0aGVyIGRpc2N1c3Npb24sIHJlc2VydmF0aW9u
cyB3ZXJlIGV4cHJlc3NlZCwgYW5kIHRoZSBnZW5lcmFsIGNvbnNlbnN1cyBzZWVtcyB0byBi
ZSB0aGF0IGl0IGlzIG9rYXkgZm9yIHRoZSBmaXJzdCBkZWNsYXJhdGlvbiB0byAmcXVvdDtz
ZXQgaW4gc3RvbmUmcXVvdDsgaWYgdGhlIHJldHVybiB0eXBlIHdpbGwgYmUga25vd24gKGFu
ZCBwb3NzaWJseSBsYXRlciBpbmZlcnJlZCksIG9yIGRlZHVjZWQuIEFjY29yZGluZ2x5LCBh
YnNlbnQgdGhlIGFib3ZlIGNoYW5nZTo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVy
YWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+YXV0bzwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im5hbWUgZnVuY3Rpb24iPmJhcjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
PigpOzwvc3Bhbj4KPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3Bh
biBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+YmFyPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+KCk7PC9zcGFuPiA8c3BhbiBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIGVycm9y
LCB2aW9sYXRlcyBbZGNsLnNwZWMuYXV0b10vMTMKPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3
b3JkIj5hdXRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+YmFyPC9zcGFu
PjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj4g
PHNwYW4gY2xhc3M9ImxpdGVyYWwgbnVtYmVyIGludGVnZXIiPjA8L3NwYW4+PHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08
L3NwYW4+IDxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gb2theSwgYnV0IHJldHVy
biB0eXBlIGlzIGRlZHVjZWQsIG5vdCBpbmZlcnJlZAo8L3NwYW4+CjwvcHJlPgo8L2Rpdj4K
PGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9IndoYXQtYWJvdXQtZGVmaW5pbmctdHlwZXMtaW4t
ZnVuY3Rpb24tcG9pbnRlci10eXBlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhy
ZWY9IiNpZDgiPldoYXQgYWJvdXQgZGVmaW5pbmcgdHlwZXMgaW4gZnVuY3Rpb24gcG9pbnRl
ciB0eXBlcz88L2E+PC9oMj4KPHA+QW4gb2J2aW91cyBjb25zZXF1ZW5jZSBvZiByZWxheGlu
ZyBbZGNsLmZjdF0vMTEgaXMgdGhlIGRlc2lyZSB0byBwZXJtaXQgZnVuY3Rpb24gcG9pbnRl
cnMgd2hpY2ggcmV0dXJuIGFuIGFub255bW91cyBzdHJ1Y3QuIEZvciBleGFtcGxlOjwvcD4K
PHByZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJjb21t
ZW50IHNpbmdsZSI+Ly8gRGVjbGFyZSBhIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZSB3aGljaCBy
ZXR1cm5zIGFuIGFub255bW91cyBzdHJ1Y3QKPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3Jk
Ij51c2luZzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlJldHVybnNBbm9ueW1vdXNTdHJ1
Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9
ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9z
cGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFu
PiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPio8L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4pKCk7PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQg
c2luZ2xlIj4vLyBEZWZpbmUgYSBmdW5jdGlvbiB1c2luZyB0aGUgc2FtZQo8L3NwYW4+PHNw
YW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBm
dW5jdGlvbiI+YmFyPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48
c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVjdDwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im5hbWUiPmY8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFu
PiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3
b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCg8L3NwYW4+
PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4qPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj5mPC9z
cGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KSgpKS48L3NwYW4+PHNwYW4gY2xhc3M9
Im5hbWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+
IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJjb21t
ZW50IHNpbmdsZSI+Ly8gUHJvdmlkZSBhIG1lY2hhbmlzbSB0byBvYnRhaW4gdGhlIHJldHVy
biB0eXBlIG9mIGEgZnVuY3Rpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj50ZW1w
bGF0ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mbHQ7PC9zcGFuPjxzcGFuIGNs
YXNzPSJrZXl3b3JkIj50eXBlbmFtZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3Nw
YW4+PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mZ3Q7PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5
d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuVHlwZTwvc3Bh
bj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+Cgo8c3BhbiBjbGFzcz0ia2V5
d29yZCI+dGVtcGxhdGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bh
bj48c3BhbiBjbGFzcz0ia2V5d29yZCI+dHlwZW5hbWU8L3NwYW4+IDxzcGFuIGNsYXNzPSJu
YW1lIj5UPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4g
Y2xhc3M9ImtleXdvcmQiPnR5cGVuYW1lPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+Li4uPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+QXJnczwvc3Bhbj48c3BhbiBjbGFz
cz0ib3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8
L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNz
PSJvcGVyYXRvciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+VDwvc3Bhbj4gPHNw
YW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+
Kjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPikoPC9zcGFuPjxzcGFuIGNsYXNz
PSJuYW1lIj5BcmdzPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uKTwvc3Bh
bj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+ezwvc3Bhbj4KICAgIDxzcGFuIGNsYXNzPSJrZXl3b3JkIj51c2luZzwvc3Bh
bj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+cmVzdWx0X3Q8L3NwYW4+IDxzcGFuIGNs
YXNzPSJvcGVyYXRvciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+PHNw
YW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPn07PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBEZWNsYXJl
IGEgZnVuY3Rpb24gdGhhdCBpcyBhIFJldHVybnNBbm9ueW1vdXNTdHJ1Y3QKPC9zcGFuPjxz
cGFuIGNsYXNzPSJuYW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRv
ciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVj
dDwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZndDs6Ojwvc3Bhbj48c3BhbiBjbGFz
cz0ia2V5d29yZCB0eXBlIj5yZXN1bHRfdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZv
bzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48
L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj48c3BhbiBjbGFzcz0i
bGl0ZXJhbCBudW1iZXIgaW50ZWdlciI+MDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPn07PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+Cgo8c3Bh
biBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIFVzZSB0aGUgZnVuY3Rpb24KPC9zcGFuPjxz
cGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
Pm1haW48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogICAgPHNwYW4gY2xhc3M9ImtleXdvcmQi
PnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmJhcjwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mYW1wOzwv
c3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+KTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9w
cmU+CjxwPkl0IGlzIG91ciBvcGluaW9uIHRoYXQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXJl
IHN1ZmZpY2llbnQgdG8gYWxsb3cgdGhlIGFib3ZlLiAoSW4gZmFjdCwgdGhpcyBleGFtcGxl
IGlzIGFscmVhZHkgYWNjZXB0ZWQgYnkgYm90aCBHQ0MgYW5kIElDQyAoaW4gQysrMTEgbW9k
ZSBldmVuISksIGFsdGhvdWdoIGl0IGlzIHJlamVjdGVkIGJ5IGNsYW5nIHBlciBbZGNsLmZj
dF0vMTEuKSBBY2NvcmRpbmdseSwgd2UgZmVlbCB0aGF0IHRoaXMgcHJvcG9zYWwgc2hvdWxk
IGJlIHVuZGVyc3Rvb2QgYXMgaW50ZW5kaW5nIHRvIGFsbG93IHRoZSBhYm92ZSBleGFtcGxl
IGFuZCB0aGF0IGFkZGl0aW9uYWwgd29yZGluZyBjaGFuZ2VzIHRvIHNwZWNpZnkgdGhpcyBi
ZWhhdmlvciBhcmUgbm90IHJlcXVpcmVkIGF0IHRoaXMgdGltZS48L3A+CjwvZGl2Pgo8ZGl2
IGNsYXNzPSJzZWN0aW9uIiBpZD0id2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1pbi1wYXJh
bWV0ZXItdHlwZXMiPgo8aDI+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ5Ij5X
aGF0IGFib3V0IGRlZmluaW5nIHR5cGVzIGluIHBhcmFtZXRlciB0eXBlcz88L2E+PC9oMj4K
PHA+QW4gb2J2aW91cyBmb2xsb3ctb24gcXVlc3Rpb24gaXMsIHNob3VsZCB3ZSBhbHNvIGxp
ZnQgdGhlIHByb2hpYml0aW9uIGFnYWluc3QgdHlwZXMgZGVmaW5lZCBpbiBwYXJhbWV0ZXIg
c3BlY2lmaWNhdGlvbnM/IFRoZXJlIGhhdmUgYmVlbiBzdWdnZXN0aW9ucyBmbG9hdGVkIHRv
IGltcGxlbWVudCB0aGUgbXVjaCByZXF1ZXN0ZWQgbmFtZWQgcGFyYW1ldGVycyBpbiBzb21l
dGhpbmcgbGlrZSB0aGlzIG1hbm5lci4gSG93ZXZlciwgdGhlcmUgYXJlIHNpZ25pZmljYW50
IChpbiBvdXIgb3BpbmlvbikgcmVhc29ucyB0byBub3QgYWRkcmVzcyB0aGlzLCBhdCBsZWFz
dCBpbml0aWFsbHkuIEZpcnN0LCBpdCBpcyB3aWRlbHkgY29udGVzdGVkIHRoYXQgdGhpcyBp
cyBub3QgYW4gb3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSAobmFtZWQgcGFyYW1l
dGVycykgaW4gdGhlIGZpcnN0IHBsYWNlLiBTZWNvbmQsIGl0IGRlcGVuZHMgb24gbmFtZWQg
aW5pdGlhbGl6ZXJzLCB3aGljaCBpcyBhbiBhcmVhIG9mIG9uZ29pbmcgd29yay4gVGhpcmQs
IHRoaXMgcHJvcG9zYWwgd29ya3MgbGFyZ2VseSBiZWNhdXNlIEMrKyBmb3JiaWRzIG92ZXJs
b2FkaW5nIG9uIHJldHVybiB0eXBlLCB3aGljaCBtYXkgYmUgbGV2ZXJhZ2VkIHRvIGVsaW1p
bmF0ZSBhbnkgYW1iaWd1aXR5IGFzIHRvIHRoZSBkZWR1Y3Rpb24gb2YgdGhlIGFjdHVhbCB0
eXBlIG9mIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+OyB0aGlzIGlz
IG5vdCB0aGUgY2FzZSBmb3IgcGFyYW1ldGVycywgYW5kIHNvIHBlcm1pdHRpbmcgPHR0IGNs
YXNzPSJkb2N1dGlscyBsaXRlcmFsIj5hdXRvPC90dD4gYXMgYSBwYXJhbWV0ZXIgdHlwZSBz
cGVjaWZpZXIgd291bGQgcXVpY2tseSBydW4gaW50byBpc3N1ZXMgdGhhdCBjYW4gYmUgYXZv
aWRlZCBmb3IgdGhlIHJldHVybiB0eXBlIGNhc2UuPC9wPgo8cD5XaGlsZSB3ZSBkbyBub3Qg
d2lzaCB0byBjYXRlZ29yaWNhbGx5IHJ1bGUgb3V0IGZ1dHVyZSBjaGFuZ2VzIGluIHRoaXMg
ZGlyZWN0aW9uLCB3ZSBmZWVsIHRoYXQgaXQgaXMgbm90IGFwcHJvcHJpYXRlIGZvciB0aGlz
IHByb3Bvc2FsIHRvIGF0dGVtcHQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMuPC9wPgo8cD5P
biBhIHJlbGF0ZWQgbm90ZSwgaXQgaXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgdGhl
IHNha2Ugb2YgdGhlIGFkZGVkIHV0aWxpdHkgb2YgaW1wbGllZCByZXR1cm4gdHlwZSB0byBy
ZWxheCBbZGNsLmZjdF0vMTEuIEhvd2V2ZXIsIG11Y2ggb2YgdGhlIGJlbmVmaXQgaXMgbG9z
dCB3aXRoIHRoaXMgcHJvaGliaXRpb24gaW4gcGxhY2UuIENvbnZlcnNlbHksIHNpbXBseSBy
ZWxheGluZyB0aGUgcHJvaGliaXRpb24gaXMgb2Ygc2lnbmlmaWNhbnRseSBsZXNzIGJlbmVm
aXQgd2l0aG91dCB0aGUgcHJvcG9zZWQgaW1wbGllZCByZXR1cm4gdHlwZSBmZWF0dXJlLiBB
Y2NvcmRpbmdseSwgd2hpbGUgd2UgY29uc2lkZXJlZCBzcGxpdHRpbmcgdGhlIHR3byBjaGFu
Z2VzIGludG8gc2VwYXJhdGUgcHJvcG9zYWxzLCB3ZSBoYXZlIGRlY2lkZWQgZm9yIG5vdyB0
byBrZWVwIHRoZW0gdG9nZXRoZXIuPC9wPgo8cD5Bbm90aGVyIHF1ZXN0aW9uIHRoYXQgaGFz
IGNvbWUgdXAgaXMgaWYgc29tZXRoaW5nIGxpa2UgdGhpcyBzaG91bGQgYmUgYWxsb3dlZDo8
L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0i
a2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im5hbWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+
IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
PmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
Li4uPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjxzcGFuIGNs
YXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBj
bGFzcz0ibmFtZSI+cmVzdWx0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwv
c3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0i
bmFtZSI+YmFyPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+Cjxz
cGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0ia2V5d29y
ZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+KCk7PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pn08L3NwYW4+CjwvcHJlPgo8cD5VbmRlciB0aGUgY3VycmVudCBydWxlcyAocGx1cyByZWxh
eGVkIFtkY2wuZmN0XS8xMSksIHRoZXNlIHR3byBkZWZpbml0aW9ucyBoYXZlIGRpZmZlcmVu
dCByZXR1cm4gdHlwZXMgd2hpY2ggYXJlIG5vdCBjb252ZXJ0aWJsZS4gSXQgaXMgb3VyIG9w
aW5pb24gdGhhdCB0aGUgcnVsZXMgbWFraW5nIHRoZXNlIHR5cGVzIGRpZmZlcmVudCBhcmUg
aW4gZmFjdCBjb3JyZWN0IGFuZCBkZXNpcmFibGUsIGFuZCB0aGlzIHByb3Bvc2FsIHNwZWNp
ZmljYWxseSBkb2VzIDxlbT5ub3Q8L2VtPiBpbmNsdWRlIGFueSBjaGFuZ2VzIHdoaWNoIHdv
dWxkIG1ha2UgdGhlIHR5cGVzIGNvbXBhdGlibGUuIFdlIHdvdWxkLCBob3dldmVyLCBlbmNv
dXJhZ2UgYSBmdXR1cmUgKG9ydGhvZ29uYWwpIHByb3Bvc2FsIHdoaWNoIHdvdWxkIGFsbG93
IHNvbWV0aGluZyBsaWtlIHRoaXM6PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFs
LWJsb2NrIj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5p
bnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5iYXI8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0
aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogIDxz
cGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gVGhlICdbKl0nIG9wZXJhdG9yIGhlcmUg
Y2F1c2VzIHRoZSBjb21waWxlciB0byBzdG9yZSB0aGUgaW5wdXQgYXMgYQo8L3NwYW4+ICA8
c3BhbiBjbGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIHRlbXBvcmFyeSBhbmQgZ2VuZXJhdGUg
YW4gZXhwcmVzc2lvbiBsaXN0IGZyb20gdGhlIHVucGFja2VkIG1lbWJlcnMgb2YKPC9zcGFu
PiAgPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyB0aGUgc2FtZTsgaXQgY2FuIGJl
IHVzZWQgYW55d2hlcmUgYW4gZXhwcmVzc2lvbiBsaXN0IGlzIGFjY2VwdGVkCjwvc3Bhbj4g
IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj5bPC9zcGFuPjxz
cGFuIGNsYXNzPSJvcGVyYXRvciI+Kjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pl08L3NwYW4+PHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFu
Pgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8L2Rpdj4KPGRp
diBjbGFzcz0ic2VjdGlvbiIgaWQ9ImNvbmZsaWN0cy13aXRoLWZ1dHVyZS10cnVlLW11bHRp
cGxlLXJldHVybi12YWx1ZXMiPgo8aDI+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIj
aWQxMCI+Q29uZmxpY3RzIHdpdGggZnV0dXJlICZxdW90O3RydWUmcXVvdDsgbXVsdGlwbGUg
cmV0dXJuIHZhbHVlcz88L2E+PC9oMj4KPHA+VGhlcmUgaGFzIGJlZW4gc29tZSBkaXNjdXNz
aW9uIG9mICZxdW90O3RydWUmcXVvdDsgbXVsdGlwbGUgcmV0dXJuIHZhbHVlcywgaW4gcGFy
dGljdWxhciB3aXRoIHJlc3BlY3QgdG8gUlZPIGFuZCBzaW1pbGFyIGlzc3Vlcy4gTm8gZG91
YnQgdW5wYWNraW5nLCBpZiBhY2NlcHRlZCwgd2lsbCBwbGF5IGEgcGFydC4gQSBwb2ludCB0
aGF0IGJlYXJzIGNvbnNpZGVyYXRpb24gaXMgaWYgbW92aW5nIGRvd24gdGhlIHBhdGggb2Yg
dXNpbmcgYW5vbnltb3VzIChvciBub3QpIHN0cnVjdHMgZm9yIG11bHRpcGxlIHJldHVybiB2
YWx1ZXMgd2lsbCAmcXVvdDtwYWludCB1cyBpbnRvIGEgY29ybmVyJnF1b3Q7IHdoZXJlIGZ1
dHVyZSBvcHRpbWl6YXRpb24gcG90ZW50aWFsIGlzIHByZW1hdHVyZWx5IGVsaW1pbmF0ZWQu
PC9wPgo8cD5JdCBpcyBvdXIgaG9wZSB0aGF0IHRoZXNlIGlzc3VlcyBjYW4gYmUgYWRkcmVz
c2VkIHdpdGggZXhpc3RpbmcgY29tcG91bmQgdHlwZXMgKHdoaWNoIHdpbGwgaGF2ZSBmdXJ0
aGVyIHJlYWNoaW5nIGJlbmVmaXQpLCBhbmQgdGhhdCBpdCBpcyBhY2NvcmRpbmdseSBub3Qg
bmVjZXNzYXJ5IHRvIGhvbGQgYmFjayB0aGUgZmVhdHVyZXMgaGVyZSBwcm9wb3NlZCBpbiB0
aGUgaG9wZSBvZiBzb21ldGhpbmcgYmV0dGVyIGNvbWluZyBhbG9uZy4gQXMgaXMgb2Z0ZW4g
c2FpZCwgcGVyZmVjdCBpcyB0aGUgZW5lbXkgb2YgZ29vZC48L3A+CjwvZGl2Pgo8L2Rpdj4K
PGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9ImZ1dHVyZS1kaXJlY3Rpb25zIj4KPGgxPjxhIGNs
YXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkMTEiPkZ1dHVyZSBEaXJlY3Rpb25zPC9hPjwv
aDE+CjxwPkluIHRoZSA8YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjZGlz
Y3Vzc2lvbiI+RGlzY3Vzc2lvbjwvYT4gc2VjdGlvbiBhYm92ZSwgd2UgcHJlc2VudGVkIGEg
dXRpbGl0eSBmb3IgZXh0cmFjdGluZyB0aGUgcmV0dXJuIHR5cGUgZnJvbSBhIGZ1bmN0aW9u
IHBvaW50ZXIgdHlwZS4gVGhlIGZhY2lsaXR5IGFzIHByZXNlbnRlZCBoYXMgc2lnbmlmaWNh
bnQgbGltaXRhdGlvbnM7IG5hbWVseSwgaXQgZG9lcyBub3Qgd29yayBvbiBtZW1iZXIgZnVu
Y3Rpb25zIGFuZCB0aGUgc2V2ZXJhbCB2YXJpYXRpb25zIChlLmcuIENWLXF1YWxpZmljYXRp
b24pIHdoaWNoIGFwcGx5IHRvIHRoZSBzYW1lLiBXZSBkbyBub3QgaGVyZSBwcm9wb3NlIGEg
c3RhbmRhcmQgbGlicmFyeSBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGZhY2lsaXR5LCB3aGlj
aCBwcmVzdW1hYmx5IHdvdWxkIGNvdmVyIHRoZXNlIGNhc2VzLCBob3dldmVyIHRoZXJlIGlz
IHJvb20gdG8gaW1hZ2luZSB0aGF0IHN1Y2ggYSBmYWNpbGl0eSBjb3VsZCBiZSB1c2VmdWws
IGVzcGVjaWFsbHkgaWYgdGhlIHByb3Bvc2FscyB3ZSBwcmVzZW50IGhlcmUgYXJlIGFkb3B0
ZWQuIChEYXZpZCBLcmF1c3MgcG9pbnRzIG91dCB0aGF0IDx0dCBjbGFzcz0iZG9jdXRpbHMg
bGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjpyZWZlcmVuY2Vfd3JhcHBlcjwvc3Bh
bj48L3R0PiBjYW4gYmUgdXNlZCB0byBzaW1pbGFyIGVmZmVjdC4uLiBvbiA8ZW0+c29tZTwv
ZW0+IGNvbXBpbGVycy4gSG93ZXZlciwgaW1wZXJmZWN0IHBvcnRhYmlsaXR5IGFuZCB0aGUg
ZGlzcGFyaXR5IGJldHdlZW4gaW50ZW5kZWQgZnVuY3Rpb24gYW5kIHVzZSBmb3IgdGhpcyBy
ZXN1bHQgc3VnZ2VzdCB0aGF0IHRoaXMgaXMgbm90IHRoZSBvcHRpbWFsIGZhY2lsaXR5IGZv
ciB0aGUgcHJvYmxlbS4pPC9wPgo8cD5Bbm90aGVyIGNvbnNpZGVyYXRpb24gdGhhdCBzZWVt
cyBsaWtlbHkgdG8gY29tZSB1cCBpcyBpZiB3ZSBzaG91bGQgZnVydGhlciBzaW1wbGlmeSB0
aGUgc3ludGF4IGZvciByZXR1cm5pbmcgbXVsdGlwbGUgdmFsdWVzIChjb25jZWl2YWJseSwg
dGhpcyBjb3VsZCBhcHBseSB0byBib3RoIGFub255bW91cyBzdHJ1Y3RzIGFuZCB0byA8dHQg
Y2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6cGFpcjwv
c3Bhbj48L3R0PiAvIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9
InByZSI+c3RkOjp0dXBsZTwvc3Bhbj48L3R0PikuIFNvbWUgaGF2ZSBzdWdnZXN0ZWQgYWxs
b3dpbmcgdGhhdCB0aGUgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5zdHJ1Y3Q8L3R0
PiBrZXl3b3JkIG1heSBiZSBvbWl0dGVkLiBJbiBsaWdodCBvZiA8YSBjbGFzcz0icmVmZXJl
bmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIv
d2cyMS9kb2NzL3BhcGVycy8yMDE1L3AwMTUxcjAucGRmIj5QMDE1MTwvYT4sIHdlIGNhbiBj
b25jZWl2ZSB0aGF0IGFsbG93aW5nIHRoZSBzeW50YXggPHR0IGNsYXNzPSJkb2N1dGlscyBs
aXRlcmFsIj4mbHQ7aW50IHgsIGRvdWJsZSB5Jmd0OyBmb28oKTwvdHQ+IG1pZ2h0IGJlIGlu
dGVyZXN0aW5nLiBBdCB0aGlzIHRpbWUsIHdlIHByZWZlciB0byBmb2N1cyBvbiB0aGUgdHdv
IGZlYXR1cmVzIGhlcmUgcHJlc2VudGVkIHJhdGhlciB0aGFuIHJpc2sgb3ZlcmV4dGVuZGlu
ZyB0aGUgcmVhY2ggb2YgdGhpcyBwcm9wb3NhbC4gSG93ZXZlciwgaWYgdGhpcyBwcm9wb3Nh
bCBpcyBhY2NlcHRlZCwgaXQgcmVwcmVzZW50cyBhbiBvYnZpb3VzIGZpcnN0IHN0ZXAgdG8g
Y29uc2lkZXJpbmcgc3VjaCBmZWF0dXJlcyBpbiB0aGUgZnV0dXJlLjwvcD4KPC9kaXY+Cjxk
aXYgY2xhc3M9InNlY3Rpb24iIGlkPSJhY2tub3dsZWRnbWVudHMiPgo8aDE+PGEgY2xhc3M9
InRvYy1iYWNrcmVmIiBocmVmPSIjaWQxMiI+QWNrbm93bGVkZ21lbnRzPC9hPjwvaDE+Cjxw
PldlIHdpc2ggdG8gdGhhbmsgZXZlcnlvbmUgb24gdGhlIDx0dCBjbGFzcz0iZG9jdXRpbHMg
bGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkLXByb3Bvc2Fsczwvc3Bhbj48L3R0PiBm
b3J1bSwgZXNwZWNpYWxseSBCZW5ndCBHdXN0YWZzc29uIGFuZCBUaW0gU29uZywgZm9yIHRo
ZWlyIHZhbHVhYmxlIGZlZWRiYWNrIGFuZCBpbnNpZ2h0cy48L3A+CjwhLS0gLi4gLi4gLi4g
Li4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4g
Li4gLi4gLi4gLi4gLS0+CjwvZGl2Pgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg==
--------------050909090300080608090908--


.