Topic: [RFC] Implicit Return Type and Allowing Anonymous
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 16 Dec 2016 13:09:15 -0500
Raw View
This is a multi-part message in MIME format.
--------------090900060003000907040001
Content-Type: text/plain; charset=UTF-8
I'm soliciting comments on the attached draft proposal. At Jacksonville,
it was suggested that the case for P0222 and P0224 would be stronger by
combining the proposals; so this paper does that. One major change is
that I now suggest `decltype(return)` as the marker for reusing the
previously declared return type, which avoids some issues present in the
original proposal.
Summary:
- Remove the restriction on an anonymous type as a return value.
- Add `decltype(return)` as a permitted return type specifier meaning
'the type as seen in a previous declaration of this overload'.
This is NOT a general proposal for `decltype(return)` in function
*bodies* (although I do hope someone will make such a proposal); only as
the return type specifier.
Please let me know what y'all think!
p.s. There are some known broken links, as I intend to reference my
not-yet-published paper on slicing and generalized unpacking. These will
be fixed prior to publication once I have a document numbers.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/o31ak7%24heq%241%40blaine.gmane.org.
--------------090900060003000907040001
Content-Type: text/prs.fallenstein.rst;
name="dxxxx-implicit-return-and-anonymous-structs.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="dxxxx-implicit-return-and-anonymous-structs.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=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 and Allowing Anonymous Types as Return Values
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: DXXXXR0
:Date: 2016-12-16
:Project: ISO/IEC JTC1 SC22 WG21 Programming Language C++
:Audience: Evolution Working Group
:Author: Matthew Woehlke (mwoehlke.floss@gmail.com)
=2E. raw:: html
<style>
html { color: black; background: white; }
table.docinfo { margin: 2em 0; }
</style>
=2E. role:: cpp(code)
:language: c++
Abstract
=3D=3D=3D=3D=3D=3D=3D=3D
This proposal recommends the relaxing of [dcl.fct]/11; specifically, the =
prohibition of defining (anonymous) types as return values, and adding a =
mechanism that simplifies naming the return type of a previously declared=
function. These features were previously proposed separately, as P0222_ =
and P0224_.
=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. P0341_ presents a similar idea with tagged parameter packs as return =
values.
The addition of "structured bindings" in C++17 in particular represents a=
significant step toward support of multiple return values as first class=
citizens. This feature, along with other ongoing efforts to add first cl=
ass support for "product types" and other efforts such as P0341_ show an =
encouraging movement away from the traditional ``std::pair`` and ``std::t=
uple`` towards comparable concepts without requiring the explicit types. =
(We expect, however, that the standard template library types will remain=
useful for algorithms where the identity of the elements is unimportant,=
while it *is* important to be able to name at least the outer, if not co=
mplete, type. In that respect, we hypothesize that we may in the future s=
ee the ability to construct a ``std::tuple`` from any tuple-like, as also=
suggested in P0197_.)
On their own, however, these directions risk exacerbating the problem tha=
t this proposal aims to address. In particular, a concern with the notion=
of returning a parameter pack, as presented in P0341_, opens a potential=
ABI can of worms. Moreover, parameter packs are not true types, and are =
subject to significant limitations, such as inability to make copies or p=
ass them around as single entities, which are not shared by regular compo=
und types. With generalized unpacking (\ FIXME_), product types and param=
eter packs are effectively interchangeable, and returning a product type =
rather than a parameter pack leverages existing ABI and techniques, rathe=
r than introducing something entirely novel. The remaining issue is one o=
f naming; naming things |--| in this case, return types, especially for o=
ne-off functions |--| is *hard*.
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. This, however, le=
ads to a more interesting question: **why is it necessary to repeat the r=
eturn 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.)
While it is already possible in simple cases to use :cpp:`decltype` and a=
sample invocation of the function, this is needlessly verbose, and as th=
e argument list grows longer and/or gains arguments for which providing a=
legal value is non-trivial, it can quickly become unwieldy and unfeasibl=
e.
While both these features have use on their own, they are nevertheless re=
lated, and we believe that presenting them together makes sense, and stre=
ngthens the case for each.
Proposal
=3D=3D=3D=3D=3D=3D=3D=3D
We propose, first, to remove the restriction against anonymous types as r=
eturn values:
=2E. code:: c++
struct { int id; double value; } foo() { ... }
Second, we propose the addition of :cpp:`decltype(return)` to name |--| i=
n a function signature |--| the return type of a previously declared func=
tion. This is consistent with recent changes to the language that have pr=
ogressively relaxed the requirements for how return types are specified, =
and 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()``? With our p=
roposal, the solution is simple:
=2E. code:: c++
// foo.cpp
decltype(return) foo()
{
...
return { id, value };
}
Naturally, "previous declared" here means a declaration having the same n=
ame and argument list. This, for example, would remain illegal:
=2E. code:: c++
int foo(int);
float foo(float);
decltype(return) foo(double input) // does not match any previous decla=
ration
{
...
return result;
}
The reasons to prohibit an anonymous struct defined as a return type have=
also been significantly mitigated. Constructing the return result is a n=
on-issue, since the type name may now be elided, and the combination of :=
cpp:`auto` variable declarations, :cpp:`decltype`, and the proposed mecha=
nism for naming the return type in a function signature permit implicit n=
aming of the type where necessary. In short, the prohibition ([dcl.fct]/1=
1) against defining types in return type specifications has become largel=
y an artificial and arbitrary restriction which we propose to remove.
We additionally note that this prohibition is already not enforced by at =
least one major compiler (MSVC), and is enforced sporadically in others (=
see `What about defining types in function pointer types?`_).
Interactions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Definition of an anonymous class-type as a return value type is currently=
ill-formed (although not universally enforced by existing major compiler=
s), and the token sequence :cpp:`decltype(return)` is currently ill-forme=
d. Accordingly, this change will not affect existing and conforming code,=
and may cause existing but non-conforming code to become conforming. Thi=
s proposal does not make any changes to other existing language or librar=
y features; while conceivable that some library methods might benefit fro=
m the feature, such changes are potentially breaking, and no such changes=
are proposed at this time.
Implementation and Existing Practice
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The proposed feature to allow anonymous types as return values is at leas=
t already partly implemented by MSVC and (to a lesser extend) GCC and ICC=
=2E The curious, partial support in GCC and ICC (see `What about defining=
types in function pointer types?`_) suggests that the existing prohibiti=
on may already be largely artificial, and that removing it would accordin=
gly be a simple matter.
The proposed feature to allow :cpp:`decltype(return)` to name the return =
value has not, to our knowledge, been implemented, but given that compile=
rs must already compare the return value when confronted with an initial =
declaration followed by subsequent redeclarations and/or a definition, we=
do not anticipate any implementation difficulties.
Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Is :cpp:`decltype(return)` dangerous?
-------------------------------------
P0224_ previously recommended overloading :cpp:`auto` as a mechanism for =
implicitly naming the return type given a prior declaration. While we bel=
ieve this approach is feasible, there were some potential issues, which a=
re discussed in P0224_. While we would happily accept the solution propos=
ed by P0224_, we feel that :cpp:`decltype(return)` is less ambiguous, bot=
h to readers and to compilers. It is slightly more verbose than :cpp:`aut=
o`, but not so much that we feel the added verbosity is an issue in those=
cases where we expect it to be used, and the extra verbosity may serve t=
o deter "frivolous" use. Particularly, there is a clear distinction betwe=
en inferred return values (the traditional use of :cpp:`auto` as a return=
type) and "implied" return values (that is, the use of :cpp:`decltype(re=
turn)` as an alternate spelling of a previously declared return type).
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, alt=
hough it is rejected by clang per [dcl.fct]/11.) Accordingly, we feel tha=
t this proposal should be understood as intending to allow the above exam=
ple 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 :cpp:`decltype(return)`.=
This is not the case for parameters; the ability to overload functions w=
ould make a similar change for parameters much more complicated.
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.
What about "pass-through" of return values having equivalent types?
-------------------------------------------------------------------
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();
}
Specifically, others have expressed an interest in treating layout-compat=
ible types as equivalent (or at least, implicitly convertible), particula=
rly in the context of return values as in the above example.
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. That said, we note that FIXME_ provid=
es a ready solution to this problem:
=2E. code:: c++
struct { int result; } bar()
{
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. In particular, some feature=
s proposed by P0341_ are very much in this vein. A point that bears consi=
deration is if moving down the path of using anonymous (or not) structs f=
or multiple return values will "paint us into a corner" where future opti=
mization potential is prematurely eliminated.
It is our hope that these issues can be addressed with existing compound =
types (which will have further reaching benefit). Moreover, as previously=
stated, the use of compound types for multiple return values uses existi=
ng techniques and is well understood, whereas introducing "first class" m=
ultiple return values introduces questions of ABI and other issues.
What about deduced return types?
--------------------------------
This feature is not compatible with deduced return types at this time. If=
designated initializers are ever accepted, it might be possible to lift =
this restriction:
=2E. code:: c++
auto foo()
{
return { .x =3D 3, .y =3D 2 }; // deduce: struct { int x, y; }
}
However, we have reservations about allowing this, and do not at this tim=
e propose that this example would be well-formed.
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_ and P0341_, we can conceive that allowing the synta=
x ``<int x, double y> foo()`` might be interesting (in contrast to P0341_=
, we would suggest that this be shorthand for :cpp:`std::tuple`). At this=
time, we prefer to focus on the feature here presented rather than risk =
overextending the reach of this proposal. However, if this proposal is ac=
cepted, it represents an obvious first step to considering such features =
in the future.
A final consideration is the extension of :cpp:`decltype(return)` to allo=
w use within a function body. At the time of writing, we are not aware of=
a proposal to do so, although the idea has been floated on numerous occa=
sions. We would hope to see such an addition, which can be orthogonal to =
this proposal, in the near 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.
References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2E. FIXME current draft, and also check references to spec
=2E. _N4567: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
7.pdf
* N4567_ Working Draft, Standard for Programming Language C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4567.pdf
=2E. _N4560: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n456=
0.pdf
* N4560_ Extensions for Ranges
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4560.pdf
=2E. _P0151: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p015=
1r0.pdf
* P0151_ Proposal of Multi-Declarators (aka Structured Bindings)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0151r0.pdf
=2E. _P0197: http://wg21.link/p0197
* P0197_ Default Tuple-like Access
http://wg21.link/p0197
=2E. _P0222: http://wg21.link/p0222
* P0222_ Allowing Anonymous Structs as Return Values
http://wg21.link/p0224
=2E. _P0224: http://wg21.link/p0224
* P0224_ Implicit Return Type
http://wg21.link/p0224
=2E. _P0341: http://wg21.link/p0341
* P0341_ Parameter Packs Outside of Templates
http://wg21.link/p0341
=2E. FIXME link to gen-unpack
=2E. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..=
.. ..
=2E. |--| unicode:: U+02014 .. em dash
=2E. kate: hl reStructuredText
--------------090900060003000907040001
Content-Type: text/html; charset=UTF-8;
name="dxxxx-implicit-return-and-anonymous-structs.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="dxxxx-implicit-return-and-anonymous-structs.html"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiID8+CjwhRE9DVFlQRSBodG1s
IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRw
Oi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4K
PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJl
biIgbGFuZz0iZW4iPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+CjxtZXRhIG5hbWU9ImdlbmVy
YXRvciIgY29udGVudD0iRG9jdXRpbHMgMC4xMjogaHR0cDovL2RvY3V0aWxzLnNvdXJjZWZv
cmdlLm5ldC8iIC8+Cjx0aXRsZT5JbXBsaWNpdCBSZXR1cm4gVHlwZSBhbmQgQWxsb3dpbmcg
QW5vbnltb3VzIFN0cnVjdHMgYXMgUmV0dXJuIFZhbHVlczwvdGl0bGU+CjxtZXRhIG5hbWU9
ImRhdGUiIGNvbnRlbnQ9IjIwMTYtMTItMTYiIC8+CjxtZXRhIG5hbWU9ImF1dGhvciIgY29u
dGVudD0iTWF0dGhldyBXb2VobGtlIChtd29laGxrZS5mbG9zcyYjNjQ7Z21haWwuY29tKSIg
Lz4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KCi8qCjpBdXRob3I6IERhdmlkIEdvb2RnZXIg
KGdvb2RnZXJAcHl0aG9uLm9yZykKOklkOiAkSWQ6IGh0bWw0Y3NzMS5jc3MgNzYxNCAyMDEz
LTAyLTIxIDE1OjU1OjUxWiBtaWxkZSAkCjpDb3B5cmlnaHQ6IFRoaXMgc3R5bGVzaGVldCBo
YXMgYmVlbiBwbGFjZWQgaW4gdGhlIHB1YmxpYyBkb21haW4uCgpEZWZhdWx0IGNhc2NhZGlu
ZyBzdHlsZSBzaGVldCBmb3IgdGhlIEhUTUwgb3V0cHV0IG9mIERvY3V0aWxzLgoKU2VlIGh0
dHA6Ly9kb2N1dGlscy5zZi5uZXQvZG9jcy9ob3d0by9odG1sLXN0eWxlc2hlZXRzLmh0bWwg
Zm9yIGhvdyB0bwpjdXN0b21pemUgdGhpcyBzdHlsZSBzaGVldC4KKi8KCi8qIHVzZWQgdG8g
cmVtb3ZlIGJvcmRlcnMgZnJvbSB0YWJsZXMgYW5kIGltYWdlcyAqLwouYm9yZGVybGVzcywg
dGFibGUuYm9yZGVybGVzcyB0ZCwgdGFibGUuYm9yZGVybGVzcyB0aCB7CiAgYm9yZGVyOiAw
IH0KCnRhYmxlLmJvcmRlcmxlc3MgdGQsIHRhYmxlLmJvcmRlcmxlc3MgdGggewogIC8qIE92
ZXJyaWRlIHBhZGRpbmcgZm9yICJ0YWJsZS5kb2N1dGlscyB0ZCIgd2l0aCAiISBpbXBvcnRh
bnQiLgogICAgIFRoZSByaWdodCBwYWRkaW5nIHNlcGFyYXRlcyB0aGUgdGFibGUgY2VsbHMu
ICovCiAgcGFkZGluZzogMCAwLjVlbSAwIDAgISBpbXBvcnRhbnQgfQoKLmZpcnN0IHsKICAv
KiBPdmVycmlkZSBtb3JlIHNwZWNpZmljIG1hcmdpbiBzdHlsZXMgd2l0aCAiISBpbXBvcnRh
bnQiLiAqLwogIG1hcmdpbi10b3A6IDAgISBpbXBvcnRhbnQgfQoKLmxhc3QsIC53aXRoLXN1
YnRpdGxlIHsKICBtYXJnaW4tYm90dG9tOiAwICEgaW1wb3J0YW50IH0KCi5oaWRkZW4gewog
IGRpc3BsYXk6IG5vbmUgfQoKYS50b2MtYmFja3JlZiB7CiAgdGV4dC1kZWNvcmF0aW9uOiBu
b25lIDsKICBjb2xvcjogYmxhY2sgfQoKYmxvY2txdW90ZS5lcGlncmFwaCB7CiAgbWFyZ2lu
OiAyZW0gNWVtIDsgfQoKZGwuZG9jdXRpbHMgZGQgewogIG1hcmdpbi1ib3R0b206IDAuNWVt
IH0KCm9iamVjdFt0eXBlPSJpbWFnZS9zdmcreG1sIl0sIG9iamVjdFt0eXBlPSJhcHBsaWNh
dGlvbi94LXNob2Nrd2F2ZS1mbGFzaCJdIHsKICBvdmVyZmxvdzogaGlkZGVuOwp9CgovKiBV
bmNvbW1lbnQgKGFuZCByZW1vdmUgdGhpcyB0ZXh0ISkgdG8gZ2V0IGJvbGQtZmFjZWQgZGVm
aW5pdGlvbiBsaXN0IHRlcm1zCmRsLmRvY3V0aWxzIGR0IHsKICBmb250LXdlaWdodDogYm9s
ZCB9CiovCgpkaXYuYWJzdHJhY3QgewogIG1hcmdpbjogMmVtIDVlbSB9CgpkaXYuYWJzdHJh
Y3QgcC50b3BpYy10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIHRleHQtYWxpZ246
IGNlbnRlciB9CgpkaXYuYWRtb25pdGlvbiwgZGl2LmF0dGVudGlvbiwgZGl2LmNhdXRpb24s
IGRpdi5kYW5nZXIsIGRpdi5lcnJvciwKZGl2LmhpbnQsIGRpdi5pbXBvcnRhbnQsIGRpdi5u
b3RlLCBkaXYudGlwLCBkaXYud2FybmluZyB7CiAgbWFyZ2luOiAyZW0gOwogIGJvcmRlcjog
bWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIH0KCmRpdi5hZG1vbml0aW9uIHAuYWRt
b25pdGlvbi10aXRsZSwgZGl2LmhpbnQgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYuaW1wb3J0
YW50IHAuYWRtb25pdGlvbi10aXRsZSwgZGl2Lm5vdGUgcC5hZG1vbml0aW9uLXRpdGxlLApk
aXYudGlwIHAuYWRtb25pdGlvbi10aXRsZSB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZv
bnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0KCmRpdi5hdHRlbnRpb24gcC5hZG1vbml0aW9uLXRp
dGxlLCBkaXYuY2F1dGlvbiBwLmFkbW9uaXRpb24tdGl0bGUsCmRpdi5kYW5nZXIgcC5hZG1v
bml0aW9uLXRpdGxlLCBkaXYuZXJyb3IgcC5hZG1vbml0aW9uLXRpdGxlLApkaXYud2Fybmlu
ZyBwLmFkbW9uaXRpb24tdGl0bGUsIC5jb2RlIC5lcnJvciB7CiAgY29sb3I6IHJlZCA7CiAg
Zm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmIH0KCi8qIFVu
Y29tbWVudCAoYW5kIHJlbW92ZSB0aGlzIHRleHQhKSB0byBnZXQgcmVkdWNlZCB2ZXJ0aWNh
bCBzcGFjZSBpbgogICBjb21wb3VuZCBwYXJhZ3JhcGhzLgpkaXYuY29tcG91bmQgLmNvbXBv
dW5kLWZpcnN0LCBkaXYuY29tcG91bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFyZ2luLWJv
dHRvbTogMC41ZW0gfQoKZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1sYXN0LCBkaXYuY29tcG91
bmQgLmNvbXBvdW5kLW1pZGRsZSB7CiAgbWFyZ2luLXRvcDogMC41ZW0gfQoqLwoKZGl2LmRl
ZGljYXRpb24gewogIG1hcmdpbjogMmVtIDVlbSA7CiAgdGV4dC1hbGlnbjogY2VudGVyIDsK
ICBmb250LXN0eWxlOiBpdGFsaWMgfQoKZGl2LmRlZGljYXRpb24gcC50b3BpYy10aXRsZSB7
CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc3R5bGU6IG5vcm1hbCB9CgpkaXYuZmln
dXJlIHsKICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9CgpkaXYu
Zm9vdGVyLCBkaXYuaGVhZGVyIHsKICBjbGVhcjogYm90aDsKICBmb250LXNpemU6IHNtYWxs
ZXIgfQoKZGl2LmxpbmUtYmxvY2sgewogIGRpc3BsYXk6IGJsb2NrIDsKICBtYXJnaW4tdG9w
OiAxZW0gOwogIG1hcmdpbi1ib3R0b206IDFlbSB9CgpkaXYubGluZS1ibG9jayBkaXYubGlu
ZS1ibG9jayB7CiAgbWFyZ2luLXRvcDogMCA7CiAgbWFyZ2luLWJvdHRvbTogMCA7CiAgbWFy
Z2luLWxlZnQ6IDEuNWVtIH0KCmRpdi5zaWRlYmFyIHsKICBtYXJnaW46IDAgMCAwLjVlbSAx
ZW0gOwogIGJvcmRlcjogbWVkaXVtIG91dHNldCA7CiAgcGFkZGluZzogMWVtIDsKICBiYWNr
Z3JvdW5kLWNvbG9yOiAjZmZmZmVlIDsKICB3aWR0aDogNDAlIDsKICBmbG9hdDogcmlnaHQg
OwogIGNsZWFyOiByaWdodCB9CgpkaXYuc2lkZWJhciBwLnJ1YnJpYyB7CiAgZm9udC1mYW1p
bHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtc2l6ZTogbWVkaXVtIH0KCmRpdi5zeXN0ZW0tbWVz
c2FnZXMgewogIG1hcmdpbjogNWVtIH0KCmRpdi5zeXN0ZW0tbWVzc2FnZXMgaDEgewogIGNv
bG9yOiByZWQgfQoKZGl2LnN5c3RlbS1tZXNzYWdlIHsKICBib3JkZXI6IG1lZGl1bSBvdXRz
ZXQgOwogIHBhZGRpbmc6IDFlbSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2UgcC5zeXN0ZW0tbWVz
c2FnZS10aXRsZSB7CiAgY29sb3I6IHJlZCA7CiAgZm9udC13ZWlnaHQ6IGJvbGQgfQoKZGl2
LnRvcGljIHsKICBtYXJnaW46IDJlbSB9CgpoMS5zZWN0aW9uLXN1YnRpdGxlLCBoMi5zZWN0
aW9uLXN1YnRpdGxlLCBoMy5zZWN0aW9uLXN1YnRpdGxlLApoNC5zZWN0aW9uLXN1YnRpdGxl
LCBoNS5zZWN0aW9uLXN1YnRpdGxlLCBoNi5zZWN0aW9uLXN1YnRpdGxlIHsKICBtYXJnaW4t
dG9wOiAwLjRlbSB9CgpoMS50aXRsZSB7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0KCmgyLnN1
YnRpdGxlIHsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKaHIuZG9jdXRpbHMgewogIHdpZHRo
OiA3NSUgfQoKaW1nLmFsaWduLWxlZnQsIC5maWd1cmUuYWxpZ24tbGVmdCwgb2JqZWN0LmFs
aWduLWxlZnQgewogIGNsZWFyOiBsZWZ0IDsKICBmbG9hdDogbGVmdCA7CiAgbWFyZ2luLXJp
Z2h0OiAxZW0gfQoKaW1nLmFsaWduLXJpZ2h0LCAuZmlndXJlLmFsaWduLXJpZ2h0LCBvYmpl
Y3QuYWxpZ24tcmlnaHQgewogIGNsZWFyOiByaWdodCA7CiAgZmxvYXQ6IHJpZ2h0IDsKICBt
YXJnaW4tbGVmdDogMWVtIH0KCmltZy5hbGlnbi1jZW50ZXIsIC5maWd1cmUuYWxpZ24tY2Vu
dGVyLCBvYmplY3QuYWxpZ24tY2VudGVyIHsKICBkaXNwbGF5OiBibG9jazsKICBtYXJnaW4t
bGVmdDogYXV0bzsKICBtYXJnaW4tcmlnaHQ6IGF1dG87Cn0KCi5hbGlnbi1sZWZ0IHsKICB0
ZXh0LWFsaWduOiBsZWZ0IH0KCi5hbGlnbi1jZW50ZXIgewogIGNsZWFyOiBib3RoIDsKICB0
ZXh0LWFsaWduOiBjZW50ZXIgfQoKLmFsaWduLXJpZ2h0IHsKICB0ZXh0LWFsaWduOiByaWdo
dCB9CgovKiByZXNldCBpbm5lciBhbGlnbm1lbnQgaW4gZmlndXJlcyAqLwpkaXYuYWxpZ24t
cmlnaHQgewogIHRleHQtYWxpZ246IGluaGVyaXQgfQoKLyogZGl2LmFsaWduLWNlbnRlciAq
IHsgKi8KLyogICB0ZXh0LWFsaWduOiBsZWZ0IH0gKi8KCm9sLnNpbXBsZSwgdWwuc2ltcGxl
IHsKICBtYXJnaW4tYm90dG9tOiAxZW0gfQoKb2wuYXJhYmljIHsKICBsaXN0LXN0eWxlOiBk
ZWNpbWFsIH0KCm9sLmxvd2VyYWxwaGEgewogIGxpc3Qtc3R5bGU6IGxvd2VyLWFscGhhIH0K
Cm9sLnVwcGVyYWxwaGEgewogIGxpc3Qtc3R5bGU6IHVwcGVyLWFscGhhIH0KCm9sLmxvd2Vy
cm9tYW4gewogIGxpc3Qtc3R5bGU6IGxvd2VyLXJvbWFuIH0KCm9sLnVwcGVycm9tYW4gewog
IGxpc3Qtc3R5bGU6IHVwcGVyLXJvbWFuIH0KCnAuYXR0cmlidXRpb24gewogIHRleHQtYWxp
Z246IHJpZ2h0IDsKICBtYXJnaW4tbGVmdDogNTAlIH0KCnAuY2FwdGlvbiB7CiAgZm9udC1z
dHlsZTogaXRhbGljIH0KCnAuY3JlZGl0cyB7CiAgZm9udC1zdHlsZTogaXRhbGljIDsKICBm
b250LXNpemU6IHNtYWxsZXIgfQoKcC5sYWJlbCB7CiAgd2hpdGUtc3BhY2U6IG5vd3JhcCB9
CgpwLnJ1YnJpYyB7CiAgZm9udC13ZWlnaHQ6IGJvbGQgOwogIGZvbnQtc2l6ZTogbGFyZ2Vy
IDsKICBjb2xvcjogbWFyb29uIDsKICB0ZXh0LWFsaWduOiBjZW50ZXIgfQoKcC5zaWRlYmFy
LXRpdGxlIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC13ZWlnaHQ6IGJv
bGQgOwogIGZvbnQtc2l6ZTogbGFyZ2VyIH0KCnAuc2lkZWJhci1zdWJ0aXRsZSB7CiAgZm9u
dC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnAudG9waWMt
dGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCnByZS5hZGRyZXNzIHsKICBtYXJnaW4t
Ym90dG9tOiAwIDsKICBtYXJnaW4tdG9wOiAwIDsKICBmb250OiBpbmhlcml0IH0KCnByZS5s
aXRlcmFsLWJsb2NrLCBwcmUuZG9jdGVzdC1ibG9jaywgcHJlLm1hdGgsIHByZS5jb2RlIHsK
ICBtYXJnaW4tbGVmdDogMmVtIDsKICBtYXJnaW4tcmlnaHQ6IDJlbSB9CgpwcmUuY29kZSAu
bG4geyBjb2xvcjogZ3JleTsgfSAvKiBsaW5lIG51bWJlcnMgKi8KcHJlLmNvZGUsIGNvZGUg
eyBiYWNrZ3JvdW5kLWNvbG9yOiAjZWVlZWVlIH0KcHJlLmNvZGUgLmNvbW1lbnQsIGNvZGUg
LmNvbW1lbnQgeyBjb2xvcjogIzVDNjU3NiB9CnByZS5jb2RlIC5rZXl3b3JkLCBjb2RlIC5r
ZXl3b3JkIHsgY29sb3I6ICMzQjBEMDY7IGZvbnQtd2VpZ2h0OiBib2xkIH0KcHJlLmNvZGUg
LmxpdGVyYWwuc3RyaW5nLCBjb2RlIC5saXRlcmFsLnN0cmluZyB7IGNvbG9yOiAjMEM1NDA0
IH0KcHJlLmNvZGUgLm5hbWUuYnVpbHRpbiwgY29kZSAubmFtZS5idWlsdGluIHsgY29sb3I6
ICMzNTJCODQgfQpwcmUuY29kZSAuZGVsZXRlZCwgY29kZSAuZGVsZXRlZCB7IGJhY2tncm91
bmQtY29sb3I6ICNERUIwQTF9CnByZS5jb2RlIC5pbnNlcnRlZCwgY29kZSAuaW5zZXJ0ZWQg
eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQTNEMjg5fQoKc3Bhbi5jbGFzc2lmaWVyIHsKICBmb250
LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9udC1zdHlsZTogb2JsaXF1ZSB9CgpzcGFuLmNs
YXNzaWZpZXItZGVsaW1pdGVyIHsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiA7CiAgZm9u
dC13ZWlnaHQ6IGJvbGQgfQoKc3Bhbi5pbnRlcnByZXRlZCB7CiAgZm9udC1mYW1pbHk6IHNh
bnMtc2VyaWYgfQoKc3Bhbi5vcHRpb24gewogIHdoaXRlLXNwYWNlOiBub3dyYXAgfQoKc3Bh
bi5wcmUgewogIHdoaXRlLXNwYWNlOiBwcmUgfQoKc3Bhbi5wcm9ibGVtYXRpYyB7CiAgY29s
b3I6IHJlZCB9CgpzcGFuLnNlY3Rpb24tc3VidGl0bGUgewogIC8qIGZvbnQtc2l6ZSByZWxh
dGl2ZSB0byBwYXJlbnQgKGgxLi5oNiBlbGVtZW50KSAqLwogIGZvbnQtc2l6ZTogODAlIH0K
CnRhYmxlLmNpdGF0aW9uIHsKICBib3JkZXItbGVmdDogc29saWQgMXB4IGdyYXk7CiAgbWFy
Z2luLWxlZnQ6IDFweCB9Cgp0YWJsZS5kb2NpbmZvIHsKICBtYXJnaW46IDJlbSA0ZW0gfQoK
dGFibGUuZG9jdXRpbHMgewogIG1hcmdpbi10b3A6IDAuNWVtIDsKICBtYXJnaW4tYm90dG9t
OiAwLjVlbSB9Cgp0YWJsZS5mb290bm90ZSB7CiAgYm9yZGVyLWxlZnQ6IHNvbGlkIDFweCBi
bGFjazsKICBtYXJnaW4tbGVmdDogMXB4IH0KCnRhYmxlLmRvY3V0aWxzIHRkLCB0YWJsZS5k
b2N1dGlscyB0aCwKdGFibGUuZG9jaW5mbyB0ZCwgdGFibGUuZG9jaW5mbyB0aCB7CiAgcGFk
ZGluZy1sZWZ0OiAwLjVlbSA7CiAgcGFkZGluZy1yaWdodDogMC41ZW0gOwogIHZlcnRpY2Fs
LWFsaWduOiB0b3AgfQoKdGFibGUuZG9jdXRpbHMgdGguZmllbGQtbmFtZSwgdGFibGUuZG9j
aW5mbyB0aC5kb2NpbmZvLW5hbWUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICB0ZXh0LWFs
aWduOiBsZWZ0IDsKICB3aGl0ZS1zcGFjZTogbm93cmFwIDsKICBwYWRkaW5nLWxlZnQ6IDAg
fQoKLyogImJvb2t0YWJzIiBzdHlsZSAobm8gdmVydGljYWwgbGluZXMpICovCnRhYmxlLmRv
Y3V0aWxzLmJvb2t0YWJzIHsKICBib3JkZXI6IDBweDsKICBib3JkZXItdG9wOiAycHggc29s
aWQ7CiAgYm9yZGVyLWJvdHRvbTogMnB4IHNvbGlkOwogIGJvcmRlci1jb2xsYXBzZTogY29s
bGFwc2U7Cn0KdGFibGUuZG9jdXRpbHMuYm9va3RhYnMgKiB7CiAgYm9yZGVyOiAwcHg7Cn0K
dGFibGUuZG9jdXRpbHMuYm9va3RhYnMgdGggewogIGJvcmRlci1ib3R0b206IHRoaW4gc29s
aWQ7CiAgdGV4dC1hbGlnbjogbGVmdDsKfQoKaDEgdHQuZG9jdXRpbHMsIGgyIHR0LmRvY3V0
aWxzLCBoMyB0dC5kb2N1dGlscywKaDQgdHQuZG9jdXRpbHMsIGg1IHR0LmRvY3V0aWxzLCBo
NiB0dC5kb2N1dGlscyB7CiAgZm9udC1zaXplOiAxMDAlIH0KCnVsLmF1dG8tdG9jIHsKICBs
aXN0LXN0eWxlLXR5cGU6IG5vbmUgfQoKPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPGRpdiBj
bGFzcz0iZG9jdW1lbnQiIGlkPSJpbXBsaWNpdC1yZXR1cm4tdHlwZS1hbmQtYWxsb3dpbmct
YW5vbnltb3VzLXN0cnVjdHMtYXMtcmV0dXJuLXZhbHVlcyI+CjxoMSBjbGFzcz0idGl0bGUi
PkltcGxpY2l0IFJldHVybiBUeXBlIGFuZCBBbGxvd2luZyBBbm9ueW1vdXMgU3RydWN0cyBh
cyBSZXR1cm4gVmFsdWVzPC9oMT4KPHRhYmxlIGNsYXNzPSJkb2NpbmZvIiBmcmFtZT0idm9p
ZCIgcnVsZXM9Im5vbmUiPgo8Y29sIGNsYXNzPSJkb2NpbmZvLW5hbWUiIC8+Cjxjb2wgY2xh
c3M9ImRvY2luZm8tY29udGVudCIgLz4KPHRib2R5IHZhbGlnbj0idG9wIj4KPHRyIGNsYXNz
PSJmaWVsZCI+PHRoIGNsYXNzPSJkb2NpbmZvLW5hbWUiPkRvY3VtZW50OjwvdGg+PHRkIGNs
YXNzPSJmaWVsZC1ib2R5Ij5EWFhYWFIwPC90ZD4KPC90cj4KPHRyPjx0aCBjbGFzcz0iZG9j
aW5mby1uYW1lIj5EYXRlOjwvdGg+Cjx0ZD4yMDE2LTEyLTE2PC90ZD48L3RyPgo8dHIgY2xh
c3M9ImZpZWxkIj48dGggY2xhc3M9ImRvY2luZm8tbmFtZSI+UHJvamVjdDo8L3RoPjx0ZCBj
bGFzcz0iZmllbGQtYm9keSI+SVNPL0lFQyBKVEMxIFNDMjIgV0cyMSBQcm9ncmFtbWluZyBM
YW5ndWFnZSBDKys8L3RkPgo8L3RyPgo8dHIgY2xhc3M9ImZpZWxkIj48dGggY2xhc3M9ImRv
Y2luZm8tbmFtZSI+QXVkaWVuY2U6PC90aD48dGQgY2xhc3M9ImZpZWxkLWJvZHkiPkV2b2x1
dGlvbiBXb3JraW5nIEdyb3VwPC90ZD4KPC90cj4KPHRyPjx0aCBjbGFzcz0iZG9jaW5mby1u
YW1lIj5BdXRob3I6PC90aD4KPHRkPk1hdHRoZXcgV29laGxrZSAoPGEgY2xhc3M9InJlZmVy
ZW5jZSBleHRlcm5hbCIgaHJlZj0ibWFpbHRvOm13b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5j
b20iPm13b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5jb208L2E+KTwvdGQ+PC90cj4KPC90Ym9k
eT4KPC90YWJsZT4KPHN0eWxlPgogIGh0bWwgeyBjb2xvcjogYmxhY2s7IGJhY2tncm91bmQ6
IHdoaXRlOyB9CiAgdGFibGUuZG9jaW5mbyB7IG1hcmdpbjogMmVtIDA7IH0KPC9zdHlsZT48
ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0iYWJzdHJhY3QiPgo8aDE+PGEgY2xhc3M9InRvYy1i
YWNrcmVmIiBocmVmPSIjaWQxIj5BYnN0cmFjdDwvYT48L2gxPgo8cD5UaGlzIHByb3Bvc2Fs
IHJlY29tbWVuZHMgdGhlIHJlbGF4aW5nIG9mIFtkY2wuZmN0XS8xMTsgc3BlY2lmaWNhbGx5
LCB0aGUgcHJvaGliaXRpb24gb2YgZGVmaW5pbmcgKGFub255bW91cykgdHlwZXMgYXMgcmV0
dXJuIHZhbHVlcywgYW5kIGFkZGluZyBhIG1lY2hhbmlzbSB0aGF0IHNpbXBsaWZpZXMgbmFt
aW5nIHRoZSByZXR1cm4gdHlwZSBvZiBhIHByZXZpb3VzbHkgZGVjbGFyZWQgZnVuY3Rpb24u
IFRoZXNlIGZlYXR1cmVzIHdlcmUgcHJldmlvdXNseSBwcm9wb3NlZCBzZXBhcmF0ZWx5LCBh
cyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5r
L3AwMjIyIj5QMDIyMjwvYT4gYW5kIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhy
ZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAyMjQiPlAwMjI0PC9hPi48L3A+CjxkaXYgY2xhc3M9
ImNvbnRlbnRzIHRvcGljIiBpZD0iY29udGVudHMiPgo8cCBjbGFzcz0idG9waWMtdGl0bGUg
Zmlyc3QiPkNvbnRlbnRzPC9wPgo8dWwgY2xhc3M9InNpbXBsZSI+CjxsaT48YSBjbGFzcz0i
cmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjYWJzdHJhY3QiIGlkPSJpZDEiPkFic3RyYWN0
PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjcmF0
aW9uYWxlIiBpZD0iaWQyIj5SYXRpb25hbGU8L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZl
cmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNwcm9wb3NhbCIgaWQ9ImlkMyI+UHJvcG9zYWw8L2E+
PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNpbnRlcmFj
dGlvbnMiIGlkPSJpZDQiPkludGVyYWN0aW9uczwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJl
ZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI2ltcGxlbWVudGF0aW9uLWFuZC1leGlzdGluZy1w
cmFjdGljZSIgaWQ9ImlkNSI+SW1wbGVtZW50YXRpb24gYW5kIEV4aXN0aW5nIFByYWN0aWNl
PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjZGlz
Y3Vzc2lvbiIgaWQ9ImlkNiI+RGlzY3Vzc2lvbjwvYT48dWw+CjxsaT48YSBjbGFzcz0icmVm
ZXJlbmNlIGludGVybmFsIiBocmVmPSIjaXMtZGVjbHR5cGUtcmV0dXJuLWRhbmdlcm91cyIg
aWQ9ImlkNyI+SXMgPGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5k
ZWNsdHlwZTwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4g
Y2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pik8L3NwYW4+PC9jb2RlPiBkYW5nZXJvdXM/PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVm
ZXJlbmNlIGludGVybmFsIiBocmVmPSIjd2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1pbi1m
dW5jdGlvbi1wb2ludGVyLXR5cGVzIiBpZD0iaWQ4Ij5XaGF0IGFib3V0IGRlZmluaW5nIHR5
cGVzIGluIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZXM/PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0i
cmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjd2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1p
bi1wYXJhbWV0ZXItdHlwZXMiIGlkPSJpZDkiPldoYXQgYWJvdXQgZGVmaW5pbmcgdHlwZXMg
aW4gcGFyYW1ldGVyIHR5cGVzPzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBp
bnRlcm5hbCIgaHJlZj0iI3doYXQtYWJvdXQtcGFzcy10aHJvdWdoLW9mLXJldHVybi12YWx1
ZXMtaGF2aW5nLWVxdWl2YWxlbnQtdHlwZXMiIGlkPSJpZDEwIj5XaGF0IGFib3V0ICZxdW90
O3Bhc3MtdGhyb3VnaCZxdW90OyBvZiByZXR1cm4gdmFsdWVzIGhhdmluZyBlcXVpdmFsZW50
IHR5cGVzPzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJl
Zj0iI2NvbmZsaWN0cy13aXRoLWZ1dHVyZS10cnVlLW11bHRpcGxlLXJldHVybi12YWx1ZXMi
IGlkPSJpZDExIj5Db25mbGljdHMgd2l0aCBmdXR1cmUgJnF1b3Q7dHJ1ZSZxdW90OyBtdWx0
aXBsZSByZXR1cm4gdmFsdWVzPzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBp
bnRlcm5hbCIgaHJlZj0iI3doYXQtYWJvdXQtZGVkdWNlZC1yZXR1cm4tdHlwZXMiIGlkPSJp
ZDEyIj5XaGF0IGFib3V0IGRlZHVjZWQgcmV0dXJuIHR5cGVzPzwvYT48L2xpPgo8L3VsPgo8
L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI2Z1dHVyZS1k
aXJlY3Rpb25zIiBpZD0iaWQxMyI+RnV0dXJlIERpcmVjdGlvbnM8L2E+PC9saT4KPGxpPjxh
IGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNhY2tub3dsZWRnbWVudHMiIGlk
PSJpZDE0Ij5BY2tub3dsZWRnbWVudHM8L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVu
Y2UgaW50ZXJuYWwiIGhyZWY9IiNyZWZlcmVuY2VzIiBpZD0iaWQxNSI+UmVmZXJlbmNlczwv
YT48L2xpPgo8L3VsPgo8L2Rpdj4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJy
YXRpb25hbGUiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQyIj5SYXRp
b25hbGU8L2E+PC9oMT4KPHA+VGhlIGNvbmNlcHQgb2YgbXVsdGlwbGUgcmV0dXJuIHZhbHVl
cyBpcyB3ZWxsIGtub3duLiBBdCBwcmVzZW50LCBob3dldmVyLCBDKysgbGFja3MgYSBnb29k
IG1lY2hhbmlzbSBmb3IgaW1wbGVtZW50aW5nIHRoZSBzYW1lLiA8dHQgY2xhc3M9ImRvY3V0
aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4g
aXMgY29uc2lkZXJlZCBjbHVua3kgYnkgbWFueSBhbmQsIGNyaXRpY2FsbHksIGNyZWF0ZXMg
c3ViLW9wdGltYWwgQVBJIGJ5IHZpcnR1ZSBvZiB0aGUgcmV0dXJuZWQgdmFsdWVzIGJlaW5n
IHVubmFtZWQsIGZvcmNpbmcgZGV2ZWxvcGVycyB0byByZWx5IG9uIHN1cHBsZW1lbnRhbCBk
b2N1bWVudGF0aW9uIHRvIGV4cGxhaW4gdGhlaXIgcHVycG9zZS4gQWdncmVnYXRlcyByZXBy
ZXNlbnQgYW4gaW1wcm92ZW1lbnQsIGJlaW5nIHNlbGYtZG9jdW1lbnRpbmcsIGJ1dCB0aGUg
bmVlZCB0byBwcm92aWRlIGV4dGVybmFsIGRlZmluaXRpb25zIG9mIHRoZSBzYW1lIGlzIGF3
a3dhcmQgYW5kLCB3b3JzZSwgcG9sbHV0ZXMgdGhlaXIgY29ycmVzcG9uZGluZyBuYW1lc3Bh
Y2Ugd2l0aCBlbnRpdGllcyB0aGF0IG1heSBiZSBzaW5nbGUgdXNlLiBQcm9wb3NhbHMgc3Vj
aCBhcyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9w
ZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDE1L240NTYwLnBkZiI+
TjQ1NjA8L2E+IHByZXNlbnQgYSBjb21wbGljYXRlZCBtZWNoYW5pc20gZm9yIHByb3ZpZGlu
ZyB0YWdnZWQgKHNlbGYtZG9jdW1lbnRpbmcpIHR1cGxlLWxpa2UgdHlwZXMsIHdoaWNoIG1h
eSBiZSBuZWNlc3NhcnkgaW4gc29tZSBjYXNlcywgYnV0IHN0aWxsIHJlcHJlc2VudCBhIG5v
bi10cml2aWFsIGFtb3VudCBvZiBjb21wbGV4aXR5IHRoYXQgaWRlYWxseSBzaG91bGQgbm90
IGJlIHJlcXVpcmVkLiA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRw
Oi8vd2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4gcHJlc2VudHMgYSBzaW1pbGFyIGlkZWEg
d2l0aCB0YWdnZWQgcGFyYW1ldGVyIHBhY2tzIGFzIHJldHVybiB2YWx1ZXMuPC9wPgo8cD5U
aGUgYWRkaXRpb24gb2YgJnF1b3Q7c3RydWN0dXJlZCBiaW5kaW5ncyZxdW90OyBpbiBDKysx
NyBpbiBwYXJ0aWN1bGFyIHJlcHJlc2VudHMgYSBzaWduaWZpY2FudCBzdGVwIHRvd2FyZCBz
dXBwb3J0IG9mIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgYXMgZmlyc3QgY2xhc3MgY2l0aXpl
bnMuIFRoaXMgZmVhdHVyZSwgYWxvbmcgd2l0aCBvdGhlciBvbmdvaW5nIGVmZm9ydHMgdG8g
YWRkIGZpcnN0IGNsYXNzIHN1cHBvcnQgZm9yICZxdW90O3Byb2R1Y3QgdHlwZXMmcXVvdDsg
YW5kIG90aGVyIGVmZm9ydHMgc3VjaCBhcyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFs
IiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4gc2hvdyBhbiBlbmNv
dXJhZ2luZyBtb3ZlbWVudCBhd2F5IGZyb20gdGhlIHRyYWRpdGlvbmFsIDx0dCBjbGFzcz0i
ZG9jdXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjpwYWlyPC9zcGFuPjwv
dHQ+IGFuZCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUi
PnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gdG93YXJkcyBjb21wYXJhYmxlIGNvbmNlcHRzIHdp
dGhvdXQgcmVxdWlyaW5nIHRoZSBleHBsaWNpdCB0eXBlcy4gKFdlIGV4cGVjdCwgaG93ZXZl
ciwgdGhhdCB0aGUgc3RhbmRhcmQgdGVtcGxhdGUgbGlicmFyeSB0eXBlcyB3aWxsIHJlbWFp
biB1c2VmdWwgZm9yIGFsZ29yaXRobXMgd2hlcmUgdGhlIGlkZW50aXR5IG9mIHRoZSBlbGVt
ZW50cyBpcyB1bmltcG9ydGFudCwgd2hpbGUgaXQgPGVtPmlzPC9lbT4gaW1wb3J0YW50IHRv
IGJlIGFibGUgdG8gbmFtZSBhdCBsZWFzdCB0aGUgb3V0ZXIsIGlmIG5vdCBjb21wbGV0ZSwg
dHlwZS4gSW4gdGhhdCByZXNwZWN0LCB3ZSBoeXBvdGhlc2l6ZSB0aGF0IHdlIG1heSBpbiB0
aGUgZnV0dXJlIHNlZSB0aGUgYWJpbGl0eSB0byBjb25zdHJ1Y3QgYSA8dHQgY2xhc3M9ImRv
Y3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90
dD4gZnJvbSBhbnkgdHVwbGUtbGlrZSwgYXMgYWxzbyBzdWdnZXN0ZWQgaW4gPGEgY2xhc3M9
InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDE5NyI+UDAx
OTc8L2E+Lik8L3A+CjxwPk9uIHRoZWlyIG93biwgaG93ZXZlciwgdGhlc2UgZGlyZWN0aW9u
cyByaXNrIGV4YWNlcmJhdGluZyB0aGUgcHJvYmxlbSB0aGF0IHRoaXMgcHJvcG9zYWwgYWlt
cyB0byBhZGRyZXNzLiBJbiBwYXJ0aWN1bGFyLCBhIGNvbmNlcm4gd2l0aCB0aGUgbm90aW9u
IG9mIHJldHVybmluZyBhIHBhcmFtZXRlciBwYWNrLCBhcyBwcmVzZW50ZWQgaW4gPGEgY2xh
c3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDM0MSI+
UDAzNDE8L2E+LCBvcGVucyBhIHBvdGVudGlhbCBBQkkgY2FuIG9mIHdvcm1zLiBNb3Jlb3Zl
ciwgcGFyYW1ldGVyIHBhY2tzIGFyZSBub3QgdHJ1ZSB0eXBlcywgYW5kIGFyZSBzdWJqZWN0
IHRvIHNpZ25pZmljYW50IGxpbWl0YXRpb25zLCBzdWNoIGFzIGluYWJpbGl0eSB0byBtYWtl
IGNvcGllcyBvciBwYXNzIHRoZW0gYXJvdW5kIGFzIHNpbmdsZSBlbnRpdGllcywgd2hpY2gg
YXJlIG5vdCBzaGFyZWQgYnkgcmVndWxhciBjb21wb3VuZCB0eXBlcy4gV2l0aCBnZW5lcmFs
aXplZCB1bnBhY2tpbmcgKDxhIGhyZWY9IiNpZDE2Ij48c3BhbiBjbGFzcz0icHJvYmxlbWF0
aWMiIGlkPSJpZDE3Ij5GSVhNRV88L3NwYW4+PC9hPiksIHByb2R1Y3QgdHlwZXMgYW5kIHBh
cmFtZXRlciBwYWNrcyBhcmUgZWZmZWN0aXZlbHkgaW50ZXJjaGFuZ2VhYmxlLCBhbmQgcmV0
dXJuaW5nIGEgcHJvZHVjdCB0eXBlIHJhdGhlciB0aGFuIGEgcGFyYW1ldGVyIHBhY2sgbGV2
ZXJhZ2VzIGV4aXN0aW5nIEFCSSBhbmQgdGVjaG5pcXVlcywgcmF0aGVyIHRoYW4gaW50cm9k
dWNpbmcgc29tZXRoaW5nIGVudGlyZWx5IG5vdmVsLiBUaGUgcmVtYWluaW5nIGlzc3VlIGlz
IG9uZSBvZiBuYW1pbmc7IG5hbWluZyB0aGluZ3Mg4oCUIGluIHRoaXMgY2FzZSwgcmV0dXJu
IHR5cGVzLCBlc3BlY2lhbGx5IGZvciBvbmUtb2ZmIGZ1bmN0aW9ucyDigJQgaXMgPGVtPmhh
cmQ8L2VtPi48L3A+CjxwPkl0IGhhcyBiZWVuIHN1Z2dlc3RlZCBvbiBtdWx0aXBsZSBvY2Nh
c2lvbnMgdGhhdCB0aGUgb3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgYWJvdmUgaXNzdWVzIGlz
IHRvIHJldHVybiBhbiBhbm9ueW1vdXMgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5z
dHJ1Y3Q8L3R0Pi4gVGhpcyBzb2x2ZXMgdGhlIHByb2JsZW1zIG9mIGNsdXR0ZXIgYW5kIHNl
bGYtZG9jdW1lbnRhdGlvbiwgYnV0IHJ1bnMgYWZvdWwgb2YgYSBtdWNoIHdvcnNlIGlzc3Vl
OyBiZWNhdXNlIHRoZSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnN0cnVjdDwvdHQ+
IGlzIDxlbT5hbm9ueW1vdXM8L2VtPiwgaXQgY2FuIGJlIGRpZmZpY3VsdCB0byBpbXBvc3Np
YmxlIHRvIGdpdmUgaXRzIG5hbWUgYSBzZWNvbmQgdGltZSBpbiBvcmRlciB0byBzZXBhcmF0
ZSB0aGUgZGVjbGFyYXRpb24gYW5kIGRlZmluaXRpb24gb2YgdGhlIGZ1bmN0aW9uIHRoYXQg
d2lzaGVzIHRvIHVzZSBpdC4gVGhpcywgaG93ZXZlciwgbGVhZHMgdG8gYSBtb3JlIGludGVy
ZXN0aW5nIHF1ZXN0aW9uOiA8c3Ryb25nPndoeSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVwZWF0
IHRoZSByZXR1cm4gdmFsdWUgYXQgYWxsPzwvc3Ryb25nPjwvcD4KPHA+RXZlbiBpbiB0aGUg
Y2FzZSBvZiByZXR1cm4gdHlwZXMgdGhhdCBjYW4gYmUgbmFtZWQsIGl0IG1heSBiZSB0aGF0
IHJlcGVhdGluZyB0aGUgdHlwZSBuYW1lIGlzIGV4Y2Vzc2l2ZWx5IHZlcmJvc2Ugb3Igb3Ro
ZXJ3aXNlIHVuZGVzaXJhYmxlLiBTb21lIG1pZ2h0IGV2ZW4gY2FsbCB0aGlzIGEgdmlvbGF0
aW9uIG9mIHRoZSA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwczov
L2VuLndpa2lwZWRpYS5vcmcvd2lraS9Eb24ndF9yZXBlYXRfeW91cnNlbGYiPkRvbid0IFJl
cGVhdCBZb3Vyc2VsZjwvYT4gcHJpbmNpcGxlLCBzaW1pbGFyIHRvIHNvbWUgb2YgdGhlIGlz
c3VlcyB0aGF0IDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+IGZvciB2
YXJpYWJsZSBkZWNsYXJhdGlvbiB3YXMgaW50cm9kdWNlZCB0byBzb2x2ZS4gKE9uIHRoZSBm
bGlwIHNpZGUsIG9uZSBjb3VsZCBzZWUgdGhlIGFiaWxpdHkgdG8gZWxpZGUgdGhlIHJldHVy
biB0eXBlIGFzIHN1YmplY3QgdG8gbWFueSBhYnVzZXMsIGFnYWluIGluIG11Y2ggdGhlIG1h
bm5lciBvZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88L3R0Pi4gSG93ZXZl
ciwgbWFueSBsYW5ndWFnZSBmZWF0dXJlcyBjYW4gYmUgYWJ1c2VkOyB0aGlzIHNob3VsZCBu
b3QgcHJldmVudCB0aGUgYWRkaXRpb24gb2YgYSBmZWF0dXJlIHRoYXQgd291bGQgcHJvdmlk
ZSBhbiBpbXBvcnRhbnQgYmVuZWZpdCB3aGVuIHVzZWQgY29ycmVjdGx5Lik8L3A+CjxwPldo
aWxlIGl0IGlzIGFscmVhZHkgcG9zc2libGUgaW4gc2ltcGxlIGNhc2VzIHRvIHVzZSA8Y29k
ZSBjbGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBlPC9zcGFuPjwv
Y29kZT4gYW5kIGEgc2FtcGxlIGludm9jYXRpb24gb2YgdGhlIGZ1bmN0aW9uLCB0aGlzIGlz
IG5lZWRsZXNzbHkgdmVyYm9zZSwgYW5kIGFzIHRoZSBhcmd1bWVudCBsaXN0IGdyb3dzIGxv
bmdlciBhbmQvb3IgZ2FpbnMgYXJndW1lbnRzIGZvciB3aGljaCBwcm92aWRpbmcgYSBsZWdh
bCB2YWx1ZSBpcyBub24tdHJpdmlhbCwgaXQgY2FuIHF1aWNrbHkgYmVjb21lIHVud2llbGR5
IGFuZCB1bmZlYXNpYmxlLjwvcD4KPHA+V2hpbGUgYm90aCB0aGVzZSBmZWF0dXJlcyBoYXZl
IHVzZSBvbiB0aGVpciBvd24sIHRoZXkgYXJlIG5ldmVydGhlbGVzcyByZWxhdGVkLCBhbmQg
d2UgYmVsaWV2ZSB0aGF0IHByZXNlbnRpbmcgdGhlbSB0b2dldGhlciBtYWtlcyBzZW5zZSwg
YW5kIHN0cmVuZ3RoZW5zIHRoZSBjYXNlIGZvciBlYWNoLjwvcD4KPC9kaXY+CjxkaXYgY2xh
c3M9InNlY3Rpb24iIGlkPSJwcm9wb3NhbCI+CjxoMT48YSBjbGFzcz0idG9jLWJhY2tyZWYi
IGhyZWY9IiNpZDMiPlByb3Bvc2FsPC9hPjwvaDE+CjxwPldlIHByb3Bvc2UsIGZpcnN0LCB0
byByZW1vdmUgdGhlIHJlc3RyaWN0aW9uIGFnYWluc3QgYW5vbnltb3VzIHR5cGVzIGFzIHJl
dHVybiB2YWx1ZXM6PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFsLWJsb2NrIj4K
PHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+
IDxzcGFuIGNsYXNzPSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im5hbWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFz
cz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+
IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj4uLi48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4K
PC9wcmU+CjxwPlNlY29uZCwgd2UgcHJvcG9zZSB0aGUgYWRkaXRpb24gb2YgPGNvZGUgY2xh
c3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVy
bjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2RlPiB0byBu
YW1lIOKAlCBpbiBhIGZ1bmN0aW9uIHNpZ25hdHVyZSDigJQgdGhlIHJldHVybiB0eXBlIG9m
IGEgcHJldmlvdXNseSBkZWNsYXJlZCBmdW5jdGlvbi4gVGhpcyBpcyBjb25zaXN0ZW50IHdp
dGggcmVjZW50IGNoYW5nZXMgdG8gdGhlIGxhbmd1YWdlIHRoYXQgaGF2ZSBwcm9ncmVzc2l2
ZWx5IHJlbGF4ZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgaG93IHJldHVybiB0eXBlcyBhcmUg
c3BlY2lmaWVkLCBhbmQgcHJvdmlkZXMgYW4gb3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgZm9s
bG93aW5nIHByb2JsZW06PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFsLWJsb2Nr
Ij4KPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBmb28uaAo8L3NwYW4+PHNwYW4g
Y2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im5hbWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bh
bj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFt
ZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk7PC9zcGFuPgo8L3By
ZT4KPHA+SG93IGRvZXMgb25lIG5vdyBwcm92aWRlIGFuIGV4dGVybmFsIGRlZmluaXRpb24g
Zm9yIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+Zm9vKCk8L3R0Pj8gV2l0aCBvdXIg
cHJvcG9zYWwsIHRoZSBzb2x1dGlvbiBpcyBzaW1wbGU6PC9wPgo8cHJlIGNsYXNzPSJjb2Rl
IGMrKyBsaXRlcmFsLWJsb2NrIj4KPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBm
b28uY3BwCjwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVjbHR5cGU8L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1
cm48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPiA8c3BhbiBjbGFz
cz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+
CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPi4uLjwvc3Bhbj4KICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9z
cGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJu
YW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuYW1lIj52YWx1ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59
Ozwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+
TmF0dXJhbGx5LCAmcXVvdDtwcmV2aW91cyBkZWNsYXJlZCZxdW90OyBoZXJlIG1lYW5zIGEg
ZGVjbGFyYXRpb24gaGF2aW5nIHRoZSBzYW1lIG5hbWUgYW5kIGFyZ3VtZW50IGxpc3QuIFRo
aXMsIGZvciBleGFtcGxlLCB3b3VsZCByZW1haW4gaWxsZWdhbDo8L3A+CjxwcmUgY2xhc3M9
ImNvZGUgYysrIGxpdGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5p
bnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUi
PmludDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik7PC9zcGFuPgo8c3BhbiBj
bGFzcz0ia2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUgZnVu
Y3Rpb24iPmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNw
YW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+ZmxvYXQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj4pOzwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQi
PnJldHVybjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuYW1lIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9z
cGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im5hbWUiPmlucHV0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bh
bj4gPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBkb2VzIG5vdCBtYXRjaCBhbnkg
cHJldmlvdXMgZGVjbGFyYXRpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj4KICA8c3Bh
biBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+cmVz
dWx0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4KPHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+VGhlIHJlYXNvbnMgdG8gcHJv
aGliaXQgYW4gYW5vbnltb3VzIHN0cnVjdCBkZWZpbmVkIGFzIGEgcmV0dXJuIHR5cGUgaGF2
ZSBhbHNvIGJlZW4gc2lnbmlmaWNhbnRseSBtaXRpZ2F0ZWQuIENvbnN0cnVjdGluZyB0aGUg
cmV0dXJuIHJlc3VsdCBpcyBhIG5vbi1pc3N1ZSwgc2luY2UgdGhlIHR5cGUgbmFtZSBtYXkg
bm93IGJlIGVsaWRlZCwgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiA8Y29kZSBjbGFzcz0iY3Bw
IGMrKyI+PHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+PC9jb2RlPiB2YXJpYWJs
ZSBkZWNsYXJhdGlvbnMsIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ibmFt
ZSI+ZGVjbHR5cGU8L3NwYW4+PC9jb2RlPiwgYW5kIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20g
Zm9yIG5hbWluZyB0aGUgcmV0dXJuIHR5cGUgaW4gYSBmdW5jdGlvbiBzaWduYXR1cmUgcGVy
bWl0IGltcGxpY2l0IG5hbWluZyBvZiB0aGUgdHlwZSB3aGVyZSBuZWNlc3NhcnkuIEluIHNo
b3J0LCB0aGUgcHJvaGliaXRpb24gKFtkY2wuZmN0XS8xMSkgYWdhaW5zdCBkZWZpbmluZyB0
eXBlcyBpbiByZXR1cm4gdHlwZSBzcGVjaWZpY2F0aW9ucyBoYXMgYmVjb21lIGxhcmdlbHkg
YW4gYXJ0aWZpY2lhbCBhbmQgYXJiaXRyYXJ5IHJlc3RyaWN0aW9uIHdoaWNoIHdlIHByb3Bv
c2UgdG8gcmVtb3ZlLjwvcD4KPHA+V2UgYWRkaXRpb25hbGx5IG5vdGUgdGhhdCB0aGlzIHBy
b2hpYml0aW9uIGlzIGFscmVhZHkgbm90IGVuZm9yY2VkIGJ5IGF0IGxlYXN0IG9uZSBtYWpv
ciBjb21waWxlciAoTVNWQyksIGFuZCBpcyBlbmZvcmNlZCBzcG9yYWRpY2FsbHkgaW4gb3Ro
ZXJzIChzZWUgPGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3doYXQtYWJv
dXQtZGVmaW5pbmctdHlwZXMtaW4tZnVuY3Rpb24tcG9pbnRlci10eXBlcyI+V2hhdCBhYm91
dCBkZWZpbmluZyB0eXBlcyBpbiBmdW5jdGlvbiBwb2ludGVyIHR5cGVzPzwvYT4pLjwvcD4K
PC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJpbnRlcmFjdGlvbnMiPgo8aDE+PGEg
Y2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ0Ij5JbnRlcmFjdGlvbnM8L2E+PC9oMT4K
PHA+RGVmaW5pdGlvbiBvZiBhbiBhbm9ueW1vdXMgY2xhc3MtdHlwZSBhcyBhIHJldHVybiB2
YWx1ZSB0eXBlIGlzIGN1cnJlbnRseSBpbGwtZm9ybWVkIChhbHRob3VnaCBub3QgdW5pdmVy
c2FsbHkgZW5mb3JjZWQgYnkgZXhpc3RpbmcgbWFqb3IgY29tcGlsZXJzKSwgYW5kIHRoZSB0
b2tlbiBzZXF1ZW5jZSA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUi
PmRlY2x0eXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3Bh
biBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+KTwvc3Bhbj48L2NvZGU+IGlzIGN1cnJlbnRseSBpbGwtZm9ybWVkLiBBY2NvcmRpbmds
eSwgdGhpcyBjaGFuZ2Ugd2lsbCBub3QgYWZmZWN0IGV4aXN0aW5nIGFuZCBjb25mb3JtaW5n
IGNvZGUsIGFuZCBtYXkgY2F1c2UgZXhpc3RpbmcgYnV0IG5vbi1jb25mb3JtaW5nIGNvZGUg
dG8gYmVjb21lIGNvbmZvcm1pbmcuIFRoaXMgcHJvcG9zYWwgZG9lcyBub3QgbWFrZSBhbnkg
Y2hhbmdlcyB0byBvdGhlciBleGlzdGluZyBsYW5ndWFnZSBvciBsaWJyYXJ5IGZlYXR1cmVz
OyB3aGlsZSBjb25jZWl2YWJsZSB0aGF0IHNvbWUgbGlicmFyeSBtZXRob2RzIG1pZ2h0IGJl
bmVmaXQgZnJvbSB0aGUgZmVhdHVyZSwgc3VjaCBjaGFuZ2VzIGFyZSBwb3RlbnRpYWxseSBi
cmVha2luZywgYW5kIG5vIHN1Y2ggY2hhbmdlcyBhcmUgcHJvcG9zZWQgYXQgdGhpcyB0aW1l
LjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJpbXBsZW1lbnRhdGlvbi1h
bmQtZXhpc3RpbmctcHJhY3RpY2UiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVm
PSIjaWQ1Ij5JbXBsZW1lbnRhdGlvbiBhbmQgRXhpc3RpbmcgUHJhY3RpY2U8L2E+PC9oMT4K
PHA+VGhlIHByb3Bvc2VkIGZlYXR1cmUgdG8gYWxsb3cgYW5vbnltb3VzIHR5cGVzIGFzIHJl
dHVybiB2YWx1ZXMgaXMgYXQgbGVhc3QgYWxyZWFkeSBwYXJ0bHkgaW1wbGVtZW50ZWQgYnkg
TVNWQyBhbmQgKHRvIGEgbGVzc2VyIGV4dGVuZCkgR0NDIGFuZCBJQ0MuIFRoZSBjdXJpb3Vz
LCBwYXJ0aWFsIHN1cHBvcnQgaW4gR0NDIGFuZCBJQ0MgKHNlZSA8YSBjbGFzcz0icmVmZXJl
bmNlIGludGVybmFsIiBocmVmPSIjd2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1pbi1mdW5j
dGlvbi1wb2ludGVyLXR5cGVzIj5XaGF0IGFib3V0IGRlZmluaW5nIHR5cGVzIGluIGZ1bmN0
aW9uIHBvaW50ZXIgdHlwZXM/PC9hPikgc3VnZ2VzdHMgdGhhdCB0aGUgZXhpc3RpbmcgcHJv
aGliaXRpb24gbWF5IGFscmVhZHkgYmUgbGFyZ2VseSBhcnRpZmljaWFsLCBhbmQgdGhhdCBy
ZW1vdmluZyBpdCB3b3VsZCBhY2NvcmRpbmdseSBiZSBhIHNpbXBsZSBtYXR0ZXIuPC9wPgo8
cD5UaGUgcHJvcG9zZWQgZmVhdHVyZSB0byBhbGxvdyA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+
PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj48L2NvZGU+IHRvIG5hbWUgdGhlIHJldHVy
biB2YWx1ZSBoYXMgbm90LCB0byBvdXIga25vd2xlZGdlLCBiZWVuIGltcGxlbWVudGVkLCBi
dXQgZ2l2ZW4gdGhhdCBjb21waWxlcnMgbXVzdCBhbHJlYWR5IGNvbXBhcmUgdGhlIHJldHVy
biB2YWx1ZSB3aGVuIGNvbmZyb250ZWQgd2l0aCBhbiBpbml0aWFsIGRlY2xhcmF0aW9uIGZv
bGxvd2VkIGJ5IHN1YnNlcXVlbnQgcmVkZWNsYXJhdGlvbnMgYW5kL29yIGEgZGVmaW5pdGlv
biwgd2UgZG8gbm90IGFudGljaXBhdGUgYW55IGltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGll
cy48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0iZGlzY3Vzc2lvbiI+Cjxo
MT48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDYiPkRpc2N1c3Npb248L2E+PC9o
MT4KPGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9ImlzLWRlY2x0eXBlLXJldHVybi1kYW5nZXJv
dXMiPgo8aDI+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ3Ij5JcyA8Y29kZSBj
bGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBlPC9zcGFuPjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0
dXJuPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj48L2NvZGU+IGRh
bmdlcm91cz88L2E+PC9oMj4KPHA+PGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJl
Zj0iaHR0cDovL3dnMjEubGluay9wMDIyNCI+UDAyMjQ8L2E+IHByZXZpb3VzbHkgcmVjb21t
ZW5kZWQgb3ZlcmxvYWRpbmcgPGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJr
ZXl3b3JkIj5hdXRvPC9zcGFuPjwvY29kZT4gYXMgYSBtZWNoYW5pc20gZm9yIGltcGxpY2l0
bHkgbmFtaW5nIHRoZSByZXR1cm4gdHlwZSBnaXZlbiBhIHByaW9yIGRlY2xhcmF0aW9uLiBX
aGlsZSB3ZSBiZWxpZXZlIHRoaXMgYXBwcm9hY2ggaXMgZmVhc2libGUsIHRoZXJlIHdlcmUg
c29tZSBwb3RlbnRpYWwgaXNzdWVzLCB3aGljaCBhcmUgZGlzY3Vzc2VkIGluIDxhIGNsYXNz
PSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAyMjQiPlAw
MjI0PC9hPi4gV2hpbGUgd2Ugd291bGQgaGFwcGlseSBhY2NlcHQgdGhlIHNvbHV0aW9uIHBy
b3Bvc2VkIGJ5IDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93
ZzIxLmxpbmsvcDAyMjQiPlAwMjI0PC9hPiwgd2UgZmVlbCB0aGF0IDxjb2RlIGNsYXNzPSJj
cHAgYysrIj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVjbHR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPjwvY29kZT4gaXMgbGVzcyBh
bWJpZ3VvdXMsIGJvdGggdG8gcmVhZGVycyBhbmQgdG8gY29tcGlsZXJzLiBJdCBpcyBzbGln
aHRseSBtb3JlIHZlcmJvc2UgdGhhbiA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xh
c3M9ImtleXdvcmQiPmF1dG88L3NwYW4+PC9jb2RlPiwgYnV0IG5vdCBzbyBtdWNoIHRoYXQg
d2UgZmVlbCB0aGUgYWRkZWQgdmVyYm9zaXR5IGlzIGFuIGlzc3VlIGluIHRob3NlIGNhc2Vz
IHdoZXJlIHdlIGV4cGVjdCBpdCB0byBiZSB1c2VkLCBhbmQgdGhlIGV4dHJhIHZlcmJvc2l0
eSBtYXkgc2VydmUgdG8gZGV0ZXIgJnF1b3Q7ZnJpdm9sb3VzJnF1b3Q7IHVzZS4gUGFydGlj
dWxhcmx5LCB0aGVyZSBpcyBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gaW5mZXJyZWQg
cmV0dXJuIHZhbHVlcyAodGhlIHRyYWRpdGlvbmFsIHVzZSBvZiA8Y29kZSBjbGFzcz0iY3Bw
IGMrKyI+PHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+PC9jb2RlPiBhcyBhIHJl
dHVybiB0eXBlKSBhbmQgJnF1b3Q7aW1wbGllZCZxdW90OyByZXR1cm4gdmFsdWVzICh0aGF0
IGlzLCB0aGUgdXNlIG9mIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ibmFt
ZSI+ZGVjbHR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxz
cGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0
aW9uIj4pPC9zcGFuPjwvY29kZT4gYXMgYW4gYWx0ZXJuYXRlIHNwZWxsaW5nIG9mIGEgcHJl
dmlvdXNseSBkZWNsYXJlZCByZXR1cm4gdHlwZSkuPC9wPgo8L2Rpdj4KPGRpdiBjbGFzcz0i
c2VjdGlvbiIgaWQ9IndoYXQtYWJvdXQtZGVmaW5pbmctdHlwZXMtaW4tZnVuY3Rpb24tcG9p
bnRlci10eXBlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDgiPldo
YXQgYWJvdXQgZGVmaW5pbmcgdHlwZXMgaW4gZnVuY3Rpb24gcG9pbnRlciB0eXBlcz88L2E+
PC9oMj4KPHA+QW4gb2J2aW91cyBjb25zZXF1ZW5jZSBvZiByZWxheGluZyBbZGNsLmZjdF0v
MTEgaXMgdGhlIGRlc2lyZSB0byBwZXJtaXQgZnVuY3Rpb24gcG9pbnRlcnMgd2hpY2ggcmV0
dXJuIGFuIGFub255bW91cyBzdHJ1Y3QuIEZvciBleGFtcGxlOjwvcD4KPHByZSBjbGFzcz0i
Y29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+
Ly8gRGVjbGFyZSBhIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZSB3aGljaCByZXR1cm5zIGFuIGFu
b255bW91cyBzdHJ1Y3QKPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj51c2luZzwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im5hbWUiPlJldHVybnNBbm9ueW1vdXNTdHJ1Y3Q8L3NwYW4+IDxz
cGFuIGNsYXNzPSJvcGVyYXRvciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0
cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBj
bGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1
bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwv
c3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPio8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj4pKCk7PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBE
ZWZpbmUgYSBmdW5jdGlvbiB1c2luZyB0aGUgc2FtZQo8L3NwYW4+PHNwYW4gY2xhc3M9Imtl
eXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+YmFy
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0i
bmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
PmY8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPiA8c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48
L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCg8L3NwYW4+PHNwYW4gY2xhc3M9
Im9wZXJhdG9yIj4qPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj5mPC9zcGFuPjxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+KSgpKS48L3NwYW4+PHNwYW4gY2xhc3M9Im5hbWUiPnJlc3Vs
dDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+
Ly8gUHJvdmlkZSBhIG1lY2hhbmlzbSB0byBvYnRhaW4gdGhlIHJldHVybiB0eXBlIG9mIGEg
ZnVuY3Rpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj50ZW1wbGF0ZTwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mbHQ7PC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3Jk
Ij50eXBlbmFtZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+PHNwYW4gY2xh
c3M9Im9wZXJhdG9yIj4mZ3Q7PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuVHlwZTwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPjs8L3NwYW4+Cgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+dGVtcGxh
dGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFz
cz0ia2V5d29yZCI+dHlwZW5hbWU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5UPC9zcGFu
PjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdv
cmQiPnR5cGVuYW1lPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibmFtZSI+QXJnczwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3Ii
PiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuYW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+
Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+VDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Kjwvc3Bhbj48c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPikoPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj5Bcmdz
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uKTwvc3Bhbj48c3BhbiBjbGFz
cz0ib3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwv
c3Bhbj4KICAgIDxzcGFuIGNsYXNzPSJrZXl3b3JkIj51c2luZzwvc3Bhbj4gPHNwYW4gY2xh
c3M9ImtleXdvcmQgdHlwZSI+cmVzdWx0X3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRv
ciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj47PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFu
PgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBEZWNsYXJlIGEgZnVuY3Rpb24g
dGhhdCBpcyBhIFJldHVybnNBbm9ueW1vdXNTdHJ1Y3QKPC9zcGFuPjxzcGFuIGNsYXNzPSJu
YW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bh
bj48c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVjdDwvc3Bhbj48c3Bh
biBjbGFzcz0ib3BlcmF0b3IiPiZndDs6Ojwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCB0
eXBlIj5yZXN1bHRfdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj48c3BhbiBjbGFzcz0ibGl0ZXJhbCBudW1i
ZXIgaW50ZWdlciI+MDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFu
PiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+Cgo8c3BhbiBjbGFzcz0iY29t
bWVudCBzaW5nbGUiPi8vIFVzZSB0aGUgZnVuY3Rpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJr
ZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPm1haW48L3NwYW4+
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj57PC9zcGFuPgogICAgPHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im5hbWUiPmJhcjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPig8L3NwYW4+PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mYW1wOzwvc3Bhbj48c3BhbiBj
bGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTs8L3Nw
YW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPkl0IGlz
IG91ciBvcGluaW9uIHRoYXQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXJlIHN1ZmZpY2llbnQg
dG8gYWxsb3cgdGhlIGFib3ZlLiAoSW4gZmFjdCwgdGhpcyBleGFtcGxlIGlzIGFscmVhZHkg
YWNjZXB0ZWQgYnkgYm90aCBHQ0MgYW5kIElDQywgYWx0aG91Z2ggaXQgaXMgcmVqZWN0ZWQg
YnkgY2xhbmcgcGVyIFtkY2wuZmN0XS8xMS4pIEFjY29yZGluZ2x5LCB3ZSBmZWVsIHRoYXQg
dGhpcyBwcm9wb3NhbCBzaG91bGQgYmUgdW5kZXJzdG9vZCBhcyBpbnRlbmRpbmcgdG8gYWxs
b3cgdGhlIGFib3ZlIGV4YW1wbGUgYW5kIHRoYXQgYWRkaXRpb25hbCB3b3JkaW5nIGNoYW5n
ZXMgdG8gc3BlY2lmeSB0aGlzIGJlaGF2aW9yIGFyZSBub3QgcmVxdWlyZWQgYXQgdGhpcyB0
aW1lLjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJ3aGF0LWFib3V0LWRl
ZmluaW5nLXR5cGVzLWluLXBhcmFtZXRlci10eXBlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJh
Y2tyZWYiIGhyZWY9IiNpZDkiPldoYXQgYWJvdXQgZGVmaW5pbmcgdHlwZXMgaW4gcGFyYW1l
dGVyIHR5cGVzPzwvYT48L2gyPgo8cD5BbiBvYnZpb3VzIGZvbGxvdy1vbiBxdWVzdGlvbiBp
cywgc2hvdWxkIHdlIGFsc28gbGlmdCB0aGUgcHJvaGliaXRpb24gYWdhaW5zdCB0eXBlcyBk
ZWZpbmVkIGluIHBhcmFtZXRlciBzcGVjaWZpY2F0aW9ucz8gVGhlcmUgaGF2ZSBiZWVuIHN1
Z2dlc3Rpb25zIGZsb2F0ZWQgdG8gaW1wbGVtZW50IHRoZSBtdWNoIHJlcXVlc3RlZCBuYW1l
ZCBwYXJhbWV0ZXJzIGluIHNvbWV0aGluZyBsaWtlIHRoaXMgbWFubmVyLiBIb3dldmVyLCB0
aGVyZSBhcmUgc2lnbmlmaWNhbnQgKGluIG91ciBvcGluaW9uKSByZWFzb25zIHRvIG5vdCBh
ZGRyZXNzIHRoaXMsIGF0IGxlYXN0IGluaXRpYWxseS4gRmlyc3QsIGl0IGlzIHdpZGVseSBj
b250ZXN0ZWQgdGhhdCB0aGlzIGlzIG5vdCBhbiBvcHRpbWFsIHNvbHV0aW9uIHRvIHRoZSBw
cm9ibGVtIChuYW1lZCBwYXJhbWV0ZXJzKSBpbiB0aGUgZmlyc3QgcGxhY2UuIFNlY29uZCwg
aXQgZGVwZW5kcyBvbiBuYW1lZCBpbml0aWFsaXplcnMsIHdoaWNoIGlzIGFuIGFyZWEgb2Yg
b25nb2luZyB3b3JrLiBUaGlyZCwgdGhpcyBwcm9wb3NhbCB3b3JrcyBsYXJnZWx5IGJlY2F1
c2UgQysrIGZvcmJpZHMgb3ZlcmxvYWRpbmcgb24gcmV0dXJuIHR5cGUsIHdoaWNoIG1heSBi
ZSBsZXZlcmFnZWQgdG8gZWxpbWluYXRlIGFueSBhbWJpZ3VpdHkgYXMgdG8gdGhlIGRlZHVj
dGlvbiBvZiB0aGUgYWN0dWFsIHR5cGUgb2YgPGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFu
IGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj48c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2RlPi4gVGhpcyBpcyBub3QgdGhlIGNhc2Ug
Zm9yIHBhcmFtZXRlcnM7IHRoZSBhYmlsaXR5IHRvIG92ZXJsb2FkIGZ1bmN0aW9ucyB3b3Vs
ZCBtYWtlIGEgc2ltaWxhciBjaGFuZ2UgZm9yIHBhcmFtZXRlcnMgbXVjaCBtb3JlIGNvbXBs
aWNhdGVkLjwvcD4KPHA+V2hpbGUgd2UgZG8gbm90IHdpc2ggdG8gY2F0ZWdvcmljYWxseSBy
dWxlIG91dCBmdXR1cmUgY2hhbmdlcyBpbiB0aGlzIGRpcmVjdGlvbiwgd2UgZmVlbCB0aGF0
IGl0IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IgdGhpcyBwcm9wb3NhbCB0byBhdHRlbXB0IHRv
IGFkZHJlc3MgdGhlc2UgaXNzdWVzLjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24i
IGlkPSJ3aGF0LWFib3V0LXBhc3MtdGhyb3VnaC1vZi1yZXR1cm4tdmFsdWVzLWhhdmluZy1l
cXVpdmFsZW50LXR5cGVzIj4KPGgyPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lk
MTAiPldoYXQgYWJvdXQgJnF1b3Q7cGFzcy10aHJvdWdoJnF1b3Q7IG9mIHJldHVybiB2YWx1
ZXMgaGF2aW5nIGVxdWl2YWxlbnQgdHlwZXM/PC9hPjwvaDI+CjxwPkFub3RoZXIgcXVlc3Rp
b24gdGhhdCBoYXMgY29tZSB1cCBpcyBpZiBzb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBi
ZSBhbGxvd2VkOjwvcD4KPHByZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+Cjxz
cGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8
c3BhbiBjbGFzcz0ibmFtZSI+cmVzdWx0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBj
bGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj4uLi48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bh
bj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxz
cGFuIGNsYXNzPSJuYW1lIj5iYXI8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4o
KTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogIDxzcGFuIGNs
YXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5mb288L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJw
dW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPlNwZWNpZmljYWxseSwgb3RoZXJzIGhh
dmUgZXhwcmVzc2VkIGFuIGludGVyZXN0IGluIHRyZWF0aW5nIGxheW91dC1jb21wYXRpYmxl
IHR5cGVzIGFzIGVxdWl2YWxlbnQgKG9yIGF0IGxlYXN0LCBpbXBsaWNpdGx5IGNvbnZlcnRp
YmxlKSwgcGFydGljdWxhcmx5IGluIHRoZSBjb250ZXh0IG9mIHJldHVybiB2YWx1ZXMgYXMg
aW4gdGhlIGFib3ZlIGV4YW1wbGUuPC9wPgo8cD5VbmRlciB0aGUgY3VycmVudCBydWxlcyAo
cGx1cyByZWxheGVkIFtkY2wuZmN0XS8xMSksIHRoZXNlIHR3byBkZWZpbml0aW9ucyBoYXZl
IGRpZmZlcmVudCByZXR1cm4gdHlwZXMgd2hpY2ggYXJlIG5vdCBjb252ZXJ0aWJsZS4gSXQg
aXMgb3VyIG9waW5pb24gdGhhdCB0aGUgcnVsZXMgbWFraW5nIHRoZXNlIHR5cGVzIGRpZmZl
cmVudCBhcmUgaW4gZmFjdCBjb3JyZWN0IGFuZCBkZXNpcmFibGUsIGFuZCB0aGlzIHByb3Bv
c2FsIHNwZWNpZmljYWxseSBkb2VzIDxlbT5ub3Q8L2VtPiBpbmNsdWRlIGFueSBjaGFuZ2Vz
IHdoaWNoIHdvdWxkIG1ha2UgdGhlIHR5cGVzIGNvbXBhdGlibGUuIFRoYXQgc2FpZCwgd2Ug
bm90ZSB0aGF0IDxhIGhyZWY9IiNpZDE4Ij48c3BhbiBjbGFzcz0icHJvYmxlbWF0aWMiIGlk
PSJpZDE5Ij5GSVhNRV88L3NwYW4+PC9hPiBwcm92aWRlcyBhIHJlYWR5IHNvbHV0aW9uIHRv
IHRoaXMgcHJvYmxlbTo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwtYmxvY2si
Pgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im5hbWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im5hbWUiPmJhcjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigp
PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+CiAgPHNwYW4gY2xh
c3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57
PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPls8L3NwYW4+PHNwYW4gY2xhc3M9
Im9wZXJhdG9yIj46PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+XTwvc3Bhbj48
c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
KCkuLi48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTs8L3NwYW4+CjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjwvZGl2Pgo8ZGl2IGNsYXNz
PSJzZWN0aW9uIiBpZD0iY29uZmxpY3RzLXdpdGgtZnV0dXJlLXRydWUtbXVsdGlwbGUtcmV0
dXJuLXZhbHVlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDExIj5D
b25mbGljdHMgd2l0aCBmdXR1cmUgJnF1b3Q7dHJ1ZSZxdW90OyBtdWx0aXBsZSByZXR1cm4g
dmFsdWVzPzwvYT48L2gyPgo8cD5UaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gb2Yg
JnF1b3Q7dHJ1ZSZxdW90OyBtdWx0aXBsZSByZXR1cm4gdmFsdWVzLCBpbiBwYXJ0aWN1bGFy
IHdpdGggcmVzcGVjdCB0byBSVk8gYW5kIHNpbWlsYXIgaXNzdWVzLiBJbiBwYXJ0aWN1bGFy
LCBzb21lIGZlYXR1cmVzIHByb3Bvc2VkIGJ5IDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJu
YWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAzNDEiPlAwMzQxPC9hPiBhcmUgdmVyeSBt
dWNoIGluIHRoaXMgdmVpbi4gQSBwb2ludCB0aGF0IGJlYXJzIGNvbnNpZGVyYXRpb24gaXMg
aWYgbW92aW5nIGRvd24gdGhlIHBhdGggb2YgdXNpbmcgYW5vbnltb3VzIChvciBub3QpIHN0
cnVjdHMgZm9yIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgd2lsbCAmcXVvdDtwYWludCB1cyBp
bnRvIGEgY29ybmVyJnF1b3Q7IHdoZXJlIGZ1dHVyZSBvcHRpbWl6YXRpb24gcG90ZW50aWFs
IGlzIHByZW1hdHVyZWx5IGVsaW1pbmF0ZWQuPC9wPgo8cD5JdCBpcyBvdXIgaG9wZSB0aGF0
IHRoZXNlIGlzc3VlcyBjYW4gYmUgYWRkcmVzc2VkIHdpdGggZXhpc3RpbmcgY29tcG91bmQg
dHlwZXMgKHdoaWNoIHdpbGwgaGF2ZSBmdXJ0aGVyIHJlYWNoaW5nIGJlbmVmaXQpLiBNb3Jl
b3ZlciwgYXMgcHJldmlvdXNseSBzdGF0ZWQsIHRoZSB1c2Ugb2YgY29tcG91bmQgdHlwZXMg
Zm9yIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgdXNlcyBleGlzdGluZyB0ZWNobmlxdWVzIGFu
ZCBpcyB3ZWxsIHVuZGVyc3Rvb2QsIHdoZXJlYXMgaW50cm9kdWNpbmcgJnF1b3Q7Zmlyc3Qg
Y2xhc3MmcXVvdDsgbXVsdGlwbGUgcmV0dXJuIHZhbHVlcyBpbnRyb2R1Y2VzIHF1ZXN0aW9u
cyBvZiBBQkkgYW5kIG90aGVyIGlzc3Vlcy48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0
aW9uIiBpZD0id2hhdC1hYm91dC1kZWR1Y2VkLXJldHVybi10eXBlcyI+CjxoMj48YSBjbGFz
cz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDEyIj5XaGF0IGFib3V0IGRlZHVjZWQgcmV0dXJu
IHR5cGVzPzwvYT48L2gyPgo8cD5UaGlzIGZlYXR1cmUgaXMgbm90IGNvbXBhdGlibGUgd2l0
aCBkZWR1Y2VkIHJldHVybiB0eXBlcyBhdCB0aGlzIHRpbWUuIElmIGRlc2lnbmF0ZWQgaW5p
dGlhbGl6ZXJzIGFyZSBldmVyIGFjY2VwdGVkLCBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBs
aWZ0IHRoaXMgcmVzdHJpY3Rpb246PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFs
LWJsb2NrIj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4o
KTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogIDxzcGFuIGNs
YXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4uPC9zcGFuPjxzcGFuIGNsYXNz
PSJuYW1lIj54PC9zcGFuPiA8c3BhbiBjbGFzcz0ib3BlcmF0b3IiPj08L3NwYW4+IDxzcGFu
IGNsYXNzPSJsaXRlcmFsIG51bWJlciBpbnRlZ2VyIj4zPC9zcGFuPjxzcGFuIGNsYXNzPSJw
dW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4uPC9zcGFu
PjxzcGFuIGNsYXNzPSJuYW1lIj55PC9zcGFuPiA8c3BhbiBjbGFzcz0ib3BlcmF0b3IiPj08
L3NwYW4+IDxzcGFuIGNsYXNzPSJsaXRlcmFsIG51bWJlciBpbnRlZ2VyIj4yPC9zcGFuPiA8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFuPiA8c3BhbiBjbGFzcz0iY29tbWVu
dCBzaW5nbGUiPi8vIGRlZHVjZTogc3RydWN0IHsgaW50IHgsIHk7IH0KPC9zcGFuPjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPkhvd2V2ZXIsIHdlIGhh
dmUgcmVzZXJ2YXRpb25zIGFib3V0IGFsbG93aW5nIHRoaXMsIGFuZCBkbyBub3QgYXQgdGhp
cyB0aW1lIHByb3Bvc2UgdGhhdCB0aGlzIGV4YW1wbGUgd291bGQgYmUgd2VsbC1mb3JtZWQu
PC9wPgo8L2Rpdj4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJmdXR1cmUtZGly
ZWN0aW9ucyI+CjxoMT48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDEzIj5GdXR1
cmUgRGlyZWN0aW9uczwvYT48L2gxPgo8cD5JbiB0aGUgPGEgY2xhc3M9InJlZmVyZW5jZSBp
bnRlcm5hbCIgaHJlZj0iI2Rpc2N1c3Npb24iPkRpc2N1c3Npb248L2E+IHNlY3Rpb24gYWJv
dmUsIHdlIHByZXNlbnRlZCBhIHV0aWxpdHkgZm9yIGV4dHJhY3RpbmcgdGhlIHJldHVybiB0
eXBlIGZyb20gYSBmdW5jdGlvbiBwb2ludGVyIHR5cGUuIFRoZSBmYWNpbGl0eSBhcyBwcmVz
ZW50ZWQgaGFzIHNpZ25pZmljYW50IGxpbWl0YXRpb25zOyBuYW1lbHksIGl0IGRvZXMgbm90
IHdvcmsgb24gbWVtYmVyIGZ1bmN0aW9ucyBhbmQgdGhlIHNldmVyYWwgdmFyaWF0aW9ucyAo
ZS5nLiBDVi1xdWFsaWZpY2F0aW9uKSB3aGljaCBhcHBseSB0byB0aGUgc2FtZS4gV2UgZG8g
bm90IGhlcmUgcHJvcG9zZSBhIHN0YW5kYXJkIGxpYnJhcnkgaW1wbGVtZW50YXRpb24gb2Yg
dGhpcyBmYWNpbGl0eSwgd2hpY2ggcHJlc3VtYWJseSB3b3VsZCBjb3ZlciB0aGVzZSBjYXNl
cywgaG93ZXZlciB0aGVyZSBpcyByb29tIHRvIGltYWdpbmUgdGhhdCBzdWNoIGEgZmFjaWxp
dHkgY291bGQgYmUgdXNlZnVsLCBlc3BlY2lhbGx5IGlmIHRoZSBwcm9wb3NhbHMgd2UgcHJl
c2VudCBoZXJlIGFyZSBhZG9wdGVkLiAoRGF2aWQgS3JhdXNzIHBvaW50cyBvdXQgdGhhdCA8
dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6cmVm
ZXJlbmNlX3dyYXBwZXI8L3NwYW4+PC90dD4gY2FuIGJlIHVzZWQgdG8gc2ltaWxhciBlZmZl
Y3QuLi4gb24gPGVtPnNvbWU8L2VtPiBjb21waWxlcnMuIEhvd2V2ZXIsIGltcGVyZmVjdCBw
b3J0YWJpbGl0eSBhbmQgdGhlIGRpc3Bhcml0eSBiZXR3ZWVuIGludGVuZGVkIGZ1bmN0aW9u
IGFuZCB1c2UgZm9yIHRoaXMgcmVzdWx0IHN1Z2dlc3QgdGhhdCB0aGlzIGlzIG5vdCB0aGUg
b3B0aW1hbCBmYWNpbGl0eSBmb3IgdGhlIHByb2JsZW0uKTwvcD4KPHA+QW5vdGhlciBjb25z
aWRlcmF0aW9uIHRoYXQgc2VlbXMgbGlrZWx5IHRvIGNvbWUgdXAgaXMgaWYgd2Ugc2hvdWxk
IGZ1cnRoZXIgc2ltcGxpZnkgdGhlIHN5bnRheCBmb3IgcmV0dXJuaW5nIG11bHRpcGxlIHZh
bHVlcyAoY29uY2VpdmFibHksIHRoaXMgY291bGQgYXBwbHkgdG8gYm90aCBhbm9ueW1vdXMg
c3RydWN0cyBhbmQgdG8gPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj48c3BhbiBjbGFz
cz0icHJlIj5zdGQ6OnBhaXI8L3NwYW4+PC90dD4gLyA8dHQgY2xhc3M9ImRvY3V0aWxzIGxp
dGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4pLiBTb21l
IGhhdmUgc3VnZ2VzdGVkIGFsbG93aW5nIHRoYXQgdGhlIDx0dCBjbGFzcz0iZG9jdXRpbHMg
bGl0ZXJhbCI+c3RydWN0PC90dD4ga2V5d29yZCBtYXkgYmUgb21pdHRlZC4gSW4gbGlnaHQg
b2YgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVu
LXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZiI+
UDAxNTE8L2E+IGFuZCA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRw
Oi8vd2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4sIHdlIGNhbiBjb25jZWl2ZSB0aGF0IGFs
bG93aW5nIHRoZSBzeW50YXggPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj4mbHQ7aW50
IHgsIGRvdWJsZSB5Jmd0OyBmb28oKTwvdHQ+IG1pZ2h0IGJlIGludGVyZXN0aW5nIChpbiBj
b250cmFzdCB0byA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8v
d2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4sIHdlIHdvdWxkIHN1Z2dlc3QgdGhhdCB0aGlz
IGJlIHNob3J0aGFuZCBmb3IgPGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJu
YW1lIj5zdGQ8L3NwYW4+PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj46Ojwvc3Bhbj48c3BhbiBj
bGFzcz0ibmFtZSI+dHVwbGU8L3NwYW4+PC9jb2RlPikuIEF0IHRoaXMgdGltZSwgd2UgcHJl
ZmVyIHRvIGZvY3VzIG9uIHRoZSBmZWF0dXJlIGhlcmUgcHJlc2VudGVkIHJhdGhlciB0aGFu
IHJpc2sgb3ZlcmV4dGVuZGluZyB0aGUgcmVhY2ggb2YgdGhpcyBwcm9wb3NhbC4gSG93ZXZl
ciwgaWYgdGhpcyBwcm9wb3NhbCBpcyBhY2NlcHRlZCwgaXQgcmVwcmVzZW50cyBhbiBvYnZp
b3VzIGZpcnN0IHN0ZXAgdG8gY29uc2lkZXJpbmcgc3VjaCBmZWF0dXJlcyBpbiB0aGUgZnV0
dXJlLjwvcD4KPHA+QSBmaW5hbCBjb25zaWRlcmF0aW9uIGlzIHRoZSBleHRlbnNpb24gb2Yg
PGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bh
bj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdv
cmQiPnJldHVybjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9j
b2RlPiB0byBhbGxvdyB1c2Ugd2l0aGluIGEgZnVuY3Rpb24gYm9keS4gQXQgdGhlIHRpbWUg
b2Ygd3JpdGluZywgd2UgYXJlIG5vdCBhd2FyZSBvZiBhIHByb3Bvc2FsIHRvIGRvIHNvLCBh
bHRob3VnaCB0aGUgaWRlYSBoYXMgYmVlbiBmbG9hdGVkIG9uIG51bWVyb3VzIG9jY2FzaW9u
cy4gV2Ugd291bGQgaG9wZSB0byBzZWUgc3VjaCBhbiBhZGRpdGlvbiwgd2hpY2ggY2FuIGJl
IG9ydGhvZ29uYWwgdG8gdGhpcyBwcm9wb3NhbCwgaW4gdGhlIG5lYXIgZnV0dXJlLjwvcD4K
PC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJhY2tub3dsZWRnbWVudHMiPgo8aDE+
PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQxNCI+QWNrbm93bGVkZ21lbnRzPC9h
PjwvaDE+CjxwPldlIHdpc2ggdG8gdGhhbmsgZXZlcnlvbmUgb24gdGhlIDx0dCBjbGFzcz0i
ZG9jdXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkLXByb3Bvc2Fsczwvc3Bh
bj48L3R0PiBmb3J1bSwgZXNwZWNpYWxseSBCZW5ndCBHdXN0YWZzc29uIGFuZCBUaW0gU29u
ZywgZm9yIHRoZWlyIHZhbHVhYmxlIGZlZWRiYWNrIGFuZCBpbnNpZ2h0cy48L3A+CjwvZGl2
Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0icmVmZXJlbmNlcyI+CjxoMT48YSBjbGFzcz0i
dG9jLWJhY2tyZWYiIGhyZWY9IiNpZDE1Ij5SZWZlcmVuY2VzPC9hPjwvaDE+CjwhLS0gRklY
TUUgY3VycmVudCBkcmFmdCwgYW5kIGFsc28gY2hlY2sgcmVmZXJlbmNlcyB0byBzcGVjIC0t
Pgo8dWw+CjxsaT48cCBjbGFzcz0iZmlyc3QiPjxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJu
YWwiIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3Mv
cGFwZXJzLzIwMTUvbjQ1NjcucGRmIj5ONDU2NzwvYT4gV29ya2luZyBEcmFmdCwgU3RhbmRh
cmQgZm9yIFByb2dyYW1taW5nIExhbmd1YWdlIEMrKzwvcD4KPHA+PGEgY2xhc3M9InJlZmVy
ZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIy
L3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2Ny5wZGYiPmh0dHA6Ly93d3cub3Blbi1zdGQu
b3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvbjQ1NjcucGRmPC9hPjwvcD4K
PC9saT4KPC91bD4KPHVsPgo8bGk+PHAgY2xhc3M9ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJl
bmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIv
d2cyMS9kb2NzL3BhcGVycy8yMDE1L240NTYwLnBkZiI+TjQ1NjA8L2E+IEV4dGVuc2lvbnMg
Zm9yIFJhbmdlczwvcD4KPHA+PGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0i
aHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAx
NS9uNDU2MC5wZGYiPmh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2Rv
Y3MvcGFwZXJzLzIwMTUvbjQ1NjAucGRmPC9hPjwvcD4KPC9saT4KPC91bD4KPHVsPgo8bGk+
PHAgY2xhc3M9ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJo
dHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDE1
L3AwMTUxcjAucGRmIj5QMDE1MTwvYT4gUHJvcG9zYWwgb2YgTXVsdGktRGVjbGFyYXRvcnMg
KGFrYSBTdHJ1Y3R1cmVkIEJpbmRpbmdzKTwvcD4KPHA+PGEgY2xhc3M9InJlZmVyZW5jZSBl
eHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEv
ZG9jcy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZiI+aHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcv
anRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZjwvYT48L3A+Cjwv
bGk+CjwvdWw+Cjx1bD4KPGxpPjxwIGNsYXNzPSJmaXJzdCI+PGEgY2xhc3M9InJlZmVyZW5j
ZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDE5NyI+UDAxOTc8L2E+IERl
ZmF1bHQgVHVwbGUtbGlrZSBBY2Nlc3M8L3A+CjxwPjxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0
ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAxOTciPmh0dHA6Ly93ZzIxLmxpbmsv
cDAxOTc8L2E+PC9wPgo8L2xpPgo8L3VsPgo8dWw+CjxsaT48cCBjbGFzcz0iZmlyc3QiPjxh
IGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAy
MjIiPlAwMjIyPC9hPiBBbGxvd2luZyBBbm9ueW1vdXMgU3RydWN0cyBhcyBSZXR1cm4gVmFs
dWVzPC9wPgo8cD48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8v
d2cyMS5saW5rL3AwMjI0Ij5odHRwOi8vd2cyMS5saW5rL3AwMjI0PC9hPjwvcD4KPC9saT4K
PC91bD4KPHVsPgo8bGk+PHAgY2xhc3M9ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4
dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMjI0Ij5QMDIyNDwvYT4gSW1wbGlj
aXQgUmV0dXJuIFR5cGU8L3A+CjxwPjxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhy
ZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAyMjQiPmh0dHA6Ly93ZzIxLmxpbmsvcDAyMjQ8L2E+
PC9wPgo8L2xpPgo8L3VsPgo8dWw+CjxsaT48cCBjbGFzcz0iZmlyc3QiPjxhIGNsYXNzPSJy
ZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAzNDEiPlAwMzQx
PC9hPiBQYXJhbWV0ZXIgUGFja3MgT3V0c2lkZSBvZiBUZW1wbGF0ZXM8L3A+CjxwPjxhIGNs
YXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAzNDEi
Pmh0dHA6Ly93ZzIxLmxpbmsvcDAzNDE8L2E+PC9wPgo8L2xpPgo8L3VsPgo8IS0tIEZJWE1F
IGxpbmsgdG8gZ2VuLXVucGFjayAtLT4KPCEtLSAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAu
LiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAuLiAtLT4K
PCEtLSBrYXRlOiBobCByZVN0cnVjdHVyZWRUZXh0IC0tPgo8L2Rpdj4KPGRpdiBjbGFzcz0i
c3lzdGVtLW1lc3NhZ2VzIHNlY3Rpb24iPgo8aDE+RG9jdXRpbHMgU3lzdGVtIE1lc3NhZ2Vz
PC9oMT4KPGRpdiBjbGFzcz0ic3lzdGVtLW1lc3NhZ2UiIGlkPSJpZDE2Ij4KPHAgY2xhc3M9
InN5c3RlbS1tZXNzYWdlLXRpdGxlIj5TeXN0ZW0gTWVzc2FnZTogRVJST1IvMyAoPHR0IGNs
YXNzPSJkb2N1dGlscyI+ZHh4eHgtaW1wbGljaXQtcmV0dXJuLWFuZC1hbm9ueW1vdXMtc3Ry
dWN0cy5yc3Q8L3R0PiwgbGluZSAzNyk7IDxlbT48YSBocmVmPSIjaWQxNyI+YmFja2xpbms8
L2E+PC9lbT48L3A+ClVua25vd24gdGFyZ2V0IG5hbWU6ICZxdW90O2ZpeG1lJnF1b3Q7Ljwv
ZGl2Pgo8ZGl2IGNsYXNzPSJzeXN0ZW0tbWVzc2FnZSIgaWQ9ImlkMTgiPgo8cCBjbGFzcz0i
c3lzdGVtLW1lc3NhZ2UtdGl0bGUiPlN5c3RlbSBNZXNzYWdlOiBFUlJPUi8zICg8dHQgY2xh
c3M9ImRvY3V0aWxzIj5keHh4eC1pbXBsaWNpdC1yZXR1cm4tYW5kLWFub255bW91cy1zdHJ1
Y3RzLnJzdDwvdHQ+LCBsaW5lIDE3MCk7IDxlbT48YSBocmVmPSIjaWQxOSI+YmFja2xpbms8
L2E+PC9lbT48L3A+ClVua25vd24gdGFyZ2V0IG5hbWU6ICZxdW90O2ZpeG1lJnF1b3Q7Ljwv
ZGl2Pgo8L2Rpdj4KPC9kaXY+CjwvYm9keT4KPC9odG1sPgo=
--------------090900060003000907040001--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 17 Dec 2016 15:06:33 -0800 (PST)
Raw View
------=_Part_3109_1151223622.1482015993342
Content-Type: multipart/alternative;
boundary="----=_Part_3110_64694448.1482015993342"
------=_Part_3110_64694448.1482015993342
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthew Woehlke wrote:
>
> I'm soliciting comments on the attached draft proposal. At Jacksonville,=
=20
> it was suggested that the case for P0222 and P0224 would be stronger by=
=20
> combining the proposals; so this paper does that. One major change is=20
> that I now suggest `decltype(return)` as the marker for reusing the=20
> previously declared return type, which avoids some issues present in the=
=20
> original proposal.=20
>
> Summary:=20
>
> - Remove the restriction on an anonymous type as a return value.=20
>
I was confused by this summary until I read the paper. The following kind=
=20
of "anonymous type as return type" is already fully supported in C++14:
auto f() { struct { int x, y; } s; return s; }
You're proposing to go beyond that, with
struct { int x, y; } f() { ??? s; return s; }
where you additionally want-but-explicitly-do-not-propose=20
"decltype(return)" as the appropriate syntax for "???".
I think this proposal adds *consistency* to the language, but doesn't add=
=20
any functionality that working programmers should actually desire.
The minor downside I saw immediately is that unique struct types (as=20
declared anonymously in parameter types or return types) aren't terribly=20
useful because they're never equivalent. This is why I wouldn't want the=20
feature showing up in the coding style of any codebase *I* worked on: I'd=
=20
rather just give the class type a name.
template<class T>
auto today(T t) {
struct { int s; } result =3D {sizeof t};
return result;
}
template<class T>
struct { int s; } tomorrow(T t) {
return {sizeof t};
}
int main() {
static_assert(std::is_same_v<decltype(today(0)), decltype(today(0.0))>,=
"Unfortunately=20
this assertion will fail");
static_assert(std::is_same_v<decltype(tomorrow(0)), decltype(tomorrow(
0.0))>, "Unfortunately this assertion will fail");
}
The second, more important =E2=80=94 possibly killer? =E2=80=94 problem is =
also illustrated=20
by the above program: what does the following declaration(?) actually=20
declare?
template<class T>
struct {
int s;
}
tomorrow(T t) {
return {sizeof t};
}
All the way until the first closing curly brace on line 4 =E2=80=94 i.e. al=
l during=20
the parsing of the struct body =E2=80=94 this *looks* like a class template=
=20
definition. It's only upon finding the final semicolon missing that we=20
realize that it's actually a function template definition that contains a=
=20
(non-template) class definition buried inside it.
Do we already have this garden-path grammar anywhere else in the language?=
=20
I suspect we do not, and I (slightly more weakly) suspect that vendors will=
=20
be unhappy with having to parse it.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e0dc5291-30b3-44eb-81d6-629f7c220296%40isocpp.or=
g.
------=_Part_3110_64694448.1482015993342
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm solici=
ting comments on the attached draft proposal. At Jacksonville,
<br>it was suggested that the case for P0222 and P0224 would be stronger by
<br>combining the proposals; so this paper does that. One major change is
<br>that I now suggest `decltype(return)` as the marker for reusing the
<br>previously declared return type, which avoids some issues present in th=
e
<br>original proposal.
<br>
<br>Summary:
<br>
<br>- Remove the restriction on an anonymous type as a return value.
<br></blockquote><div><br></div><div>I was confused by this summary until I=
read the paper. The following kind of "anonymous type as return type&=
quot; is already fully supported in C++14:</div><div><br></div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px=
solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()</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"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"colo=
r: #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-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</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"> s</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
s</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: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div><=
br></div><div>You're proposing to go beyond that, with</div><div><br></=
div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">()</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 styl=
e=3D"color: #660;" class=3D"styled-by-prettify">???</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> s</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</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"><br></span></div></code>=
</div><div><br></div><div>where you additionally want-but-explicitly-do-not=
-propose "decltype(return)" as the appropriate syntax for "?=
??".</div><div><br></div><div>I think this proposal adds <i>consistenc=
y</i> to the language, but doesn't add any functionality that working p=
rogrammers should actually desire.</div><div><br></div><div>The minor downs=
ide I saw immediately is that unique struct types (as declared anonymously =
in parameter types or return types) aren't terribly useful because they=
're never equivalent. This is why I wouldn't want the feature showi=
ng up in the coding style of any codebase <i>I</i> worked on: I'd rathe=
r just give the class type a name.</div><div><br></div><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">template</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
lass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> today</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">T t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">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 sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> s</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: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> result </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span s=
tyle=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"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> result</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=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;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> s</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> tomorrow</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">T t</span><span style=3D"color: #66=
0;" 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"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">return</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: #008;" class=3D"styled-by-prettify">sizeof</=
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><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> main</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><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sta=
tic_assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">is_same_v</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">today</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)),</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">declty=
pe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">today</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">0.0</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">))>,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"Unfortunately this assertion will fail"=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">static_ass=
ert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</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_v</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">tomorrow</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">tomorrow</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">0.0</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">))>,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"Unfortunately this assertion will fail"<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></di=
v><div><br>The second, more important =E2=80=94 possibly killer? =E2=80=94 =
problem is also illustrated by the above program: what does the following d=
eclaration(?) actually declare?</div><div><br></div><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(18=
7, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</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"><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"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>to=
morrow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">T t</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"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">sizeof</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></d=
iv></code></div><div><br></div><div>All the way until the first closing cur=
ly brace on line 4 =E2=80=94 i.e. all during the parsing of the struct body=
=E2=80=94 this <i>looks</i> like a class template definition. It's onl=
y upon finding the final semicolon missing that we realize that it's ac=
tually a function template definition that contains a (non-template) class =
definition buried inside it.</div><div><br></div><div>Do we already have th=
is garden-path grammar anywhere else in the language? I suspect we do not, =
and I (slightly more weakly) suspect that vendors will be unhappy with havi=
ng to parse it.</div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0dc5291-30b3-44eb-81d6-629f7c220296%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e0dc5291-30b3-44eb-81d6-629f7c220296=
%40isocpp.org</a>.<br />
------=_Part_3110_64694448.1482015993342--
------=_Part_3109_1151223622.1482015993342--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 16:11:30 -0800 (PST)
Raw View
------=_Part_115_1954490924.1482019890476
Content-Type: multipart/alternative;
boundary="----=_Part_116_50730238.1482019890476"
------=_Part_116_50730238.1482019890476
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 6:06:33 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthew Woehlke wrote=
:
>>
>> I'm soliciting comments on the attached draft proposal. At Jacksonville,=
=20
>> it was suggested that the case for P0222 and P0224 would be stronger by=
=20
>> combining the proposals; so this paper does that. One major change is=20
>> that I now suggest `decltype(return)` as the marker for reusing the=20
>> previously declared return type, which avoids some issues present in the=
=20
>> original proposal.=20
>>
>> Summary:=20
>>
>> - Remove the restriction on an anonymous type as a return value.=20
>>
>
> I was confused by this summary until I read the paper. The following kind=
=20
> of "anonymous type as return type" is already fully supported in C++14:
>
> auto f() { struct { int x, y; } s; return s; }
>
> You're proposing to go beyond that, with
>
> struct { int x, y; } f() { ??? s; return s; }
>
> where you additionally want-but-explicitly-do-not-propose=20
> "decltype(return)" as the appropriate syntax for "???".
>
Not really. The idea being that you'd just do `return {};`. You would only=
=20
need `decltype(return)` if you needed to declare a variable of the return=
=20
type.
If you're using these anonymous structs as a way to do multiple return=20
values without tuples, then you don't really need the return type itself.=
=20
So the proposal is genuinely useful independently of `decltype(return)` to=
=20
fetch the function's return type.
I think this proposal adds *consistency* to the language, but doesn't add=
=20
> any functionality that working programmers should actually desire.
>
> The minor downside I saw immediately is that unique struct types (as=20
> declared anonymously in parameter types or return types) aren't terribly=
=20
> useful because they're never equivalent. This is why I wouldn't want the=
=20
> feature showing up in the coding style of any codebase *I* worked on: I'd=
=20
> rather just give the class type a name.
>
> template<class T>
> auto today(T t) {
> struct { int s; } result =3D {sizeof t};
> return result;
> }
> template<class T>
> struct { int s; } tomorrow(T t) {
> return {sizeof t};
> }
> int main() {
> static_assert(std::is_same_v<decltype(today(0)), decltype(today(0.0
> ))>, "Unfortunately this assertion will fail");
> static_assert(std::is_same_v<decltype(tomorrow(0)), decltype(tomorrow=
(
> 0.0))>, "Unfortunately this assertion will fail");
> }
>
> The second, more important =E2=80=94 possibly killer? =E2=80=94 problem i=
s also=20
> illustrated by the above program: what does the following declaration(?)=
=20
> actually declare?
>
> template<class T>
> struct {
> int s;
> }
> tomorrow(T t) {
> return {sizeof t};
> }
>
> All the way until the first closing curly brace on line 4 =E2=80=94 i.e. =
all=20
> during the parsing of the struct body =E2=80=94 this *looks* like a class=
=20
> template definition.
>
Does it? Because I'm fairly certain that class templates cannot be declared=
=20
without a name <http://ideone.com/vRQusf>. That's not definitive; I=20
wouldn't know where to start looking through the standard for this. But I'm=
=20
pretty sure it can't happen; how would you instantiate one?
=20
> It's only upon finding the final semicolon missing that we realize that=
=20
> it's actually a function template definition that contains a (non-templat=
e)=20
> class definition buried inside it.
>
> Do we already have this garden-path grammar anywhere else in the language=
?=20
> I suspect we do not, and I (slightly more weakly) suspect that vendors wi=
ll=20
> be unhappy with having to parse it.
>
> =E2=80=93Arthur
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/27525698-55a5-435f-89ca-d3b75260c4d2%40isocpp.or=
g.
------=_Part_116_50730238.1482019890476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 6:06:33 PM UTC-5, Arthur=
O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthew Woehlke w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">I'm soliciting comments on=
the attached draft proposal. At Jacksonville,
<br>it was suggested that the case for P0222 and P0224 would be stronger by
<br>combining the proposals; so this paper does that. One major change is
<br>that I now suggest `decltype(return)` as the marker for reusing the
<br>previously declared return type, which avoids some issues present in th=
e
<br>original proposal.
<br>
<br>Summary:
<br>
<br>- Remove the restriction on an anonymous type as a return value.
<br></blockquote><div><br></div><div>I was confused by this summary until I=
read the paper. The following kind of "anonymous type as return type&=
quot; is already fully supported in C++14:</div><div><br></div><div style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#000"> f</span><span style=3D"color:#660">()</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"> </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 style=3D"color:#0=
00"> x</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
y</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"> s</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span=
style=3D"color:#008">return</span><span style=3D"color:#000"> s</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></cod=
e></div><div><br></div><div>You're proposing to go beyond that, with</d=
iv><div><br></div><div style=3D"background-color:rgb(250,250,250);border:1p=
x solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"co=
lor:#008">struct</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">int</span><span style=3D"color:#000"> x</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> y</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"> f</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">???</span><span sty=
le=3D"color:#000"> s</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> s</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color=
:#000"><br></span></div></code></div><div><br></div><div>where you addition=
ally want-but-explicitly-do-not-<wbr>propose "decltype(return)" a=
s the appropriate syntax for "???".</div></div></blockquote><div>=
<br>Not really. The idea being that you'd just do `return {};`. You wou=
ld only need `decltype(return)` if you needed to declare a variable of the =
return type.<br><br>If you're using these anonymous structs as a way to=
do multiple return values without tuples, then you don't really need t=
he return type itself. So the proposal is genuinely useful independently of=
`decltype(return)` to fetch the function's return type.<br><br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div=
><div>I think this proposal adds <i>consistency</i> to the language, but do=
esn't add any functionality that working programmers should actually de=
sire.</div><div><br></div><div>The minor downside I saw immediately is that=
unique struct types (as declared anonymously in parameter types or return =
types) aren't terribly useful because they're never equivalent. Thi=
s is why I wouldn't want the feature showing up in the coding style of =
any codebase <i>I</i> worked on: I'd rather just give the class type a =
name.</div><div><br></div><div style=3D"background-color:rgb(250,250,250);b=
order:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span sty=
le=3D"color:#008">template</span><span style=3D"color:#660"><</span><spa=
n style=3D"color:#008">class</span><span style=3D"color:#000"> T</span><spa=
n style=3D"color:#660">></span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#008">auto</span><span style=3D"color:#000"> today</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">T t</span><sp=
an style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color:#008">struct</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">int</span><span style=3D"color:#000"> s</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"> result </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#008">sizeof</span><span sty=
le=3D"color:#000"> t</span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return<=
/span><span style=3D"color:#000"> result</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">templ=
ate</span><span style=3D"color:#660"><</span><span style=3D"color:#008">=
class</span><span style=3D"color:#000"> T</span><span style=3D"color:#660">=
></span><span 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 style=3D"color:#000"> s</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><sp=
an style=3D"color:#000"> tomorrow</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">T t</span><span style=3D"color:#660">)</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">retu=
rn</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</s=
pan><span style=3D"color:#008">sizeof</span><span style=3D"color:#000"> t</=
span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#008">int</span><span style=3D"color:#000"> main</sp=
an><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008">static_assert</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">std</span><span style=3D"color=
:#660">::</span><span style=3D"color:#000">is_same_v</span><span style=3D"c=
olor:#660"><</span><span style=3D"color:#008">d<wbr>ecltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">today</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#066">0</span><span style=
=3D"color:#660">)),</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">decltype</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">today</span><span style=3D"color:#660">(</span><span style=
=3D"color:#066">0.0</span><span style=3D"color:#660">))>,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#080">"Unfortunately t=
his assertion will fail"</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>static_assert</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:=
#000">is_same_v</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">d<wbr>ecltype</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">tomorrow</span><span style=3D"color:#660">(</span><span =
style=3D"color:#066">0</span><span style=3D"color:#660">)),</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">tomorrow</span><span=
style=3D"color:#660">(</span><span style=3D"color:#066">0.0</span><span st=
yle=3D"color:#660">))>,</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#080">"Unfortunately this assertion will fail"</spa=
n><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">}</span></div></code></div><div><br>The second,=
more important =E2=80=94 possibly killer? =E2=80=94 problem is also illust=
rated by the above program: what does the following declaration(?) actually=
declare?</div><div><br></div><div style=3D"background-color:rgb(250,250,25=
0);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span=
style=3D"color:#008">template</span><span style=3D"color:#660"><</span>=
<span style=3D"color:#008">class</span><span style=3D"color:#000"> T</span>=
<span style=3D"color:#660">></span><span 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"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#00=
0"> s</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br=
>tomorrow</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
0">T t</span><span style=3D"color:#660">)</span><span style=3D"color:#000">=
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#008">sizeof</span><span style=3D"color:#000"> t</span><span style=3D"col=
or:#660">};</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">}</span></div></code></div><div><br></div><div>All the way until th=
e first closing curly brace on line 4 =E2=80=94 i.e. all during the parsing=
of the struct body =E2=80=94 this <i>looks</i> like a class template defin=
ition.</div></div></blockquote><div><br>Does it? Because I'm <a href=3D=
"http://ideone.com/vRQusf">fairly certain that class templates cannot be de=
clared without a name</a>. That's not definitive; I wouldn't know w=
here to start looking through the standard for this. But I'm pretty sur=
e it can't happen; how would you instantiate one?<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It's only =
upon finding the final semicolon missing that we realize that it's actu=
ally a function template definition that contains a (non-template) class de=
finition buried inside it.</div><div><br></div><div>Do we already have this=
garden-path grammar anywhere else in the language? I suspect we do not, an=
d I (slightly more weakly) suspect that vendors will be unhappy with having=
to parse it.</div><div><br></div><div>=E2=80=93Arthur</div></div></blockqu=
ote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27525698-55a5-435f-89ca-d3b75260c4d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27525698-55a5-435f-89ca-d3b75260c4d2=
%40isocpp.org</a>.<br />
------=_Part_116_50730238.1482019890476--
------=_Part_115_1954490924.1482019890476--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 18 Dec 2016 10:01:23 +0100
Raw View
This is a multi-part message in MIME format.
--------------DEBE761EE2E812A02F30ABF3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/12/2016 =C3=A0 19:09, Matthew Woehlke a =C3=A9crit :
> I'm soliciting comments on the attached draft proposal. At Jacksonville,
> it was suggested that the case for P0222 and P0224 would be stronger by
> combining the proposals; so this paper does that. One major change is
> that I now suggest `decltype(return)` as the marker for reusing the
> previously declared return type, which avoids some issues present in the
> original proposal.
>
> Summary:
>
> - Remove the restriction on an anonymous type as a return value.
> - Add `decltype(return)` as a permitted return type specifier meaning
> 'the type as seen in a previous declaration of this overload'.
>
> This is NOT a general proposal for `decltype(return)` in function
> *bodies* (although I do hope someone will make such a proposal); only as
> the return type specifier.
>
> Please let me know what y'all think!
>
>
>
Hi,
while you refer to P0341 in your proposal, you don't describe the=20
differences of your proposal and Named Pack Types (which for me achieves=20
even more).
<string topSong, person president, double avgTemp>=20
someFactsAboutYear(int year) {
if(year=3D=3D1962) return {"Stranger On The Shore",=20
Presidents.get("Kennedy"), 14};
...
}
In other words, how is your proposal better than Named Pack Types?
IIUC the advantage of Named Pack Types respect to Unnamed Structs is=20
that we can define whether they are the same (the syntax of a Named Pack=20
Types is much more limited than a unnamed struct) without any backward=20
compatibility issues.
An alternative syntax for P0341 could be to use typename {...} instead=20
so that we can limit the syntax and define when two such types are the same=
..
typename {string topSong, person president, double avgTemp}=20
someFactsAboutYear(int year);
I agree that it would be nice to have a way to refer to this return=20
type. I will not be against your decltype(return) proposal and I believe=20
the other uses for decltype(return) in the body should be welcome as=20
well independently of this feature.
Vicente
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/78988e1a-76c9-78e9-90ed-4f1752a1aa9c%40wanadoo.f=
r.
--------------DEBE761EE2E812A02F30ABF3
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 16/12/2016 =C3=A0 19:09, Matthew Woeh=
lke
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:o31ak7$heq$1@blaine.gmane.org" type=3D"cite">
<pre wrap=3D"">I'm soliciting comments on the attached draft proposal=
.. At Jacksonville,
it was suggested that the case for P0222 and P0224 would be stronger by
combining the proposals; so this paper does that. One major change is
that I now suggest `decltype(return)` as the marker for reusing the
previously declared return type, which avoids some issues present in the
original proposal.
Summary:
- Remove the restriction on an anonymous type as a return value.
- Add `decltype(return)` as a permitted return type specifier meaning
'the type as seen in a previous declaration of this overload'.
This is NOT a general proposal for `decltype(return)` in function
*bodies* (although I do hope someone will make such a proposal); only as
the return type specifier.
Please let me know what y'all think!
</pre>
</blockquote>
<p><font size=3D"+1"><br>
</font></p>
<p><font size=3D"+1">Hi,<br>
<br>
while you refer to P0341 in your proposal, you don't describe
the differences of your proposal and Named Pack Types (which for
me achieves even more).<br>
<br>
<string topSong, person president, double avgTemp>
someFactsAboutYear(int year) {<br>
=C2=A0=C2=A0=C2=A0 if(year=3D=3D1962) return {"Stranger On The Shor=
e",
Presidents.get("Kennedy"), 14};<br>
=C2=A0=C2=A0=C2=A0 ...<br>
}<br>
</font></p>
<p><font size=3D"+1">In other words, how is your proposal better than
</font><font size=3D"+1"><font size=3D"+1">Named Pack Types?</font></=
font></p>
<p><font size=3D"+1">IIUC the advantage of Named Pack Types respect to
Unnamed Structs is that we can define whether they are the same
(the syntax of a Named Pack Types is much more limited than a
unnamed struct) without any backward compatibility issues.<br>
<br>
An alternative syntax for P0341 could be to use typename {...}
instead so that we can limit the syntax and define when two such
types are the same.<br>
<br>
=C2=A0=C2=A0=C2=A0 typename {string topSong, person president, doub=
le avgTemp}
someFactsAboutYear(int year);<br>
<br>
I agree that it would be nice to have a way to refer to this
return type. I will not be against your decltype(return)
proposal and I believe the other uses for decltype(return) in
the body should be welcome </font><font size=3D"+1"><font
size=3D"+1">as well </font>independently of this feature.<br>
</font></p>
<p><font size=3D"+1">Vicente</font><br>
</p>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/78988e1a-76c9-78e9-90ed-4f1752a1aa9c%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/78988e1a-76c9-78e9-90ed-4f1752a1aa9c=
%40wanadoo.fr</a>.<br />
--------------DEBE761EE2E812A02F30ABF3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 18 Dec 2016 06:52:39 -0800 (PST)
Raw View
------=_Part_551_724213931.1482072760044
Content-Type: multipart/alternative;
boundary="----=_Part_552_941151940.1482072760044"
------=_Part_552_941151940.1482072760044
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, December 18, 2016 at 4:02:05 AM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 16/12/2016 =C3=A0 19:09, Matthew Woehlke a =C3=A9crit :
>
> I'm soliciting comments on the attached draft proposal. At Jacksonville,
> it was suggested that the case for P0222 and P0224 would be stronger by
> combining the proposals; so this paper does that. One major change is
> that I now suggest `decltype(return)` as the marker for reusing the
> previously declared return type, which avoids some issues present in the
> original proposal.
>
> Summary:
>
> - Remove the restriction on an anonymous type as a return value.
> - Add `decltype(return)` as a permitted return type specifier meaning
> 'the type as seen in a previous declaration of this overload'.
>
> This is NOT a general proposal for `decltype(return)` in function
> *bodies* (although I do hope someone will make such a proposal); only as
> the return type specifier.
>
> Please let me know what y'all think!
>
>
>
>
>
> Hi,
>
> while you refer to P0341 in your proposal, you don't describe the=20
> differences of your proposal and Named Pack Types (which for me achieves=
=20
> even more).
>
> <string topSong, person president, double avgTemp> someFactsAboutYear(int=
=20
> year) {
> if(year=3D=3D1962) return {"Stranger On The Shore",=20
> Presidents.get("Kennedy"), 14};
> ...
> }
>
> In other words, how is your proposal better than Named Pack Types?
>
Because it doesn't require some major new syntax that creates a new=20
category of C++ entities?
P0341 is very... weak, as a proposal. It says kinda what it wants, but it=
=20
never explains the exact behavior of these "packs" that you can pass=20
around. By using actual C++ types, we completely understand what their C++=
=20
behavior will be. When objects are constructed, copied/moved, what happens=
=20
when you apply various operations on them, ABIs, etc. That's all very well=
=20
defined.
P0341 doesn't get very far in answering those questions.
Personally, I much prefer using actual types as the means of interchange=20
outside of functions. If you need to do pack operations on such a type, we=
=20
can provide that.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/55a6e55c-0095-4d03-a2ce-30d992cea439%40isocpp.or=
g.
------=_Part_552_941151940.1482072760044
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, December 18, 2016 at 4:02:05 AM UTC-5, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 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 16/12/2016 =C3=A0 19:09, Matthew Woehlke
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<pre>I'm soliciting comments on the attached draft proposal. At J=
acksonville,
it was suggested that the case for P0222 and P0224 would be stronger by
combining the proposals; so this paper does that. One major change is
that I now suggest `decltype(return)` as the marker for reusing the
previously declared return type, which avoids some issues present in the
original proposal.
Summary:
- Remove the restriction on an anonymous type as a return value.
- Add `decltype(return)` as a permitted return type specifier meaning
'the type as seen in a previous declaration of this overload'.
This is NOT a general proposal for `decltype(return)` in function
*bodies* (although I do hope someone will make such a proposal); only as
the return type specifier.
Please let me know what y'all think!
</pre>
</blockquote>
<p><font size=3D"+1"><br>
</font></p>
<p><font size=3D"+1">Hi,<br>
<br>
while you refer to P0341 in your proposal, you don't describe
the differences of your proposal and Named Pack Types (which for
me achieves even more).<br>
<br>
<string topSong, person president, double avgTemp>
someFactsAboutYear(int year) {<br>
=C2=A0=C2=A0=C2=A0 if(year=3D=3D1962) return {"Stranger On The=
Shore",
Presidents.get("Kennedy"), 14};<br>
=C2=A0=C2=A0=C2=A0 ...<br>
}<br>
</font></p>
<p><font size=3D"+1">In other words, how is your proposal better than
</font><font size=3D"+1"><font size=3D"+1">Named Pack Types?</font></=
font></p></div></blockquote><div><br>Because it doesn't require some ma=
jor new syntax that creates a new category of C++ entities?<br><br>P0341 is=
very... weak, as a proposal. It says kinda what it wants, but it never exp=
lains the exact behavior of these "packs" that you can pass aroun=
d. By using actual C++ types, we completely understand what their C++ behav=
ior will be. When objects are constructed, copied/moved, what happens when =
you apply various operations on them, ABIs, etc. That's all very well d=
efined.<br><br>P0341 doesn't get very far in answering those questions.=
<br><br>Personally, I much prefer using actual types as the means of interc=
hange outside of functions. If you need to do pack operations on such a typ=
e, we can provide that.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/55a6e55c-0095-4d03-a2ce-30d992cea439%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55a6e55c-0095-4d03-a2ce-30d992cea439=
%40isocpp.org</a>.<br />
------=_Part_552_941151940.1482072760044--
------=_Part_551_724213931.1482072760044--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 11:09:45 -0500
Raw View
On 2016-12-17 18:06, Arthur O'Dwyer wrote:
> On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthew Woehlke wrote=
:
>>
>> I'm soliciting comments on the attached draft proposal. At Jacksonville,=
=20
>> it was suggested that the case for P0222 and P0224 would be stronger by=
=20
>> combining the proposals; so this paper does that. One major change is=20
>> that I now suggest `decltype(return)` as the marker for reusing the=20
>> previously declared return type, which avoids some issues present in the=
=20
>> original proposal.=20
>>
>> Summary:=20
>>
>> - Remove the restriction on an anonymous type as a return value.=20
>=20
> I was confused by this summary until I read the paper. The following kind=
=20
> of "anonymous type as return type" is already fully supported in C++14:
>=20
> auto f() { struct { int x, y; } s; return s; }
I did not realize that. That seems to me even better reason to lift the
restriction. I'll add that to the paper. Thanks!
> You're proposing to go beyond that, with
>=20
> struct { int x, y; } f() { ??? s; return s; }
Right.
> where you additionally want-but-explicitly-do-not-propose=20
> "decltype(return)" as the appropriate syntax for "???".
Um... it's *meant* to be explicitly proposed. Can you please clarify why
you think I haven't done so, so I can fix it?
> I think this proposal adds *consistency* to the language, but doesn't add=
=20
> any functionality that working programmers should actually desire.
The added function is to be able to do things like:
// foo.h
struct { ... } // really don't want to have to name this
my_func(...); // note ';', this is a declaration, not a definition!
really_long_typename<that, I<do_not_want_to_repeat>>
my_other_func(...);
The intent is to allow "multiple return values" where the individual
values have names, but the aggregate type does not. There seem to be a
fair number of folks that want this, e.g. see also N4560 and P0341.
(Especially, I really want *this* rather than what P0341 proposes.)
> The second, more important =E2=80=94 possibly killer? =E2=80=94 problem i=
s also illustrated=20
> by the above program: what does the following declaration(?) actually=20
> declare?
>=20
> template<class T>
> struct {
> int s;
> }
> tomorrow(T t) {
> return {sizeof t};
> }
>=20
> All the way until the first closing curly brace on line 4 =E2=80=94 i.e. =
all during=20
> the parsing of the struct body =E2=80=94 this *looks* like a class templa=
te=20
> definition. It's only upon finding the final semicolon missing that we=20
> realize that it's actually a function template definition that contains a=
=20
> (non-template) class definition buried inside it.
I see. Maybe the feature should only work with non-template functions?
That would still be an improvement, and doesn't stop us deciding later
to allow it with templates also.
--=20
Matthew
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58580649.7020603%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 11:19:39 -0500
Raw View
On 2016-12-17 19:11, Nicol Bolas wrote:
> On Saturday, December 17, 2016 at 6:06:33 PM UTC-5, Arthur O'Dwyer wrote:
>>
>> On Saturday, December 17, 2016 at 5:38:20 AM UTC-8, Matthew Woehlke wrot=
e:
>>>
>>> I'm soliciting comments on the attached draft proposal. At Jacksonville=
,=20
>>> it was suggested that the case for P0222 and P0224 would be stronger by=
=20
>>> combining the proposals; so this paper does that. One major change is=
=20
>>> that I now suggest `decltype(return)` as the marker for reusing the=20
>>> previously declared return type, which avoids some issues present in th=
e=20
>>> original proposal.=20
>>>
>>> Summary:=20
>>>
>>> - Remove the restriction on an anonymous type as a return value.=20
>>>
>>
>> I was confused by this summary until I read the paper. The following kin=
d=20
>> of "anonymous type as return type" is already fully supported in C++14:
>>
>> auto f() { struct { int x, y; } s; return s; }
>>
>> You're proposing to go beyond that, with
>>
>> struct { int x, y; } f() { ??? s; return s; }
>>
>> where you additionally want-but-explicitly-do-not-propose=20
>> "decltype(return)" as the appropriate syntax for "???".
>=20
> Not really. The idea being that you'd just do `return {};`. You would onl=
y=20
> need `decltype(return)` if you needed to declare a variable of the return=
=20
> type.
Er... no? In fact, I don't propose that flavor of `decltype(return)`.
The flavor I *do* propose is:
struct { ... } foo(...);
decltype(return) foo(...)
{
...
}
This is fairly important, since otherwise it is very awkward to define
the previously declared function.
This case isn't too bad:
struct { ... } foo();
decltype(foo()) foo() { ... }
....but it gets worse quickly when `foo` has parameters.
Per Arthur's "how we can do this already" note, I especially care about
forward declared functions.
>> The second, more important =E2=80=94 possibly killer? =E2=80=94 problem =
is also=20
>> illustrated by the above program: what does the following declaration(?)=
=20
>> actually declare?
>>
>> template<class T>
>> struct {
>> int s;
>> }
>> tomorrow(T t) {
>> return {sizeof t};
>> }
>>
>> All the way until the first closing curly brace on line 4 =E2=80=94 i.e.=
all=20
>> during the parsing of the struct body =E2=80=94 this *looks* like a clas=
s=20
>> template definition.
>=20
> Does it? Because I'm fairly certain that class templates cannot be declar=
ed=20
> without a name <http://ideone.com/vRQusf>. That's not definitive; I=20
> wouldn't know where to start looking through the standard for this. But I=
'm=20
> pretty sure it can't happen; how would you instantiate one?
Even so, the compiler has to parse the entire type definition before it
knows it isn't looking at a templated type. I'm adding a discussion
point to the effect I'm okay relaxing the prohibition only for
non-template functions, or at least unless using trailing return type:
// Much easier to parse
template <...> auto foo -> struct { ... }
{
...
}
--=20
Matthew
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5858089B.4020009%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 11:42:48 -0500
Raw View
On 2016-12-17 20:10, Arthur O'Dwyer wrote:
> Matthew 's proposal makes it this:
>
> struct { } f1() { return {}; } // OK in proposal
Right; this is the intent.
> struct S { } f2() { return {}; } // UNKNOWN in proposal: presumably should
> declare both S and f2
The original intent was to simply strike the [dcl.fct]/11 prohibition,
in which case I believe it logically follows that the above a) is
permitted and b) does indeed declare both `S` and `f2`.
This is exactly how MSVC *already works*.
> template<class T> struct S { } vt2; // ERROR in C++14: definition of S<T>
> can't also declare vt2
Riiiight... particularly, `vt2` would have to be a template here, or
else you'd somehow need an argument list.
> template<class T> struct { } ft1(); // ERROR in C++98: a template must
> have a name, and can't also declare ft1
> template<class T> struct S { } ft2(); // ERROR in C++98: definition of
> S<T> can't also declare ft2
The "sensible" thing here would be for the function to be templated, and
the return type not. However, I agree this is a strange edge case. I
think I would like to bring this to the committee for discussion. I am
fine for now prohibiting this case.
An alternative would be to express it in a non-ambiguous manner:
template <class T> auto ft1() -> struct {};
This could be allowed while forbidding the expression as in your above
examples. But I am okay retaining the prohibition for templated functions.
> The proposal should explicitly cover the "f2" case above; and if the intent
> is to support that case, then it should maybe not make such a big deal
> about "anonymous" types. The real issue here is just whether C++ should
> permit defining a new class type in the same declaration as various other
> kinds of entities (variables and typedefs yes, functions currently no). I
> think it would be a bad idea to support such declarations *only* when the
> new class type is anonymous.
I think that's a fair point; thanks! I've updated the paper accordingly.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58580E08.90802%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 12:02:58 -0500
Raw View
On 2016-12-18 04:01, Vicente J. Botet Escriba wrote:
> while you refer to P0341 in your proposal, you don't describe the
> differences of your proposal and Named Pack Types (which for me achieves
> even more).
>
> <string topSong, person president, double avgTemp>
> someFactsAboutYear(int year) {
> if(year==1962) return {"Stranger On The Shore",
> Presidents.get("Kennedy"), 14};
> ...
> }
>
> In other words, how is your proposal better than Named Pack Types?
It's probably less *directly useful* than named pack types. However,
named pack types are a very complicated feature. They introduce
returning packs from functions, which is complicated. They introduce the
concept of names associated with parameter packs, which... I'm not even
sure what that means?
How do I accept the return value of the above function? Can I apply S.B.
to it? How do I use the names of the pack values?
By contrast, anonymous structs solve the same problems without inventing
new language concepts:
struct { string topSong; person president; double avgTemp; }
someFactsAboutYear(int year) {
if(year==1962) return {"Stranger On The Shore",
Presidents.get("Kennedy"), 14};
...
}
Here, it's obvious that the return value is just an aggregate type. I
can assign it to an `auto` variable, copy it, use S.B. on it, or use
`result.avgTemp` to get an individual value. No new, exotic language
features are involved, and indeed I can even *compile this program
today* (albeit only on MSVC).
Now I'll ask the opposite question: how is P0341 better than this (plus
generalized unpacking)?
On 2016-12-18 09:52, Nicol Bolas wrote:
> Personally, I much prefer using actual types as the means of interchange
> outside of functions. If you need to do pack operations on such a type, we
> can provide that.
Strongly agreed, on both points. (And, oh, look, I have a proposal for
that second point... I will try to post it today.)
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/585812C2.2030603%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 15:04:35 -0500
Raw View
This is a multi-part message in MIME format.
--------------050900060409010603020009
Content-Type: text/plain; charset=UTF-8
On 2016-12-16 13:09, Matthew Woehlke wrote:
> I'm soliciting comments on the attached draft proposal.
>
> Summary:
>
> - Remove the restriction on an anonymous type as a return value.
> - Add `decltype(return)` as a permitted return type specifier meaning
> 'the type as seen in a previous declaration of this overload'.
Updated version attached. Thanks all for the feedback so far!
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58583D53.7060803%40gmail.com.
--------------050900060409010603020009
Content-Type: text/prs.fallenstein.rst;
name="dxxxx-implicit-return-and-anonymous-structs.rst"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="dxxxx-implicit-return-and-anonymous-structs.rst"
======================================================================
Implicit Return Type and Allowing Anonymous Types as Return Values
======================================================================
:Document: DXXXXR0
:Date: 2016-12-19
:Project: ISO/IEC JTC1 SC22 WG21 Programming Language C++
:Audience: Evolution Working Group
:Author: Matthew Woehlke (mwoehlke.floss@gmail.com)
... raw:: html
<style>
html { color: black; background: white; }
table.docinfo { margin: 2em 0; }
</style>
... role:: cpp(code)
:language: c++
Abstract
========
This proposal recommends the relaxing of [dcl.fct]/11; specifically, the prohibition of defining (anonymous) types as return values, and adding a mechanism that simplifies naming the return type of a previously declared function. These features were previously proposed separately, as P0222_ and P0224_.
... contents::
Rationale
=========
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 virtue of the returned values being unnamed, forcing developers to rely on supplemental 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 corresponding namespace with entities that may be single use. Proposals such as N4560_ present a complicated mechanism for providing tagged (self-documenting) tuple-like types, which may be necessary in some cases, but still represent a non-trivial amount of complexity that ideally should not be req
uired. P0341_ presents a similar idea with tagged parameter packs as return values.
The addition of "structured bindings" in C++17 in particular represents a significant step toward support of multiple return values as first class citizens. This feature, along with other ongoing efforts to add first class support for "product types" and other efforts such as P0341_ 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 the standard template library types will remain useful for algorithms where the identity of the elements is unimportant, while it *is* important to be 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, as a
lso suggested in P0197_.)
On their own, however, these directions risk exacerbating the problem that this proposal aims to address. In particular, a concern with the notion of returning a parameter pack, as presented in P0341_, opens a potential ABI can of worms. Moreover, parameter packs are not true types, and are subject to significant limitations, such as inability to make copies or pass them around as single entities, which are not shared by regular compound types. With generalized unpacking (\ FIXME_), product types and parameter packs are effectively interchangeable, and returning a product type rather than a parameter pack leverages existing ABI and techniques, rather than introducing something entirely novel. The remaining issue is one of naming; naming things |--| in this case, return types, especially fo
r one-off functions |--| is *hard*.
It has been suggested on multiple occasions that the optimal solution to the above issues is to return an anonymous ``struct``. This solves the problems of clutter and self-documentation, but runs afoul of a much worse issue; because the ``struct`` is *anonymous*, it can be difficult to impossible to give its name a second time in order to separate the declaration and definition of the function that wishes to use it. This, however, leads to a more interesting question: **why is it necessary to repeat the return value at all?**
Even in the case of return types that can be named, it may be that repeating the type name is excessively verbose or otherwise undesirable. Some might even call this a violation of the `Don't Repeat Yourself <https://en.wikipedia.org/wiki/Don't_repeat_yourself>`_ principle, similar to some of the issues that ``auto`` for variable declaration was introduced to solve. (On the flip side, one could see the ability to elide the return type as subject to many abuses, again in much the manner of ``auto``. However, many language features can be abused; this should not prevent the addition of a feature that would provide an important benefit when used correctly.)
While it is already possible in simple cases to use :cpp:`decltype` and a sample invocation of the function, this is needlessly verbose, and as the argument list grows longer and/or gains arguments for which providing a legal value is non-trivial, it can quickly become unwieldy and unfeasible.
While both these features have use on their own, they are nevertheless related, and we believe that presenting them together makes sense, and strengthens the case for each.
Proposal
========
We propose, first, to remove the restriction against (anonymous) types as return values:
... code:: c++
struct { int id; double value; } foo() { ... }
We believe this can be accomplished largely by simply removing the prohibition in [dcl.fct]/11.
Second, we propose the addition of :cpp:`decltype(return)` to name |--| in a function signature |--| the return type of a previously declared function. This is consistent with recent changes to the language that have progressively relaxed the requirements for how return types are specified, and provides an optimal solution to the following problem:
... code:: c++
// foo.h
struct { int id; double value; } foo();
How does one now provide an external definition for ``foo()``? With our proposal, the solution is simple:
... code:: c++
// foo.cpp
decltype(return) foo()
{
...
return { id, value };
}
Naturally, "previous declared" here means a declaration having the same name and argument list. This, for example, would remain illegal:
... code:: c++
int foo(int);
float foo(float);
decltype(return) foo(double input) // does not match any previous declaration
{
...
return result;
}
The reasons to prohibit an anonymous struct defined as a return type have also been significantly mitigated. Constructing the return result is a non-issue, since the type name may now be elided, and the combination of :cpp:`auto` variable declarations, :cpp:`decltype`, and the proposed mechanism for naming the return type in a function signature permit implicit naming of the type where necessary. In short, the prohibition ([dcl.fct]/11) against defining types in return type specifications has become largely an artificial and arbitrary restriction which we propose to remove.
We additionally note that this prohibition is already not enforced by at least one major compiler (MSVC), and is enforced sporadically in others (see `What about defining types in function pointer types?`_).
Interactions
============
Definition of a class-type as a return value type is currently ill-formed (although not universally enforced by existing major compilers), and the token sequence :cpp:`decltype(return)` is currently ill-formed. Accordingly, this change will not affect existing and conforming code, and may cause existing but non-conforming code to become conforming. This proposal does not make any changes to other existing language or library features; while conceivable that some library methods might benefit from the feature, such changes are potentially breaking, and no such changes are proposed at this time.
Implementation and Existing Practice
====================================
The proposed feature to allow types as return values is at least already partly implemented by MSVC and (to a lesser extend) GCC and ICC. The curious, partial support in GCC and ICC (see `What about defining types in function pointer types?`_) suggests that the existing prohibition may already be largely artificial, and that removing it would accordingly be a simple matter.
The proposed feature to allow :cpp:`decltype(return)` to name the return value has not, to our knowledge, been implemented, but given that compilers must already compare the return value when confronted with an initial declaration followed by subsequent redeclarations and/or a definition, we do not anticipate any implementation difficulties.
Discussion
==========
Can't we do this already?
-------------------------
Astute observers may note that this is already legal (as of C++14):
... code:: c++
auto f()
{
struct { int x, y; } result;
// set values of result
return result;
}
The critical problem with this, which we wish specifically to address, is that a forward declaration of such a function is not possible. We would see this as further justification for relaxing the existing prohibition, as proposed.
Should we allow *named* types defined as return types?
------------------------------------------------------
Allowing both named and anonymous types is a logical consequence of simply lifting the existing [dcl.fct]/11 prohibition as it is currently stated. It is also consistent, and already supported by MSVC:
... code:: c++
// Equivalent to struct S { ... }; S foo();
struct S { ... } foo();
That said, the value here is less obvious, and we would find it acceptable to permit definition of only anonymous types as return types.
Isn't template parsing difficult?
---------------------------------
Arthur O'Dwyer pointed out this interesting example:
... code:: c++
template<class T>
struct {
size_t s;
} // Declaring a templated type, right?
what_size(T t) {
return {sizeof(t)};
}
It isn't obvious to the compiler, and not especially obvious to readers either, that this is a declaration of a templated function returning an anonymous type. Moreover, while the type itself is not templated, per-se, in effect it is, because (presumably?) each different instantiation of the function will have a distinct return type.
Since the primary motivation for this feature is for forward declarations of functions (per previous question, returning anonymous types is already possible with deduced return type), there are fewer use cases for the feature in conjunction with templated functions. As such, an easy cop-out is to retain the prohibition in these cases; we can always decide to lift it later.
An alternative (which may be worth considering for all cases) is to permit anonymous types only in trailing return type specifications, as follows:
... code:: c++
auto foo -> struct { ... };
template<...> auto bar -> struct { ... };
Is :cpp:`decltype(return)` dangerous?
-------------------------------------
P0224_ previously recommended overloading :cpp:`auto` as a mechanism for implicitly naming the return type given a prior declaration. While we believe this approach is feasible, there were some potential issues, which are discussed in P0224_. While we would happily accept the solution proposed by P0224_, we feel that :cpp:`decltype(return)` is less ambiguous, both to readers and to compilers. It is slightly more verbose than :cpp:`auto`, but not so much that we feel the added verbosity is an issue in those cases where we expect it to be used, and the extra verbosity may serve to deter "frivolous" use. Particularly, there is a clear distinction between inferred return values (the traditional use of :cpp:`auto` as a return type) and "implied" return values (that is, the use of :cpp:`decltype
(return)` as an alternate spelling of a previously declared return type).
What about defining types in function pointer types?
----------------------------------------------------
An obvious consequence of relaxing [dcl.fct]/11 is the desire to permit function pointers which return an anonymous struct. For example:
... code:: c++
// Declare a function pointer type which returns an anonymous struct
using ReturnsAnonymousStruct = 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 = 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 above. (In fact, this example is already accepted by both GCC and ICC, although it is rejected by clang per [dcl.fct]/11.) Accordingly, we feel that this proposal should be understood as intending to 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 against types defined in parameter specifications? There have been suggestions 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 that this is not an optimal solution to the problem (named parameters) in the first place. Second, it depends on named initializers, which is an area of ongoing work. Third, this proposal works largely because C++ forbids overloading on return type, which may be leveraged to eliminate any ambiguity as to the deduction of the actual type of :cpp:`decltype(return)`. This is not the case for parameters; the ability to overload function
s would make a similar change for parameters much more complicated.
While we do not wish to categorically rule out future changes in this direction, we feel that it is not appropriate for this proposal to attempt to address these issues.
What about "pass-through" of return values having equivalent types?
-------------------------------------------------------------------
Another question that has come up is if something like this should be allowed:
... code:: c++
struct { int result; } foo() { ... }
struct { int result; } bar()
{
return foo();
}
Specifically, others have expressed an interest in treating layout-compatible types as equivalent (or at least, implicitly convertible), particularly in the context of return values as in the above example.
Under the current rules (plus relaxed [dcl.fct]/11), these two definitions have different return types which are not convertible. It is our opinion that the rules making these types different are in fact correct and desirable, and this proposal specifically does *not* include any changes which would make the types compatible. That said, we note that FIXME_ provides a ready solution to this problem:
... code:: c++
struct { int result; } bar()
{
return { [:]foo()... };
}
Does this conflicts with future "true" multiple return values?
--------------------------------------------------------------
There has been some discussion of "true" multiple return values, in particular with respect to RVO and similar issues. In particular, some features proposed by P0341_ are very much in this vein. A point that bears consideration is if moving down the path of using anonymous (or not) structs for multiple return values will "paint us into a corner" where future optimization potential is prematurely eliminated.
It is our hope that these issues can be addressed with existing compound types (which will have further reaching benefit). Moreover, as previously stated, the use of compound types for multiple return values uses existing techniques and is well understood, whereas introducing "first class" multiple return values introduces questions of ABI and other issues.
What about deduced return types?
--------------------------------
This feature is not compatible with deduced return types at this time. In light of P0329_, it might be possible to lift this restriction:
... code:: c++
auto foo()
{
return { .x = 3, .y = 2 }; // deduce: struct { int x, y; }
}
However, we have reservations about allowing this, and do not at this time propose that this example would be well-formed.
Future Directions
=================
In the Discussion_ section above, we presented a utility for extracting the return type from a function pointer type. The facility as presented has significant limitations; namely, it does not work on member functions and the several variations (e.g. CV-qualification) which apply to the same. We do not here propose a standard library implementation of this facility, 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::reference_wrapper`` can be used to similar effect... on *some* compilers. However, imperfect portability and the disparity between intended function and use for this result suggest that this is not the optimal facility for t
he problem.)
Another consideration that seems likely to come up is if we should further simplify the syntax for returning multiple values (conceivably, this could apply to both anonymous structs and to ``std::pair`` / ``std::tuple``). Some have suggested allowing that the ``struct`` keyword may be omitted. In light of P0151_ and P0341_, we can conceive that allowing the syntax ``<int x, double y> foo()`` might be interesting (in contrast to P0341_, we would suggest that this be shorthand for :cpp:`std::tuple`). At this time, we prefer to focus on the feature here presented rather than risk overextending the reach of this proposal. However, if this proposal is accepted, it represents an obvious first step to considering such features in the future.
A final consideration is the extension of :cpp:`decltype(return)` to allow use within a function body. At the time of writing, we are not aware of a proposal to do so, although the idea has been floated on numerous occasions. We would hope to see such an addition, which can be orthogonal to this proposal, in the near future.
Acknowledgments
===============
We wish to thank everyone on the ``std-proposals`` forum, especially Bengt Gustafsson, Arthur O'Dwyer and R. "Tim" Song, for their valuable feedback and insights.
References
==========
... _N4618: http://wg21.link/n4618
* N4618_ Working Draft, Standard for Programming Language C++
http://wg21.link/n4618
... _N4560: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4560.pdf
* N4560_ Extensions for Ranges
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4560.pdf
... _P0151: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0151r0.pdf
* P0151_ Proposal of Multi-Declarators (aka Structured Bindings)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0151r0.pdf
... _P0197: http://wg21.link/p0197
* P0197_ Default Tuple-like Access
http://wg21.link/p0197
... _P0222: http://wg21.link/p0222
* P0222_ Allowing Anonymous Structs as Return Values
http://wg21.link/p0224
... _P0224: http://wg21.link/p0224
* P0224_ Implicit Return Type
http://wg21.link/p0224
... _P0329: http://wg21.link/p0329
* P0329_ Designated Initializer Wording
http://wg21.link/p0329
... _P0341: http://wg21.link/p0341
* P0341_ Parameter Packs Outside of Templates
http://wg21.link/p0341
... FIXME link to gen-unpack
... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
... |--| unicode:: U+02014 .. em dash
... kate: hl reStructuredText
--------------050900060409010603020009
Content-Type: text/html; charset=UTF-8;
name="dxxxx-implicit-return-and-anonymous-structs.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="dxxxx-implicit-return-and-anonymous-structs.html"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiID8+CjwhRE9DVFlQRSBodG1s
IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRw
Oi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4K
PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJl
biIgbGFuZz0iZW4iPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+CjxtZXRhIG5hbWU9ImdlbmVy
YXRvciIgY29udGVudD0iRG9jdXRpbHMgMC4xMjogaHR0cDovL2RvY3V0aWxzLnNvdXJjZWZv
cmdlLm5ldC8iIC8+Cjx0aXRsZT5JbXBsaWNpdCBSZXR1cm4gVHlwZSBhbmQgQWxsb3dpbmcg
QW5vbnltb3VzIFR5cGVzIGFzIFJldHVybiBWYWx1ZXM8L3RpdGxlPgo8bWV0YSBuYW1lPSJk
YXRlIiBjb250ZW50PSIyMDE2LTEyLTE5IiAvPgo8bWV0YSBuYW1lPSJhdXRob3IiIGNvbnRl
bnQ9Ik1hdHRoZXcgV29laGxrZSAobXdvZWhsa2UuZmxvc3MmIzY0O2dtYWlsLmNvbSkiIC8+
CjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CgovKgo6QXV0aG9yOiBEYXZpZCBHb29kZ2VyIChn
b29kZ2VyQHB5dGhvbi5vcmcpCjpJZDogJElkOiBodG1sNGNzczEuY3NzIDc2MTQgMjAxMy0w
Mi0yMSAxNTo1NTo1MVogbWlsZGUgJAo6Q29weXJpZ2h0OiBUaGlzIHN0eWxlc2hlZXQgaGFz
IGJlZW4gcGxhY2VkIGluIHRoZSBwdWJsaWMgZG9tYWluLgoKRGVmYXVsdCBjYXNjYWRpbmcg
c3R5bGUgc2hlZXQgZm9yIHRoZSBIVE1MIG91dHB1dCBvZiBEb2N1dGlscy4KClNlZSBodHRw
Oi8vZG9jdXRpbHMuc2YubmV0L2RvY3MvaG93dG8vaHRtbC1zdHlsZXNoZWV0cy5odG1sIGZv
ciBob3cgdG8KY3VzdG9taXplIHRoaXMgc3R5bGUgc2hlZXQuCiovCgovKiB1c2VkIHRvIHJl
bW92ZSBib3JkZXJzIGZyb20gdGFibGVzIGFuZCBpbWFnZXMgKi8KLmJvcmRlcmxlc3MsIHRh
YmxlLmJvcmRlcmxlc3MgdGQsIHRhYmxlLmJvcmRlcmxlc3MgdGggewogIGJvcmRlcjogMCB9
Cgp0YWJsZS5ib3JkZXJsZXNzIHRkLCB0YWJsZS5ib3JkZXJsZXNzIHRoIHsKICAvKiBPdmVy
cmlkZSBwYWRkaW5nIGZvciAidGFibGUuZG9jdXRpbHMgdGQiIHdpdGggIiEgaW1wb3J0YW50
Ii4KICAgICBUaGUgcmlnaHQgcGFkZGluZyBzZXBhcmF0ZXMgdGhlIHRhYmxlIGNlbGxzLiAq
LwogIHBhZGRpbmc6IDAgMC41ZW0gMCAwICEgaW1wb3J0YW50IH0KCi5maXJzdCB7CiAgLyog
T3ZlcnJpZGUgbW9yZSBzcGVjaWZpYyBtYXJnaW4gc3R5bGVzIHdpdGggIiEgaW1wb3J0YW50
Ii4gKi8KICBtYXJnaW4tdG9wOiAwICEgaW1wb3J0YW50IH0KCi5sYXN0LCAud2l0aC1zdWJ0
aXRsZSB7CiAgbWFyZ2luLWJvdHRvbTogMCAhIGltcG9ydGFudCB9CgouaGlkZGVuIHsKICBk
aXNwbGF5OiBub25lIH0KCmEudG9jLWJhY2tyZWYgewogIHRleHQtZGVjb3JhdGlvbjogbm9u
ZSA7CiAgY29sb3I6IGJsYWNrIH0KCmJsb2NrcXVvdGUuZXBpZ3JhcGggewogIG1hcmdpbjog
MmVtIDVlbSA7IH0KCmRsLmRvY3V0aWxzIGRkIHsKICBtYXJnaW4tYm90dG9tOiAwLjVlbSB9
CgpvYmplY3RbdHlwZT0iaW1hZ2Uvc3ZnK3htbCJdLCBvYmplY3RbdHlwZT0iYXBwbGljYXRp
b24veC1zaG9ja3dhdmUtZmxhc2giXSB7CiAgb3ZlcmZsb3c6IGhpZGRlbjsKfQoKLyogVW5j
b21tZW50IChhbmQgcmVtb3ZlIHRoaXMgdGV4dCEpIHRvIGdldCBib2xkLWZhY2VkIGRlZmlu
aXRpb24gbGlzdCB0ZXJtcwpkbC5kb2N1dGlscyBkdCB7CiAgZm9udC13ZWlnaHQ6IGJvbGQg
fQoqLwoKZGl2LmFic3RyYWN0IHsKICBtYXJnaW46IDJlbSA1ZW0gfQoKZGl2LmFic3RyYWN0
IHAudG9waWMtdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICB0ZXh0LWFsaWduOiBj
ZW50ZXIgfQoKZGl2LmFkbW9uaXRpb24sIGRpdi5hdHRlbnRpb24sIGRpdi5jYXV0aW9uLCBk
aXYuZGFuZ2VyLCBkaXYuZXJyb3IsCmRpdi5oaW50LCBkaXYuaW1wb3J0YW50LCBkaXYubm90
ZSwgZGl2LnRpcCwgZGl2Lndhcm5pbmcgewogIG1hcmdpbjogMmVtIDsKICBib3JkZXI6IG1l
ZGl1bSBvdXRzZXQgOwogIHBhZGRpbmc6IDFlbSB9CgpkaXYuYWRtb25pdGlvbiBwLmFkbW9u
aXRpb24tdGl0bGUsIGRpdi5oaW50IHAuYWRtb25pdGlvbi10aXRsZSwKZGl2LmltcG9ydGFu
dCBwLmFkbW9uaXRpb24tdGl0bGUsIGRpdi5ub3RlIHAuYWRtb25pdGlvbi10aXRsZSwKZGl2
LnRpcCBwLmFkbW9uaXRpb24tdGl0bGUgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICBmb250
LWZhbWlseTogc2Fucy1zZXJpZiB9CgpkaXYuYXR0ZW50aW9uIHAuYWRtb25pdGlvbi10aXRs
ZSwgZGl2LmNhdXRpb24gcC5hZG1vbml0aW9uLXRpdGxlLApkaXYuZGFuZ2VyIHAuYWRtb25p
dGlvbi10aXRsZSwgZGl2LmVycm9yIHAuYWRtb25pdGlvbi10aXRsZSwKZGl2Lndhcm5pbmcg
cC5hZG1vbml0aW9uLXRpdGxlLCAuY29kZSAuZXJyb3IgewogIGNvbG9yOiByZWQgOwogIGZv
bnQtd2VpZ2h0OiBib2xkIDsKICBmb250LWZhbWlseTogc2Fucy1zZXJpZiB9CgovKiBVbmNv
bW1lbnQgKGFuZCByZW1vdmUgdGhpcyB0ZXh0ISkgdG8gZ2V0IHJlZHVjZWQgdmVydGljYWwg
c3BhY2UgaW4KICAgY29tcG91bmQgcGFyYWdyYXBocy4KZGl2LmNvbXBvdW5kIC5jb21wb3Vu
ZC1maXJzdCwgZGl2LmNvbXBvdW5kIC5jb21wb3VuZC1taWRkbGUgewogIG1hcmdpbi1ib3R0
b206IDAuNWVtIH0KCmRpdi5jb21wb3VuZCAuY29tcG91bmQtbGFzdCwgZGl2LmNvbXBvdW5k
IC5jb21wb3VuZC1taWRkbGUgewogIG1hcmdpbi10b3A6IDAuNWVtIH0KKi8KCmRpdi5kZWRp
Y2F0aW9uIHsKICBtYXJnaW46IDJlbSA1ZW0gOwogIHRleHQtYWxpZ246IGNlbnRlciA7CiAg
Zm9udC1zdHlsZTogaXRhbGljIH0KCmRpdi5kZWRpY2F0aW9uIHAudG9waWMtdGl0bGUgewog
IGZvbnQtd2VpZ2h0OiBib2xkIDsKICBmb250LXN0eWxlOiBub3JtYWwgfQoKZGl2LmZpZ3Vy
ZSB7CiAgbWFyZ2luLWxlZnQ6IDJlbSA7CiAgbWFyZ2luLXJpZ2h0OiAyZW0gfQoKZGl2LmZv
b3RlciwgZGl2LmhlYWRlciB7CiAgY2xlYXI6IGJvdGg7CiAgZm9udC1zaXplOiBzbWFsbGVy
IH0KCmRpdi5saW5lLWJsb2NrIHsKICBkaXNwbGF5OiBibG9jayA7CiAgbWFyZ2luLXRvcDog
MWVtIDsKICBtYXJnaW4tYm90dG9tOiAxZW0gfQoKZGl2LmxpbmUtYmxvY2sgZGl2LmxpbmUt
YmxvY2sgewogIG1hcmdpbi10b3A6IDAgOwogIG1hcmdpbi1ib3R0b206IDAgOwogIG1hcmdp
bi1sZWZ0OiAxLjVlbSB9CgpkaXYuc2lkZWJhciB7CiAgbWFyZ2luOiAwIDAgMC41ZW0gMWVt
IDsKICBib3JkZXI6IG1lZGl1bSBvdXRzZXQgOwogIHBhZGRpbmc6IDFlbSA7CiAgYmFja2dy
b3VuZC1jb2xvcjogI2ZmZmZlZSA7CiAgd2lkdGg6IDQwJSA7CiAgZmxvYXQ6IHJpZ2h0IDsK
ICBjbGVhcjogcmlnaHQgfQoKZGl2LnNpZGViYXIgcC5ydWJyaWMgewogIGZvbnQtZmFtaWx5
OiBzYW5zLXNlcmlmIDsKICBmb250LXNpemU6IG1lZGl1bSB9CgpkaXYuc3lzdGVtLW1lc3Nh
Z2VzIHsKICBtYXJnaW46IDVlbSB9CgpkaXYuc3lzdGVtLW1lc3NhZ2VzIGgxIHsKICBjb2xv
cjogcmVkIH0KCmRpdi5zeXN0ZW0tbWVzc2FnZSB7CiAgYm9yZGVyOiBtZWRpdW0gb3V0c2V0
IDsKICBwYWRkaW5nOiAxZW0gfQoKZGl2LnN5c3RlbS1tZXNzYWdlIHAuc3lzdGVtLW1lc3Nh
Z2UtdGl0bGUgewogIGNvbG9yOiByZWQgOwogIGZvbnQtd2VpZ2h0OiBib2xkIH0KCmRpdi50
b3BpYyB7CiAgbWFyZ2luOiAyZW0gfQoKaDEuc2VjdGlvbi1zdWJ0aXRsZSwgaDIuc2VjdGlv
bi1zdWJ0aXRsZSwgaDMuc2VjdGlvbi1zdWJ0aXRsZSwKaDQuc2VjdGlvbi1zdWJ0aXRsZSwg
aDUuc2VjdGlvbi1zdWJ0aXRsZSwgaDYuc2VjdGlvbi1zdWJ0aXRsZSB7CiAgbWFyZ2luLXRv
cDogMC40ZW0gfQoKaDEudGl0bGUgewogIHRleHQtYWxpZ246IGNlbnRlciB9CgpoMi5zdWJ0
aXRsZSB7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0KCmhyLmRvY3V0aWxzIHsKICB3aWR0aDog
NzUlIH0KCmltZy5hbGlnbi1sZWZ0LCAuZmlndXJlLmFsaWduLWxlZnQsIG9iamVjdC5hbGln
bi1sZWZ0IHsKICBjbGVhcjogbGVmdCA7CiAgZmxvYXQ6IGxlZnQgOwogIG1hcmdpbi1yaWdo
dDogMWVtIH0KCmltZy5hbGlnbi1yaWdodCwgLmZpZ3VyZS5hbGlnbi1yaWdodCwgb2JqZWN0
LmFsaWduLXJpZ2h0IHsKICBjbGVhcjogcmlnaHQgOwogIGZsb2F0OiByaWdodCA7CiAgbWFy
Z2luLWxlZnQ6IDFlbSB9CgppbWcuYWxpZ24tY2VudGVyLCAuZmlndXJlLmFsaWduLWNlbnRl
ciwgb2JqZWN0LmFsaWduLWNlbnRlciB7CiAgZGlzcGxheTogYmxvY2s7CiAgbWFyZ2luLWxl
ZnQ6IGF1dG87CiAgbWFyZ2luLXJpZ2h0OiBhdXRvOwp9CgouYWxpZ24tbGVmdCB7CiAgdGV4
dC1hbGlnbjogbGVmdCB9CgouYWxpZ24tY2VudGVyIHsKICBjbGVhcjogYm90aCA7CiAgdGV4
dC1hbGlnbjogY2VudGVyIH0KCi5hbGlnbi1yaWdodCB7CiAgdGV4dC1hbGlnbjogcmlnaHQg
fQoKLyogcmVzZXQgaW5uZXIgYWxpZ25tZW50IGluIGZpZ3VyZXMgKi8KZGl2LmFsaWduLXJp
Z2h0IHsKICB0ZXh0LWFsaWduOiBpbmhlcml0IH0KCi8qIGRpdi5hbGlnbi1jZW50ZXIgKiB7
ICovCi8qICAgdGV4dC1hbGlnbjogbGVmdCB9ICovCgpvbC5zaW1wbGUsIHVsLnNpbXBsZSB7
CiAgbWFyZ2luLWJvdHRvbTogMWVtIH0KCm9sLmFyYWJpYyB7CiAgbGlzdC1zdHlsZTogZGVj
aW1hbCB9CgpvbC5sb3dlcmFscGhhIHsKICBsaXN0LXN0eWxlOiBsb3dlci1hbHBoYSB9Cgpv
bC51cHBlcmFscGhhIHsKICBsaXN0LXN0eWxlOiB1cHBlci1hbHBoYSB9CgpvbC5sb3dlcnJv
bWFuIHsKICBsaXN0LXN0eWxlOiBsb3dlci1yb21hbiB9CgpvbC51cHBlcnJvbWFuIHsKICBs
aXN0LXN0eWxlOiB1cHBlci1yb21hbiB9CgpwLmF0dHJpYnV0aW9uIHsKICB0ZXh0LWFsaWdu
OiByaWdodCA7CiAgbWFyZ2luLWxlZnQ6IDUwJSB9CgpwLmNhcHRpb24gewogIGZvbnQtc3R5
bGU6IGl0YWxpYyB9CgpwLmNyZWRpdHMgewogIGZvbnQtc3R5bGU6IGl0YWxpYyA7CiAgZm9u
dC1zaXplOiBzbWFsbGVyIH0KCnAubGFiZWwgewogIHdoaXRlLXNwYWNlOiBub3dyYXAgfQoK
cC5ydWJyaWMgewogIGZvbnQtd2VpZ2h0OiBib2xkIDsKICBmb250LXNpemU6IGxhcmdlciA7
CiAgY29sb3I6IG1hcm9vbiA7CiAgdGV4dC1hbGlnbjogY2VudGVyIH0KCnAuc2lkZWJhci10
aXRsZSB7CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtd2VpZ2h0OiBib2xk
IDsKICBmb250LXNpemU6IGxhcmdlciB9CgpwLnNpZGViYXItc3VidGl0bGUgewogIGZvbnQt
ZmFtaWx5OiBzYW5zLXNlcmlmIDsKICBmb250LXdlaWdodDogYm9sZCB9CgpwLnRvcGljLXRp
dGxlIHsKICBmb250LXdlaWdodDogYm9sZCB9CgpwcmUuYWRkcmVzcyB7CiAgbWFyZ2luLWJv
dHRvbTogMCA7CiAgbWFyZ2luLXRvcDogMCA7CiAgZm9udDogaW5oZXJpdCB9CgpwcmUubGl0
ZXJhbC1ibG9jaywgcHJlLmRvY3Rlc3QtYmxvY2ssIHByZS5tYXRoLCBwcmUuY29kZSB7CiAg
bWFyZ2luLWxlZnQ6IDJlbSA7CiAgbWFyZ2luLXJpZ2h0OiAyZW0gfQoKcHJlLmNvZGUgLmxu
IHsgY29sb3I6IGdyZXk7IH0gLyogbGluZSBudW1iZXJzICovCnByZS5jb2RlLCBjb2RlIHsg
YmFja2dyb3VuZC1jb2xvcjogI2VlZWVlZSB9CnByZS5jb2RlIC5jb21tZW50LCBjb2RlIC5j
b21tZW50IHsgY29sb3I6ICM1QzY1NzYgfQpwcmUuY29kZSAua2V5d29yZCwgY29kZSAua2V5
d29yZCB7IGNvbG9yOiAjM0IwRDA2OyBmb250LXdlaWdodDogYm9sZCB9CnByZS5jb2RlIC5s
aXRlcmFsLnN0cmluZywgY29kZSAubGl0ZXJhbC5zdHJpbmcgeyBjb2xvcjogIzBDNTQwNCB9
CnByZS5jb2RlIC5uYW1lLmJ1aWx0aW4sIGNvZGUgLm5hbWUuYnVpbHRpbiB7IGNvbG9yOiAj
MzUyQjg0IH0KcHJlLmNvZGUgLmRlbGV0ZWQsIGNvZGUgLmRlbGV0ZWQgeyBiYWNrZ3JvdW5k
LWNvbG9yOiAjREVCMEExfQpwcmUuY29kZSAuaW5zZXJ0ZWQsIGNvZGUgLmluc2VydGVkIHsg
YmFja2dyb3VuZC1jb2xvcjogI0EzRDI4OX0KCnNwYW4uY2xhc3NpZmllciB7CiAgZm9udC1m
YW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQtc3R5bGU6IG9ibGlxdWUgfQoKc3Bhbi5jbGFz
c2lmaWVyLWRlbGltaXRlciB7CiAgZm9udC1mYW1pbHk6IHNhbnMtc2VyaWYgOwogIGZvbnQt
d2VpZ2h0OiBib2xkIH0KCnNwYW4uaW50ZXJwcmV0ZWQgewogIGZvbnQtZmFtaWx5OiBzYW5z
LXNlcmlmIH0KCnNwYW4ub3B0aW9uIHsKICB3aGl0ZS1zcGFjZTogbm93cmFwIH0KCnNwYW4u
cHJlIHsKICB3aGl0ZS1zcGFjZTogcHJlIH0KCnNwYW4ucHJvYmxlbWF0aWMgewogIGNvbG9y
OiByZWQgfQoKc3Bhbi5zZWN0aW9uLXN1YnRpdGxlIHsKICAvKiBmb250LXNpemUgcmVsYXRp
dmUgdG8gcGFyZW50IChoMS4uaDYgZWxlbWVudCkgKi8KICBmb250LXNpemU6IDgwJSB9Cgp0
YWJsZS5jaXRhdGlvbiB7CiAgYm9yZGVyLWxlZnQ6IHNvbGlkIDFweCBncmF5OwogIG1hcmdp
bi1sZWZ0OiAxcHggfQoKdGFibGUuZG9jaW5mbyB7CiAgbWFyZ2luOiAyZW0gNGVtIH0KCnRh
YmxlLmRvY3V0aWxzIHsKICBtYXJnaW4tdG9wOiAwLjVlbSA7CiAgbWFyZ2luLWJvdHRvbTog
MC41ZW0gfQoKdGFibGUuZm9vdG5vdGUgewogIGJvcmRlci1sZWZ0OiBzb2xpZCAxcHggYmxh
Y2s7CiAgbWFyZ2luLWxlZnQ6IDFweCB9Cgp0YWJsZS5kb2N1dGlscyB0ZCwgdGFibGUuZG9j
dXRpbHMgdGgsCnRhYmxlLmRvY2luZm8gdGQsIHRhYmxlLmRvY2luZm8gdGggewogIHBhZGRp
bmctbGVmdDogMC41ZW0gOwogIHBhZGRpbmctcmlnaHQ6IDAuNWVtIDsKICB2ZXJ0aWNhbC1h
bGlnbjogdG9wIH0KCnRhYmxlLmRvY3V0aWxzIHRoLmZpZWxkLW5hbWUsIHRhYmxlLmRvY2lu
Zm8gdGguZG9jaW5mby1uYW1lIHsKICBmb250LXdlaWdodDogYm9sZCA7CiAgdGV4dC1hbGln
bjogbGVmdCA7CiAgd2hpdGUtc3BhY2U6IG5vd3JhcCA7CiAgcGFkZGluZy1sZWZ0OiAwIH0K
Ci8qICJib29rdGFicyIgc3R5bGUgKG5vIHZlcnRpY2FsIGxpbmVzKSAqLwp0YWJsZS5kb2N1
dGlscy5ib29rdGFicyB7CiAgYm9yZGVyOiAwcHg7CiAgYm9yZGVyLXRvcDogMnB4IHNvbGlk
OwogIGJvcmRlci1ib3R0b206IDJweCBzb2xpZDsKICBib3JkZXItY29sbGFwc2U6IGNvbGxh
cHNlOwp9CnRhYmxlLmRvY3V0aWxzLmJvb2t0YWJzICogewogIGJvcmRlcjogMHB4Owp9CnRh
YmxlLmRvY3V0aWxzLmJvb2t0YWJzIHRoIHsKICBib3JkZXItYm90dG9tOiB0aGluIHNvbGlk
OwogIHRleHQtYWxpZ246IGxlZnQ7Cn0KCmgxIHR0LmRvY3V0aWxzLCBoMiB0dC5kb2N1dGls
cywgaDMgdHQuZG9jdXRpbHMsCmg0IHR0LmRvY3V0aWxzLCBoNSB0dC5kb2N1dGlscywgaDYg
dHQuZG9jdXRpbHMgewogIGZvbnQtc2l6ZTogMTAwJSB9Cgp1bC5hdXRvLXRvYyB7CiAgbGlz
dC1zdHlsZS10eXBlOiBub25lIH0KCjwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+CjxkaXYgY2xh
c3M9ImRvY3VtZW50IiBpZD0iaW1wbGljaXQtcmV0dXJuLXR5cGUtYW5kLWFsbG93aW5nLWFu
b255bW91cy10eXBlcy1hcy1yZXR1cm4tdmFsdWVzIj4KPGgxIGNsYXNzPSJ0aXRsZSI+SW1w
bGljaXQgUmV0dXJuIFR5cGUgYW5kIEFsbG93aW5nIEFub255bW91cyBUeXBlcyBhcyBSZXR1
cm4gVmFsdWVzPC9oMT4KPHRhYmxlIGNsYXNzPSJkb2NpbmZvIiBmcmFtZT0idm9pZCIgcnVs
ZXM9Im5vbmUiPgo8Y29sIGNsYXNzPSJkb2NpbmZvLW5hbWUiIC8+Cjxjb2wgY2xhc3M9ImRv
Y2luZm8tY29udGVudCIgLz4KPHRib2R5IHZhbGlnbj0idG9wIj4KPHRyIGNsYXNzPSJmaWVs
ZCI+PHRoIGNsYXNzPSJkb2NpbmZvLW5hbWUiPkRvY3VtZW50OjwvdGg+PHRkIGNsYXNzPSJm
aWVsZC1ib2R5Ij5EWFhYWFIwPC90ZD4KPC90cj4KPHRyPjx0aCBjbGFzcz0iZG9jaW5mby1u
YW1lIj5EYXRlOjwvdGg+Cjx0ZD4yMDE2LTEyLTE5PC90ZD48L3RyPgo8dHIgY2xhc3M9ImZp
ZWxkIj48dGggY2xhc3M9ImRvY2luZm8tbmFtZSI+UHJvamVjdDo8L3RoPjx0ZCBjbGFzcz0i
ZmllbGQtYm9keSI+SVNPL0lFQyBKVEMxIFNDMjIgV0cyMSBQcm9ncmFtbWluZyBMYW5ndWFn
ZSBDKys8L3RkPgo8L3RyPgo8dHIgY2xhc3M9ImZpZWxkIj48dGggY2xhc3M9ImRvY2luZm8t
bmFtZSI+QXVkaWVuY2U6PC90aD48dGQgY2xhc3M9ImZpZWxkLWJvZHkiPkV2b2x1dGlvbiBX
b3JraW5nIEdyb3VwPC90ZD4KPC90cj4KPHRyPjx0aCBjbGFzcz0iZG9jaW5mby1uYW1lIj5B
dXRob3I6PC90aD4KPHRkPk1hdHRoZXcgV29laGxrZSAoPGEgY2xhc3M9InJlZmVyZW5jZSBl
eHRlcm5hbCIgaHJlZj0ibWFpbHRvOm13b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5jb20iPm13
b2VobGtlLmZsb3NzJiM2NDtnbWFpbC5jb208L2E+KTwvdGQ+PC90cj4KPC90Ym9keT4KPC90
YWJsZT4KPHN0eWxlPgogIGh0bWwgeyBjb2xvcjogYmxhY2s7IGJhY2tncm91bmQ6IHdoaXRl
OyB9CiAgdGFibGUuZG9jaW5mbyB7IG1hcmdpbjogMmVtIDA7IH0KPC9zdHlsZT48ZGl2IGNs
YXNzPSJzZWN0aW9uIiBpZD0iYWJzdHJhY3QiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVm
IiBocmVmPSIjaWQxIj5BYnN0cmFjdDwvYT48L2gxPgo8cD5UaGlzIHByb3Bvc2FsIHJlY29t
bWVuZHMgdGhlIHJlbGF4aW5nIG9mIFtkY2wuZmN0XS8xMTsgc3BlY2lmaWNhbGx5LCB0aGUg
cHJvaGliaXRpb24gb2YgZGVmaW5pbmcgKGFub255bW91cykgdHlwZXMgYXMgcmV0dXJuIHZh
bHVlcywgYW5kIGFkZGluZyBhIG1lY2hhbmlzbSB0aGF0IHNpbXBsaWZpZXMgbmFtaW5nIHRo
ZSByZXR1cm4gdHlwZSBvZiBhIHByZXZpb3VzbHkgZGVjbGFyZWQgZnVuY3Rpb24uIFRoZXNl
IGZlYXR1cmVzIHdlcmUgcHJldmlvdXNseSBwcm9wb3NlZCBzZXBhcmF0ZWx5LCBhcyA8YSBj
bGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMjIy
Ij5QMDIyMjwvYT4gYW5kIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0
dHA6Ly93ZzIxLmxpbmsvcDAyMjQiPlAwMjI0PC9hPi48L3A+CjxkaXYgY2xhc3M9ImNvbnRl
bnRzIHRvcGljIiBpZD0iY29udGVudHMiPgo8cCBjbGFzcz0idG9waWMtdGl0bGUgZmlyc3Qi
PkNvbnRlbnRzPC9wPgo8dWwgY2xhc3M9InNpbXBsZSI+CjxsaT48YSBjbGFzcz0icmVmZXJl
bmNlIGludGVybmFsIiBocmVmPSIjYWJzdHJhY3QiIGlkPSJpZDEiPkFic3RyYWN0PC9hPjwv
bGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjcmF0aW9uYWxl
IiBpZD0iaWQyIj5SYXRpb25hbGU8L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2Ug
aW50ZXJuYWwiIGhyZWY9IiNwcm9wb3NhbCIgaWQ9ImlkMyI+UHJvcG9zYWw8L2E+PC9saT4K
PGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNpbnRlcmFjdGlvbnMi
IGlkPSJpZDQiPkludGVyYWN0aW9uczwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5j
ZSBpbnRlcm5hbCIgaHJlZj0iI2ltcGxlbWVudGF0aW9uLWFuZC1leGlzdGluZy1wcmFjdGlj
ZSIgaWQ9ImlkNSI+SW1wbGVtZW50YXRpb24gYW5kIEV4aXN0aW5nIFByYWN0aWNlPC9hPjwv
bGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjZGlzY3Vzc2lv
biIgaWQ9ImlkNiI+RGlzY3Vzc2lvbjwvYT48dWw+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNl
IGludGVybmFsIiBocmVmPSIjY2FuLXQtd2UtZG8tdGhpcy1hbHJlYWR5IiBpZD0iaWQ3Ij5D
YW4ndCB3ZSBkbyB0aGlzIGFscmVhZHk/PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJl
bmNlIGludGVybmFsIiBocmVmPSIjc2hvdWxkLXdlLWFsbG93LW5hbWVkLXR5cGVzLWRlZmlu
ZWQtYXMtcmV0dXJuLXR5cGVzIiBpZD0iaWQ4Ij5TaG91bGQgd2UgYWxsb3cgPGVtPm5hbWVk
PC9lbT4gdHlwZXMgZGVmaW5lZCBhcyByZXR1cm4gdHlwZXM/PC9hPjwvbGk+CjxsaT48YSBj
bGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjaXNuLXQtdGVtcGxhdGUtcGFyc2lu
Zy1kaWZmaWN1bHQiIGlkPSJpZDkiPklzbid0IHRlbXBsYXRlIHBhcnNpbmcgZGlmZmljdWx0
PzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI2lz
LWRlY2x0eXBlLXJldHVybi1kYW5nZXJvdXMiIGlkPSJpZDEwIj5JcyA8Y29kZSBjbGFzcz0i
Y3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBlPC9zcGFuPjxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9z
cGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj48L2NvZGU+IGRhbmdlcm91
cz88L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiN3
aGF0LWFib3V0LWRlZmluaW5nLXR5cGVzLWluLWZ1bmN0aW9uLXBvaW50ZXItdHlwZXMiIGlk
PSJpZDExIj5XaGF0IGFib3V0IGRlZmluaW5nIHR5cGVzIGluIGZ1bmN0aW9uIHBvaW50ZXIg
dHlwZXM/PC9hPjwvbGk+CjxsaT48YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVm
PSIjd2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1pbi1wYXJhbWV0ZXItdHlwZXMiIGlkPSJp
ZDEyIj5XaGF0IGFib3V0IGRlZmluaW5nIHR5cGVzIGluIHBhcmFtZXRlciB0eXBlcz88L2E+
PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiN3aGF0LWFi
b3V0LXBhc3MtdGhyb3VnaC1vZi1yZXR1cm4tdmFsdWVzLWhhdmluZy1lcXVpdmFsZW50LXR5
cGVzIiBpZD0iaWQxMyI+V2hhdCBhYm91dCAmcXVvdDtwYXNzLXRocm91Z2gmcXVvdDsgb2Yg
cmV0dXJuIHZhbHVlcyBoYXZpbmcgZXF1aXZhbGVudCB0eXBlcz88L2E+PC9saT4KPGxpPjxh
IGNsYXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNkb2VzLXRoaXMtY29uZmxpY3Rz
LXdpdGgtZnV0dXJlLXRydWUtbXVsdGlwbGUtcmV0dXJuLXZhbHVlcyIgaWQ9ImlkMTQiPkRv
ZXMgdGhpcyBjb25mbGljdHMgd2l0aCBmdXR1cmUgJnF1b3Q7dHJ1ZSZxdW90OyBtdWx0aXBs
ZSByZXR1cm4gdmFsdWVzPzwvYT48L2xpPgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRl
cm5hbCIgaHJlZj0iI3doYXQtYWJvdXQtZGVkdWNlZC1yZXR1cm4tdHlwZXMiIGlkPSJpZDE1
Ij5XaGF0IGFib3V0IGRlZHVjZWQgcmV0dXJuIHR5cGVzPzwvYT48L2xpPgo8L3VsPgo8L2xp
Pgo8bGk+PGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI2Z1dHVyZS1kaXJl
Y3Rpb25zIiBpZD0iaWQxNiI+RnV0dXJlIERpcmVjdGlvbnM8L2E+PC9saT4KPGxpPjxhIGNs
YXNzPSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNhY2tub3dsZWRnbWVudHMiIGlkPSJp
ZDE3Ij5BY2tub3dsZWRnbWVudHM8L2E+PC9saT4KPGxpPjxhIGNsYXNzPSJyZWZlcmVuY2Ug
aW50ZXJuYWwiIGhyZWY9IiNyZWZlcmVuY2VzIiBpZD0iaWQxOCI+UmVmZXJlbmNlczwvYT48
L2xpPgo8L3VsPgo8L2Rpdj4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJyYXRp
b25hbGUiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQyIj5SYXRpb25h
bGU8L2E+PC9oMT4KPHA+VGhlIGNvbmNlcHQgb2YgbXVsdGlwbGUgcmV0dXJuIHZhbHVlcyBp
cyB3ZWxsIGtub3duLiBBdCBwcmVzZW50LCBob3dldmVyLCBDKysgbGFja3MgYSBnb29kIG1l
Y2hhbmlzbSBmb3IgaW1wbGVtZW50aW5nIHRoZSBzYW1lLiA8dHQgY2xhc3M9ImRvY3V0aWxz
IGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4gaXMg
Y29uc2lkZXJlZCBjbHVua3kgYnkgbWFueSBhbmQsIGNyaXRpY2FsbHksIGNyZWF0ZXMgc3Vi
LW9wdGltYWwgQVBJIGJ5IHZpcnR1ZSBvZiB0aGUgcmV0dXJuZWQgdmFsdWVzIGJlaW5nIHVu
bmFtZWQsIGZvcmNpbmcgZGV2ZWxvcGVycyB0byByZWx5IG9uIHN1cHBsZW1lbnRhbCBkb2N1
bWVudGF0aW9uIHRvIGV4cGxhaW4gdGhlaXIgcHVycG9zZS4gQWdncmVnYXRlcyByZXByZXNl
bnQgYW4gaW1wcm92ZW1lbnQsIGJlaW5nIHNlbGYtZG9jdW1lbnRpbmcsIGJ1dCB0aGUgbmVl
ZCB0byBwcm92aWRlIGV4dGVybmFsIGRlZmluaXRpb25zIG9mIHRoZSBzYW1lIGlzIGF3a3dh
cmQgYW5kLCB3b3JzZSwgcG9sbHV0ZXMgdGhlaXIgY29ycmVzcG9uZGluZyBuYW1lc3BhY2Ug
d2l0aCBlbnRpdGllcyB0aGF0IG1heSBiZSBzaW5nbGUgdXNlLiBQcm9wb3NhbHMgc3VjaCBh
cyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd3d3Lm9wZW4t
c3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDE1L240NTYwLnBkZiI+TjQ1
NjA8L2E+IHByZXNlbnQgYSBjb21wbGljYXRlZCBtZWNoYW5pc20gZm9yIHByb3ZpZGluZyB0
YWdnZWQgKHNlbGYtZG9jdW1lbnRpbmcpIHR1cGxlLWxpa2UgdHlwZXMsIHdoaWNoIG1heSBi
ZSBuZWNlc3NhcnkgaW4gc29tZSBjYXNlcywgYnV0IHN0aWxsIHJlcHJlc2VudCBhIG5vbi10
cml2aWFsIGFtb3VudCBvZiBjb21wbGV4aXR5IHRoYXQgaWRlYWxseSBzaG91bGQgbm90IGJl
IHJlcXVpcmVkLiA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8v
d2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4gcHJlc2VudHMgYSBzaW1pbGFyIGlkZWEgd2l0
aCB0YWdnZWQgcGFyYW1ldGVyIHBhY2tzIGFzIHJldHVybiB2YWx1ZXMuPC9wPgo8cD5UaGUg
YWRkaXRpb24gb2YgJnF1b3Q7c3RydWN0dXJlZCBiaW5kaW5ncyZxdW90OyBpbiBDKysxNyBp
biBwYXJ0aWN1bGFyIHJlcHJlc2VudHMgYSBzaWduaWZpY2FudCBzdGVwIHRvd2FyZCBzdXBw
b3J0IG9mIG11bHRpcGxlIHJldHVybiB2YWx1ZXMgYXMgZmlyc3QgY2xhc3MgY2l0aXplbnMu
IFRoaXMgZmVhdHVyZSwgYWxvbmcgd2l0aCBvdGhlciBvbmdvaW5nIGVmZm9ydHMgdG8gYWRk
IGZpcnN0IGNsYXNzIHN1cHBvcnQgZm9yICZxdW90O3Byb2R1Y3QgdHlwZXMmcXVvdDsgYW5k
IG90aGVyIGVmZm9ydHMgc3VjaCBhcyA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBo
cmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4gc2hvdyBhbiBlbmNvdXJh
Z2luZyBtb3ZlbWVudCBhd2F5IGZyb20gdGhlIHRyYWRpdGlvbmFsIDx0dCBjbGFzcz0iZG9j
dXRpbHMgbGl0ZXJhbCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjpwYWlyPC9zcGFuPjwvdHQ+
IGFuZCA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0
ZDo6dHVwbGU8L3NwYW4+PC90dD4gdG93YXJkcyBjb21wYXJhYmxlIGNvbmNlcHRzIHdpdGhv
dXQgcmVxdWlyaW5nIHRoZSBleHBsaWNpdCB0eXBlcy4gKFdlIGV4cGVjdCwgaG93ZXZlciwg
dGhhdCB0aGUgc3RhbmRhcmQgdGVtcGxhdGUgbGlicmFyeSB0eXBlcyB3aWxsIHJlbWFpbiB1
c2VmdWwgZm9yIGFsZ29yaXRobXMgd2hlcmUgdGhlIGlkZW50aXR5IG9mIHRoZSBlbGVtZW50
cyBpcyB1bmltcG9ydGFudCwgd2hpbGUgaXQgPGVtPmlzPC9lbT4gaW1wb3J0YW50IHRvIGJl
IGFibGUgdG8gbmFtZSBhdCBsZWFzdCB0aGUgb3V0ZXIsIGlmIG5vdCBjb21wbGV0ZSwgdHlw
ZS4gSW4gdGhhdCByZXNwZWN0LCB3ZSBoeXBvdGhlc2l6ZSB0aGF0IHdlIG1heSBpbiB0aGUg
ZnV0dXJlIHNlZSB0aGUgYWJpbGl0eSB0byBjb25zdHJ1Y3QgYSA8dHQgY2xhc3M9ImRvY3V0
aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZDo6dHVwbGU8L3NwYW4+PC90dD4g
ZnJvbSBhbnkgdHVwbGUtbGlrZSwgYXMgYWxzbyBzdWdnZXN0ZWQgaW4gPGEgY2xhc3M9InJl
ZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDE5NyI+UDAxOTc8
L2E+Lik8L3A+CjxwPk9uIHRoZWlyIG93biwgaG93ZXZlciwgdGhlc2UgZGlyZWN0aW9ucyBy
aXNrIGV4YWNlcmJhdGluZyB0aGUgcHJvYmxlbSB0aGF0IHRoaXMgcHJvcG9zYWwgYWltcyB0
byBhZGRyZXNzLiBJbiBwYXJ0aWN1bGFyLCBhIGNvbmNlcm4gd2l0aCB0aGUgbm90aW9uIG9m
IHJldHVybmluZyBhIHBhcmFtZXRlciBwYWNrLCBhcyBwcmVzZW50ZWQgaW4gPGEgY2xhc3M9
InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDM0MSI+UDAz
NDE8L2E+LCBvcGVucyBhIHBvdGVudGlhbCBBQkkgY2FuIG9mIHdvcm1zLiBNb3Jlb3Zlciwg
cGFyYW1ldGVyIHBhY2tzIGFyZSBub3QgdHJ1ZSB0eXBlcywgYW5kIGFyZSBzdWJqZWN0IHRv
IHNpZ25pZmljYW50IGxpbWl0YXRpb25zLCBzdWNoIGFzIGluYWJpbGl0eSB0byBtYWtlIGNv
cGllcyBvciBwYXNzIHRoZW0gYXJvdW5kIGFzIHNpbmdsZSBlbnRpdGllcywgd2hpY2ggYXJl
IG5vdCBzaGFyZWQgYnkgcmVndWxhciBjb21wb3VuZCB0eXBlcy4gV2l0aCBnZW5lcmFsaXpl
ZCB1bnBhY2tpbmcgKDxhIGhyZWY9IiNpZDE5Ij48c3BhbiBjbGFzcz0icHJvYmxlbWF0aWMi
IGlkPSJpZDIwIj5GSVhNRV88L3NwYW4+PC9hPiksIHByb2R1Y3QgdHlwZXMgYW5kIHBhcmFt
ZXRlciBwYWNrcyBhcmUgZWZmZWN0aXZlbHkgaW50ZXJjaGFuZ2VhYmxlLCBhbmQgcmV0dXJu
aW5nIGEgcHJvZHVjdCB0eXBlIHJhdGhlciB0aGFuIGEgcGFyYW1ldGVyIHBhY2sgbGV2ZXJh
Z2VzIGV4aXN0aW5nIEFCSSBhbmQgdGVjaG5pcXVlcywgcmF0aGVyIHRoYW4gaW50cm9kdWNp
bmcgc29tZXRoaW5nIGVudGlyZWx5IG5vdmVsLiBUaGUgcmVtYWluaW5nIGlzc3VlIGlzIG9u
ZSBvZiBuYW1pbmc7IG5hbWluZyB0aGluZ3Mg4oCUIGluIHRoaXMgY2FzZSwgcmV0dXJuIHR5
cGVzLCBlc3BlY2lhbGx5IGZvciBvbmUtb2ZmIGZ1bmN0aW9ucyDigJQgaXMgPGVtPmhhcmQ8
L2VtPi48L3A+CjxwPkl0IGhhcyBiZWVuIHN1Z2dlc3RlZCBvbiBtdWx0aXBsZSBvY2Nhc2lv
bnMgdGhhdCB0aGUgb3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgYWJvdmUgaXNzdWVzIGlzIHRv
IHJldHVybiBhbiBhbm9ueW1vdXMgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj5zdHJ1
Y3Q8L3R0Pi4gVGhpcyBzb2x2ZXMgdGhlIHByb2JsZW1zIG9mIGNsdXR0ZXIgYW5kIHNlbGYt
ZG9jdW1lbnRhdGlvbiwgYnV0IHJ1bnMgYWZvdWwgb2YgYSBtdWNoIHdvcnNlIGlzc3VlOyBi
ZWNhdXNlIHRoZSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPnN0cnVjdDwvdHQ+IGlz
IDxlbT5hbm9ueW1vdXM8L2VtPiwgaXQgY2FuIGJlIGRpZmZpY3VsdCB0byBpbXBvc3NpYmxl
IHRvIGdpdmUgaXRzIG5hbWUgYSBzZWNvbmQgdGltZSBpbiBvcmRlciB0byBzZXBhcmF0ZSB0
aGUgZGVjbGFyYXRpb24gYW5kIGRlZmluaXRpb24gb2YgdGhlIGZ1bmN0aW9uIHRoYXQgd2lz
aGVzIHRvIHVzZSBpdC4gVGhpcywgaG93ZXZlciwgbGVhZHMgdG8gYSBtb3JlIGludGVyZXN0
aW5nIHF1ZXN0aW9uOiA8c3Ryb25nPndoeSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVwZWF0IHRo
ZSByZXR1cm4gdmFsdWUgYXQgYWxsPzwvc3Ryb25nPjwvcD4KPHA+RXZlbiBpbiB0aGUgY2Fz
ZSBvZiByZXR1cm4gdHlwZXMgdGhhdCBjYW4gYmUgbmFtZWQsIGl0IG1heSBiZSB0aGF0IHJl
cGVhdGluZyB0aGUgdHlwZSBuYW1lIGlzIGV4Y2Vzc2l2ZWx5IHZlcmJvc2Ugb3Igb3RoZXJ3
aXNlIHVuZGVzaXJhYmxlLiBTb21lIG1pZ2h0IGV2ZW4gY2FsbCB0aGlzIGEgdmlvbGF0aW9u
IG9mIHRoZSA8YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwczovL2Vu
Lndpa2lwZWRpYS5vcmcvd2lraS9Eb24ndF9yZXBlYXRfeW91cnNlbGYiPkRvbid0IFJlcGVh
dCBZb3Vyc2VsZjwvYT4gcHJpbmNpcGxlLCBzaW1pbGFyIHRvIHNvbWUgb2YgdGhlIGlzc3Vl
cyB0aGF0IDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+YXV0bzwvdHQ+IGZvciB2YXJp
YWJsZSBkZWNsYXJhdGlvbiB3YXMgaW50cm9kdWNlZCB0byBzb2x2ZS4gKE9uIHRoZSBmbGlw
IHNpZGUsIG9uZSBjb3VsZCBzZWUgdGhlIGFiaWxpdHkgdG8gZWxpZGUgdGhlIHJldHVybiB0
eXBlIGFzIHN1YmplY3QgdG8gbWFueSBhYnVzZXMsIGFnYWluIGluIG11Y2ggdGhlIG1hbm5l
ciBvZiA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPmF1dG88L3R0Pi4gSG93ZXZlciwg
bWFueSBsYW5ndWFnZSBmZWF0dXJlcyBjYW4gYmUgYWJ1c2VkOyB0aGlzIHNob3VsZCBub3Qg
cHJldmVudCB0aGUgYWRkaXRpb24gb2YgYSBmZWF0dXJlIHRoYXQgd291bGQgcHJvdmlkZSBh
biBpbXBvcnRhbnQgYmVuZWZpdCB3aGVuIHVzZWQgY29ycmVjdGx5Lik8L3A+CjxwPldoaWxl
IGl0IGlzIGFscmVhZHkgcG9zc2libGUgaW4gc2ltcGxlIGNhc2VzIHRvIHVzZSA8Y29kZSBj
bGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBlPC9zcGFuPjwvY29k
ZT4gYW5kIGEgc2FtcGxlIGludm9jYXRpb24gb2YgdGhlIGZ1bmN0aW9uLCB0aGlzIGlzIG5l
ZWRsZXNzbHkgdmVyYm9zZSwgYW5kIGFzIHRoZSBhcmd1bWVudCBsaXN0IGdyb3dzIGxvbmdl
ciBhbmQvb3IgZ2FpbnMgYXJndW1lbnRzIGZvciB3aGljaCBwcm92aWRpbmcgYSBsZWdhbCB2
YWx1ZSBpcyBub24tdHJpdmlhbCwgaXQgY2FuIHF1aWNrbHkgYmVjb21lIHVud2llbGR5IGFu
ZCB1bmZlYXNpYmxlLjwvcD4KPHA+V2hpbGUgYm90aCB0aGVzZSBmZWF0dXJlcyBoYXZlIHVz
ZSBvbiB0aGVpciBvd24sIHRoZXkgYXJlIG5ldmVydGhlbGVzcyByZWxhdGVkLCBhbmQgd2Ug
YmVsaWV2ZSB0aGF0IHByZXNlbnRpbmcgdGhlbSB0b2dldGhlciBtYWtlcyBzZW5zZSwgYW5k
IHN0cmVuZ3RoZW5zIHRoZSBjYXNlIGZvciBlYWNoLjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9
InNlY3Rpb24iIGlkPSJwcm9wb3NhbCI+CjxoMT48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhy
ZWY9IiNpZDMiPlByb3Bvc2FsPC9hPjwvaDE+CjxwPldlIHByb3Bvc2UsIGZpcnN0LCB0byBy
ZW1vdmUgdGhlIHJlc3RyaWN0aW9uIGFnYWluc3QgKGFub255bW91cykgdHlwZXMgYXMgcmV0
dXJuIHZhbHVlczo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwtYmxvY2siPgo8
c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im5hbWUiPmlkPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+ZG91YmxlPC9zcGFuPiA8c3Bh
biBjbGFzcz0ibmFtZSI+dmFsdWU8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47
PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4g
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1
YXRpb24iPi4uLjwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8
L3ByZT4KPHA+V2UgYmVsaWV2ZSB0aGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgbGFyZ2VseSBi
eSBzaW1wbHkgcmVtb3ZpbmcgdGhlIHByb2hpYml0aW9uIGluIFtkY2wuZmN0XS8xMS48L3A+
CjxwPlNlY29uZCwgd2UgcHJvcG9zZSB0aGUgYWRkaXRpb24gb2YgPGNvZGUgY2xhc3M9ImNw
cCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bh
bj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2RlPiB0byBuYW1lIOKA
lCBpbiBhIGZ1bmN0aW9uIHNpZ25hdHVyZSDigJQgdGhlIHJldHVybiB0eXBlIG9mIGEgcHJl
dmlvdXNseSBkZWNsYXJlZCBmdW5jdGlvbi4gVGhpcyBpcyBjb25zaXN0ZW50IHdpdGggcmVj
ZW50IGNoYW5nZXMgdG8gdGhlIGxhbmd1YWdlIHRoYXQgaGF2ZSBwcm9ncmVzc2l2ZWx5IHJl
bGF4ZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgaG93IHJldHVybiB0eXBlcyBhcmUgc3BlY2lm
aWVkLCBhbmQgcHJvdmlkZXMgYW4gb3B0aW1hbCBzb2x1dGlvbiB0byB0aGUgZm9sbG93aW5n
IHByb2JsZW06PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRlcmFsLWJsb2NrIj4KPHNw
YW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBmb28uaAo8L3NwYW4+PHNwYW4gY2xhc3M9
ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9z
cGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj5pZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxz
cGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5h
bWUiPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4gPHNw
YW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+Zm9v
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk7PC9zcGFuPgo8L3ByZT4KPHA+
SG93IGRvZXMgb25lIG5vdyBwcm92aWRlIGFuIGV4dGVybmFsIGRlZmluaXRpb24gZm9yIDx0
dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJhbCI+Zm9vKCk8L3R0Pj8gV2l0aCBvdXIgcHJvcG9z
YWwsIHRoZSBzb2x1dGlvbiBpcyBzaW1wbGU6PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBs
aXRlcmFsLWJsb2NrIj4KPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBmb28uY3Bw
Cjwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVjbHR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFt
ZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk8L3NwYW4+CjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPi4uLjwvc3Bhbj4KICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5p
ZDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj52YWx1ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59Ozwvc3Bh
bj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+TmF0dXJh
bGx5LCAmcXVvdDtwcmV2aW91cyBkZWNsYXJlZCZxdW90OyBoZXJlIG1lYW5zIGEgZGVjbGFy
YXRpb24gaGF2aW5nIHRoZSBzYW1lIG5hbWUgYW5kIGFyZ3VtZW50IGxpc3QuIFRoaXMsIGZv
ciBleGFtcGxlLCB3b3VsZCByZW1haW4gaWxsZWdhbDo8L3A+CjxwcmUgY2xhc3M9ImNvZGUg
YysrIGxpdGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuYW1lIGZ1bmN0aW9uIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwv
c3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik7PC9zcGFuPgo8c3BhbiBjbGFzcz0i
a2V5d29yZCB0eXBlIj5mbG9hdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUgZnVuY3Rpb24i
PmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xh
c3M9ImtleXdvcmQgdHlwZSI+ZmxvYXQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij4pOzwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3BhbiBj
bGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVy
bjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuYW1lIj5mb288L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxz
cGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmRvdWJsZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5h
bWUiPmlucHV0PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj4gPHNw
YW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBkb2VzIG5vdCBtYXRjaCBhbnkgcHJldmlv
dXMgZGVjbGFyYXRpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bh
bj4KICA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj4KICA8c3BhbiBjbGFz
cz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+cmVzdWx0PC9z
cGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj59PC9zcGFuPgo8L3ByZT4KPHA+VGhlIHJlYXNvbnMgdG8gcHJvaGliaXQg
YW4gYW5vbnltb3VzIHN0cnVjdCBkZWZpbmVkIGFzIGEgcmV0dXJuIHR5cGUgaGF2ZSBhbHNv
IGJlZW4gc2lnbmlmaWNhbnRseSBtaXRpZ2F0ZWQuIENvbnN0cnVjdGluZyB0aGUgcmV0dXJu
IHJlc3VsdCBpcyBhIG5vbi1pc3N1ZSwgc2luY2UgdGhlIHR5cGUgbmFtZSBtYXkgbm93IGJl
IGVsaWRlZCwgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+
PHNwYW4gY2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+PC9jb2RlPiB2YXJpYWJsZSBkZWNs
YXJhdGlvbnMsIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVj
bHR5cGU8L3NwYW4+PC9jb2RlPiwgYW5kIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gZm9yIG5h
bWluZyB0aGUgcmV0dXJuIHR5cGUgaW4gYSBmdW5jdGlvbiBzaWduYXR1cmUgcGVybWl0IGlt
cGxpY2l0IG5hbWluZyBvZiB0aGUgdHlwZSB3aGVyZSBuZWNlc3NhcnkuIEluIHNob3J0LCB0
aGUgcHJvaGliaXRpb24gKFtkY2wuZmN0XS8xMSkgYWdhaW5zdCBkZWZpbmluZyB0eXBlcyBp
biByZXR1cm4gdHlwZSBzcGVjaWZpY2F0aW9ucyBoYXMgYmVjb21lIGxhcmdlbHkgYW4gYXJ0
aWZpY2lhbCBhbmQgYXJiaXRyYXJ5IHJlc3RyaWN0aW9uIHdoaWNoIHdlIHByb3Bvc2UgdG8g
cmVtb3ZlLjwvcD4KPHA+V2UgYWRkaXRpb25hbGx5IG5vdGUgdGhhdCB0aGlzIHByb2hpYml0
aW9uIGlzIGFscmVhZHkgbm90IGVuZm9yY2VkIGJ5IGF0IGxlYXN0IG9uZSBtYWpvciBjb21w
aWxlciAoTVNWQyksIGFuZCBpcyBlbmZvcmNlZCBzcG9yYWRpY2FsbHkgaW4gb3RoZXJzIChz
ZWUgPGEgY2xhc3M9InJlZmVyZW5jZSBpbnRlcm5hbCIgaHJlZj0iI3doYXQtYWJvdXQtZGVm
aW5pbmctdHlwZXMtaW4tZnVuY3Rpb24tcG9pbnRlci10eXBlcyI+V2hhdCBhYm91dCBkZWZp
bmluZyB0eXBlcyBpbiBmdW5jdGlvbiBwb2ludGVyIHR5cGVzPzwvYT4pLjwvcD4KPC9kaXY+
CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJpbnRlcmFjdGlvbnMiPgo8aDE+PGEgY2xhc3M9
InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ0Ij5JbnRlcmFjdGlvbnM8L2E+PC9oMT4KPHA+RGVm
aW5pdGlvbiBvZiBhIGNsYXNzLXR5cGUgYXMgYSByZXR1cm4gdmFsdWUgdHlwZSBpcyBjdXJy
ZW50bHkgaWxsLWZvcm1lZCAoYWx0aG91Z2ggbm90IHVuaXZlcnNhbGx5IGVuZm9yY2VkIGJ5
IGV4aXN0aW5nIG1ham9yIGNvbXBpbGVycyksIGFuZCB0aGUgdG9rZW4gc2VxdWVuY2UgPGNv
ZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQi
PnJldHVybjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2Rl
PiBpcyBjdXJyZW50bHkgaWxsLWZvcm1lZC4gQWNjb3JkaW5nbHksIHRoaXMgY2hhbmdlIHdp
bGwgbm90IGFmZmVjdCBleGlzdGluZyBhbmQgY29uZm9ybWluZyBjb2RlLCBhbmQgbWF5IGNh
dXNlIGV4aXN0aW5nIGJ1dCBub24tY29uZm9ybWluZyBjb2RlIHRvIGJlY29tZSBjb25mb3Jt
aW5nLiBUaGlzIHByb3Bvc2FsIGRvZXMgbm90IG1ha2UgYW55IGNoYW5nZXMgdG8gb3RoZXIg
ZXhpc3RpbmcgbGFuZ3VhZ2Ugb3IgbGlicmFyeSBmZWF0dXJlczsgd2hpbGUgY29uY2VpdmFi
bGUgdGhhdCBzb21lIGxpYnJhcnkgbWV0aG9kcyBtaWdodCBiZW5lZml0IGZyb20gdGhlIGZl
YXR1cmUsIHN1Y2ggY2hhbmdlcyBhcmUgcG90ZW50aWFsbHkgYnJlYWtpbmcsIGFuZCBubyBz
dWNoIGNoYW5nZXMgYXJlIHByb3Bvc2VkIGF0IHRoaXMgdGltZS48L3A+CjwvZGl2Pgo8ZGl2
IGNsYXNzPSJzZWN0aW9uIiBpZD0iaW1wbGVtZW50YXRpb24tYW5kLWV4aXN0aW5nLXByYWN0
aWNlIj4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkNSI+SW1wbGVtZW50
YXRpb24gYW5kIEV4aXN0aW5nIFByYWN0aWNlPC9hPjwvaDE+CjxwPlRoZSBwcm9wb3NlZCBm
ZWF0dXJlIHRvIGFsbG93IHR5cGVzIGFzIHJldHVybiB2YWx1ZXMgaXMgYXQgbGVhc3QgYWxy
ZWFkeSBwYXJ0bHkgaW1wbGVtZW50ZWQgYnkgTVNWQyBhbmQgKHRvIGEgbGVzc2VyIGV4dGVu
ZCkgR0NDIGFuZCBJQ0MuIFRoZSBjdXJpb3VzLCBwYXJ0aWFsIHN1cHBvcnQgaW4gR0NDIGFu
ZCBJQ0MgKHNlZSA8YSBjbGFzcz0icmVmZXJlbmNlIGludGVybmFsIiBocmVmPSIjd2hhdC1h
Ym91dC1kZWZpbmluZy10eXBlcy1pbi1mdW5jdGlvbi1wb2ludGVyLXR5cGVzIj5XaGF0IGFi
b3V0IGRlZmluaW5nIHR5cGVzIGluIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZXM/PC9hPikgc3Vn
Z2VzdHMgdGhhdCB0aGUgZXhpc3RpbmcgcHJvaGliaXRpb24gbWF5IGFscmVhZHkgYmUgbGFy
Z2VseSBhcnRpZmljaWFsLCBhbmQgdGhhdCByZW1vdmluZyBpdCB3b3VsZCBhY2NvcmRpbmds
eSBiZSBhIHNpbXBsZSBtYXR0ZXIuPC9wPgo8cD5UaGUgcHJvcG9zZWQgZmVhdHVyZSB0byBh
bGxvdyA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+PHNwYW4gY2xhc3M9Im5hbWUiPmRlY2x0eXBl
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0i
a2V5d29yZCI+cmV0dXJuPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bh
bj48L2NvZGU+IHRvIG5hbWUgdGhlIHJldHVybiB2YWx1ZSBoYXMgbm90LCB0byBvdXIga25v
d2xlZGdlLCBiZWVuIGltcGxlbWVudGVkLCBidXQgZ2l2ZW4gdGhhdCBjb21waWxlcnMgbXVz
dCBhbHJlYWR5IGNvbXBhcmUgdGhlIHJldHVybiB2YWx1ZSB3aGVuIGNvbmZyb250ZWQgd2l0
aCBhbiBpbml0aWFsIGRlY2xhcmF0aW9uIGZvbGxvd2VkIGJ5IHN1YnNlcXVlbnQgcmVkZWNs
YXJhdGlvbnMgYW5kL29yIGEgZGVmaW5pdGlvbiwgd2UgZG8gbm90IGFudGljaXBhdGUgYW55
IGltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcy48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJz
ZWN0aW9uIiBpZD0iZGlzY3Vzc2lvbiI+CjxoMT48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhy
ZWY9IiNpZDYiPkRpc2N1c3Npb248L2E+PC9oMT4KPGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9
ImNhbi10LXdlLWRvLXRoaXMtYWxyZWFkeSI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYi
IGhyZWY9IiNpZDciPkNhbid0IHdlIGRvIHRoaXMgYWxyZWFkeT88L2E+PC9oMj4KPHA+QXN0
dXRlIG9ic2VydmVycyBtYXkgbm90ZSB0aGF0IHRoaXMgaXMgYWxyZWFkeSBsZWdhbCAoYXMg
b2YgQysrMTQpOjwvcD4KPHByZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+Cjxz
cGFuIGNsYXNzPSJrZXl3b3JkIj5hdXRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5j
dGlvbiI+Zjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPgo8c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+CiAgPHNwYW4gY2xhc3M9ImtleXdvcmQi
PnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3Bh
biBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj54
PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im5hbWUiPnk8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1
bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPgogIDxzcGFuIGNs
YXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gc2V0IHZhbHVlcyBvZiByZXN1bHQKPC9zcGFuPiAg
PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUi
PnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+CjxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+CjxwPlRoZSBjcml0aWNhbCBw
cm9ibGVtIHdpdGggdGhpcywgd2hpY2ggd2Ugd2lzaCBzcGVjaWZpY2FsbHkgdG8gYWRkcmVz
cywgaXMgdGhhdCBhIGZvcndhcmQgZGVjbGFyYXRpb24gb2Ygc3VjaCBhIGZ1bmN0aW9uIGlz
IG5vdCBwb3NzaWJsZS4gV2Ugd291bGQgc2VlIHRoaXMgYXMgZnVydGhlciBqdXN0aWZpY2F0
aW9uIGZvciByZWxheGluZyB0aGUgZXhpc3RpbmcgcHJvaGliaXRpb24sIGFzIHByb3Bvc2Vk
LjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJzaG91bGQtd2UtYWxsb3ct
bmFtZWQtdHlwZXMtZGVmaW5lZC1hcy1yZXR1cm4tdHlwZXMiPgo8aDI+PGEgY2xhc3M9InRv
Yy1iYWNrcmVmIiBocmVmPSIjaWQ4Ij5TaG91bGQgd2UgYWxsb3cgPGVtPm5hbWVkPC9lbT4g
dHlwZXMgZGVmaW5lZCBhcyByZXR1cm4gdHlwZXM/PC9hPjwvaDI+CjxwPkFsbG93aW5nIGJv
dGggbmFtZWQgYW5kIGFub255bW91cyB0eXBlcyBpcyBhIGxvZ2ljYWwgY29uc2VxdWVuY2Ug
b2Ygc2ltcGx5IGxpZnRpbmcgdGhlIGV4aXN0aW5nIFtkY2wuZmN0XS8xMSBwcm9oaWJpdGlv
biBhcyBpdCBpcyBjdXJyZW50bHkgc3RhdGVkLiBJdCBpcyBhbHNvIGNvbnNpc3RlbnQsIGFu
ZCBhbHJlYWR5IHN1cHBvcnRlZCBieSBNU1ZDOjwvcD4KPHByZSBjbGFzcz0iY29kZSBjKysg
bGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJjb21tZW50IHNpbmdsZSI+Ly8gRXF1aXZh
bGVudCB0byBzdHJ1Y3QgUyB7IC4uLiB9OyBTIGZvbygpOwo8L3NwYW4+PHNwYW4gY2xhc3M9
ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlM8L3NwYW4+IDxz
cGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0
aW9uIj4uLi48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigp
Ozwvc3Bhbj4KPC9wcmU+CjxwPlRoYXQgc2FpZCwgdGhlIHZhbHVlIGhlcmUgaXMgbGVzcyBv
YnZpb3VzLCBhbmQgd2Ugd291bGQgZmluZCBpdCBhY2NlcHRhYmxlIHRvIHBlcm1pdCBkZWZp
bml0aW9uIG9mIG9ubHkgYW5vbnltb3VzIHR5cGVzIGFzIHJldHVybiB0eXBlcy48L3A+Cjwv
ZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0iaXNuLXQtdGVtcGxhdGUtcGFyc2luZy1k
aWZmaWN1bHQiPgo8aDI+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVmPSIjaWQ5Ij5Jc24n
dCB0ZW1wbGF0ZSBwYXJzaW5nIGRpZmZpY3VsdD88L2E+PC9oMj4KPHA+QXJ0aHVyIE8nRHd5
ZXIgcG9pbnRlZCBvdXQgdGhpcyBpbnRlcmVzdGluZyBleGFtcGxlOjwvcD4KPHByZSBjbGFz
cz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj50ZW1w
bGF0ZTwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZsdDs8L3NwYW4+PHNwYW4gY2xh
c3M9ImtleXdvcmQiPmNsYXNzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBjbGFzcyI+VDwv
c3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJr
ZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bh
bj4KICAgIDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPnNpemVfdDwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im5hbWUiPnM8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFu
Pgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJjb21t
ZW50IHNpbmdsZSI+Ly8gRGVjbGFyaW5nIGEgdGVtcGxhdGVkIHR5cGUsIHJpZ2h0Pwo8L3Nw
YW4+PHNwYW4gY2xhc3M9Im5hbWUiPndoYXRfc2l6ZTwvc3Bhbj48c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+IDxzcGFuIGNs
YXNzPSJuYW1lIj50PC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KTwvc3Bhbj4g
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogICAgPHNwYW4gY2xhc3M9Imtl
eXdvcmQiPnJldHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFu
PjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zaXplb2Y8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj50PC9zcGFuPjxzcGFuIGNsYXNz
PSJwdW5jdHVhdGlvbiI+KX07PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08
L3NwYW4+CjwvcHJlPgo8cD5JdCBpc24ndCBvYnZpb3VzIHRvIHRoZSBjb21waWxlciwgYW5k
IG5vdCBlc3BlY2lhbGx5IG9idmlvdXMgdG8gcmVhZGVycyBlaXRoZXIsIHRoYXQgdGhpcyBp
cyBhIGRlY2xhcmF0aW9uIG9mIGEgdGVtcGxhdGVkIGZ1bmN0aW9uIHJldHVybmluZyBhbiBh
bm9ueW1vdXMgdHlwZS4gTW9yZW92ZXIsIHdoaWxlIHRoZSB0eXBlIGl0c2VsZiBpcyBub3Qg
dGVtcGxhdGVkLCBwZXItc2UsIGluIGVmZmVjdCBpdCBpcywgYmVjYXVzZSAocHJlc3VtYWJs
eT8pIGVhY2ggZGlmZmVyZW50IGluc3RhbnRpYXRpb24gb2YgdGhlIGZ1bmN0aW9uIHdpbGwg
aGF2ZSBhIGRpc3RpbmN0IHJldHVybiB0eXBlLjwvcD4KPHA+U2luY2UgdGhlIHByaW1hcnkg
bW90aXZhdGlvbiBmb3IgdGhpcyBmZWF0dXJlIGlzIGZvciBmb3J3YXJkIGRlY2xhcmF0aW9u
cyBvZiBmdW5jdGlvbnMgKHBlciBwcmV2aW91cyBxdWVzdGlvbiwgcmV0dXJuaW5nIGFub255
bW91cyB0eXBlcyBpcyBhbHJlYWR5IHBvc3NpYmxlIHdpdGggZGVkdWNlZCByZXR1cm4gdHlw
ZSksIHRoZXJlIGFyZSBmZXdlciB1c2UgY2FzZXMgZm9yIHRoZSBmZWF0dXJlIGluIGNvbmp1
bmN0aW9uIHdpdGggdGVtcGxhdGVkIGZ1bmN0aW9ucy4gQXMgc3VjaCwgYW4gZWFzeSBjb3At
b3V0IGlzIHRvIHJldGFpbiB0aGUgcHJvaGliaXRpb24gaW4gdGhlc2UgY2FzZXM7IHdlIGNh
biBhbHdheXMgZGVjaWRlIHRvIGxpZnQgaXQgbGF0ZXIuPC9wPgo8cD5BbiBhbHRlcm5hdGl2
ZSAod2hpY2ggbWF5IGJlIHdvcnRoIGNvbnNpZGVyaW5nIGZvciBhbGwgY2FzZXMpIGlzIHRv
IHBlcm1pdCBhbm9ueW1vdXMgdHlwZXMgb25seSBpbiB0cmFpbGluZyByZXR1cm4gdHlwZSBz
cGVjaWZpY2F0aW9ucywgYXMgZm9sbG93czo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxp
dGVyYWwtYmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+YXV0bzwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4tJmd0Ozwv
c3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9
InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwv
c3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59Ozwvc3Bhbj4KPHNwYW4gY2xhc3M9
ImtleXdvcmQiPnRlbXBsYXRlPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwv
c3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPi4uLjwvc3Bhbj48c3BhbiBjbGFzcz0i
b3BlcmF0b3IiPiZndDs8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5hdXRvPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibmFtZSI+YmFyPC9zcGFuPiA8c3BhbiBjbGFzcz0ib3BlcmF0b3Ii
Pi0mZ3Q7PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+Li4uPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9zcGFuPgo8L3By
ZT4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJpcy1kZWNsdHlwZS1yZXR1cm4t
ZGFuZ2Vyb3VzIj4KPGgyPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkMTAiPklz
IDxjb2RlIGNsYXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVjbHR5cGU8L3Nw
YW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3
b3JkIj5yZXR1cm48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPjwv
Y29kZT4gZGFuZ2Vyb3VzPzwvYT48L2gyPgo8cD48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVy
bmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMjI0Ij5QMDIyNDwvYT4gcHJldmlvdXNs
eSByZWNvbW1lbmRlZCBvdmVybG9hZGluZyA8Y29kZSBjbGFzcz0iY3BwIGMrKyI+PHNwYW4g
Y2xhc3M9ImtleXdvcmQiPmF1dG88L3NwYW4+PC9jb2RlPiBhcyBhIG1lY2hhbmlzbSBmb3Ig
aW1wbGljaXRseSBuYW1pbmcgdGhlIHJldHVybiB0eXBlIGdpdmVuIGEgcHJpb3IgZGVjbGFy
YXRpb24uIFdoaWxlIHdlIGJlbGlldmUgdGhpcyBhcHByb2FjaCBpcyBmZWFzaWJsZSwgdGhl
cmUgd2VyZSBzb21lIHBvdGVudGlhbCBpc3N1ZXMsIHdoaWNoIGFyZSBkaXNjdXNzZWQgaW4g
PGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9w
MDIyNCI+UDAyMjQ8L2E+LiBXaGlsZSB3ZSB3b3VsZCBoYXBwaWx5IGFjY2VwdCB0aGUgc29s
dXRpb24gcHJvcG9zZWQgYnkgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0i
aHR0cDovL3dnMjEubGluay9wMDIyNCI+UDAyMjQ8L2E+LCB3ZSBmZWVsIHRoYXQgPGNvZGUg
Y2xhc3M9ImNwcCBjKysiPjxzcGFuIGNsYXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJl
dHVybjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2RlPiBp
cyBsZXNzIGFtYmlndW91cywgYm90aCB0byByZWFkZXJzIGFuZCB0byBjb21waWxlcnMuIEl0
IGlzIHNsaWdodGx5IG1vcmUgdmVyYm9zZSB0aGFuIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48
c3BhbiBjbGFzcz0ia2V5d29yZCI+YXV0bzwvc3Bhbj48L2NvZGU+LCBidXQgbm90IHNvIG11
Y2ggdGhhdCB3ZSBmZWVsIHRoZSBhZGRlZCB2ZXJib3NpdHkgaXMgYW4gaXNzdWUgaW4gdGhv
c2UgY2FzZXMgd2hlcmUgd2UgZXhwZWN0IGl0IHRvIGJlIHVzZWQsIGFuZCB0aGUgZXh0cmEg
dmVyYm9zaXR5IG1heSBzZXJ2ZSB0byBkZXRlciAmcXVvdDtmcml2b2xvdXMmcXVvdDsgdXNl
LiBQYXJ0aWN1bGFybHksIHRoZXJlIGlzIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBp
bmZlcnJlZCByZXR1cm4gdmFsdWVzICh0aGUgdHJhZGl0aW9uYWwgdXNlIG9mIDxjb2RlIGNs
YXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ia2V5d29yZCI+YXV0bzwvc3Bhbj48L2NvZGU+
IGFzIGEgcmV0dXJuIHR5cGUpIGFuZCAmcXVvdDtpbXBsaWVkJnF1b3Q7IHJldHVybiB2YWx1
ZXMgKHRoYXQgaXMsIHRoZSB1c2Ugb2YgPGNvZGUgY2xhc3M9ImNwcCBjKysiPjxzcGFuIGNs
YXNzPSJuYW1lIj5kZWNsdHlwZTwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPig8
L3NwYW4+PHNwYW4gY2xhc3M9ImtleXdvcmQiPnJldHVybjwvc3Bhbj48c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPik8L3NwYW4+PC9jb2RlPiBhcyBhbiBhbHRlcm5hdGUgc3BlbGxpbmcg
b2YgYSBwcmV2aW91c2x5IGRlY2xhcmVkIHJldHVybiB0eXBlKS48L3A+CjwvZGl2Pgo8ZGl2
IGNsYXNzPSJzZWN0aW9uIiBpZD0id2hhdC1hYm91dC1kZWZpbmluZy10eXBlcy1pbi1mdW5j
dGlvbi1wb2ludGVyLXR5cGVzIj4KPGgyPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0i
I2lkMTEiPldoYXQgYWJvdXQgZGVmaW5pbmcgdHlwZXMgaW4gZnVuY3Rpb24gcG9pbnRlciB0
eXBlcz88L2E+PC9oMj4KPHA+QW4gb2J2aW91cyBjb25zZXF1ZW5jZSBvZiByZWxheGluZyBb
ZGNsLmZjdF0vMTEgaXMgdGhlIGRlc2lyZSB0byBwZXJtaXQgZnVuY3Rpb24gcG9pbnRlcnMg
d2hpY2ggcmV0dXJuIGFuIGFub255bW91cyBzdHJ1Y3QuIEZvciBleGFtcGxlOjwvcD4KPHBy
ZSBjbGFzcz0iY29kZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJjb21tZW50
IHNpbmdsZSI+Ly8gRGVjbGFyZSBhIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZSB3aGljaCByZXR1
cm5zIGFuIGFub255bW91cyBzdHJ1Y3QKPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj51
c2luZzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlJldHVybnNBbm9ueW1vdXNTdHJ1Y3Q8
L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9Imtl
eXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFu
PiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBlIj5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJu
YW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+KDwvc3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPio8L3NwYW4+PHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj4pKCk7PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2lu
Z2xlIj4vLyBEZWZpbmUgYSBmdW5jdGlvbiB1c2luZyB0aGUgc2FtZQo8L3NwYW4+PHNwYW4g
Y2xhc3M9ImtleXdvcmQgdHlwZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5j
dGlvbiI+YmFyPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KDwvc3Bhbj48c3Bh
biBjbGFzcz0ibmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVjdDwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im5hbWUiPmY8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPiA8
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3Jk
Ij5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCg8L3NwYW4+PHNw
YW4gY2xhc3M9Im9wZXJhdG9yIj4qPC9zcGFuPjxzcGFuIGNsYXNzPSJuYW1lIj5mPC9zcGFu
PjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KSgpKS48L3NwYW4+PHNwYW4gY2xhc3M9Im5h
bWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+IDxz
cGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KCjxzcGFuIGNsYXNzPSJjb21tZW50
IHNpbmdsZSI+Ly8gUHJvdmlkZSBhIG1lY2hhbmlzbSB0byBvYnRhaW4gdGhlIHJldHVybiB0
eXBlIG9mIGEgZnVuY3Rpb24KPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj50ZW1wbGF0
ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mbHQ7PC9zcGFuPjxzcGFuIGNsYXNz
PSJrZXl3b3JkIj50eXBlbmFtZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+
PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mZ3Q7PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29y
ZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuVHlwZTwvc3Bhbj48
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPjs8L3NwYW4+Cgo8c3BhbiBjbGFzcz0ia2V5d29y
ZCI+dGVtcGxhdGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Jmx0Ozwvc3Bhbj48
c3BhbiBjbGFzcz0ia2V5d29yZCI+dHlwZW5hbWU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1l
Ij5UPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+LDwvc3Bhbj4gPHNwYW4gY2xh
c3M9ImtleXdvcmQiPnR5cGVuYW1lPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+
Li4uPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+QXJnczwvc3Bhbj48c3BhbiBjbGFzcz0i
b3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJv
cGVyYXRvciI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+VDwvc3Bhbj4gPHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Kjwv
c3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPikoPC9zcGFuPjxzcGFuIGNsYXNzPSJu
YW1lIj5BcmdzPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uKTwvc3Bhbj48
c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZndDs8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+ezwvc3Bhbj4KICAgIDxzcGFuIGNsYXNzPSJrZXl3b3JkIj51c2luZzwvc3Bhbj4g
PHNwYW4gY2xhc3M9ImtleXdvcmQgdHlwZSI+cmVzdWx0X3Q8L3NwYW4+IDxzcGFuIGNsYXNz
PSJvcGVyYXRvciI+PTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPlQ8L3NwYW4+PHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pn07PC9zcGFuPgoKPHNwYW4gY2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBEZWNsYXJlIGEg
ZnVuY3Rpb24gdGhhdCBpcyBhIFJldHVybnNBbm9ueW1vdXNTdHJ1Y3QKPC9zcGFuPjxzcGFu
IGNsYXNzPSJuYW1lIj5SZXR1cm5UeXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+
Jmx0Ozwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+UmV0dXJuc0Fub255bW91c1N0cnVjdDwv
c3Bhbj48c3BhbiBjbGFzcz0ib3BlcmF0b3IiPiZndDs6Ojwvc3Bhbj48c3BhbiBjbGFzcz0i
a2V5d29yZCB0eXBlIj5yZXN1bHRfdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwv
c3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPigpPC9zcGFuPiA8c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3Nw
YW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj48c3BhbiBjbGFzcz0ibGl0
ZXJhbCBudW1iZXIgaW50ZWdlciI+MDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pn07PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+Cgo8c3BhbiBj
bGFzcz0iY29tbWVudCBzaW5nbGUiPi8vIFVzZSB0aGUgZnVuY3Rpb24KPC9zcGFuPjxzcGFu
IGNsYXNzPSJrZXl3b3JkIHR5cGUiPmludDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPm1h
aW48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgogICAgPHNwYW4gY2xhc3M9ImtleXdvcmQiPnJl
dHVybjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPmJhcjwvc3Bhbj48c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPig8L3NwYW4+PHNwYW4gY2xhc3M9Im9wZXJhdG9yIj4mYW1wOzwvc3Bh
bj48c3BhbiBjbGFzcz0ibmFtZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlv
biI+KTs8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bhbj4KPC9wcmU+
CjxwPkl0IGlzIG91ciBvcGluaW9uIHRoYXQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXJlIHN1
ZmZpY2llbnQgdG8gYWxsb3cgdGhlIGFib3ZlLiAoSW4gZmFjdCwgdGhpcyBleGFtcGxlIGlz
IGFscmVhZHkgYWNjZXB0ZWQgYnkgYm90aCBHQ0MgYW5kIElDQywgYWx0aG91Z2ggaXQgaXMg
cmVqZWN0ZWQgYnkgY2xhbmcgcGVyIFtkY2wuZmN0XS8xMS4pIEFjY29yZGluZ2x5LCB3ZSBm
ZWVsIHRoYXQgdGhpcyBwcm9wb3NhbCBzaG91bGQgYmUgdW5kZXJzdG9vZCBhcyBpbnRlbmRp
bmcgdG8gYWxsb3cgdGhlIGFib3ZlIGV4YW1wbGUgYW5kIHRoYXQgYWRkaXRpb25hbCB3b3Jk
aW5nIGNoYW5nZXMgdG8gc3BlY2lmeSB0aGlzIGJlaGF2aW9yIGFyZSBub3QgcmVxdWlyZWQg
YXQgdGhpcyB0aW1lLjwvcD4KPC9kaXY+CjxkaXYgY2xhc3M9InNlY3Rpb24iIGlkPSJ3aGF0
LWFib3V0LWRlZmluaW5nLXR5cGVzLWluLXBhcmFtZXRlci10eXBlcyI+CjxoMj48YSBjbGFz
cz0idG9jLWJhY2tyZWYiIGhyZWY9IiNpZDEyIj5XaGF0IGFib3V0IGRlZmluaW5nIHR5cGVz
IGluIHBhcmFtZXRlciB0eXBlcz88L2E+PC9oMj4KPHA+QW4gb2J2aW91cyBmb2xsb3ctb24g
cXVlc3Rpb24gaXMsIHNob3VsZCB3ZSBhbHNvIGxpZnQgdGhlIHByb2hpYml0aW9uIGFnYWlu
c3QgdHlwZXMgZGVmaW5lZCBpbiBwYXJhbWV0ZXIgc3BlY2lmaWNhdGlvbnM/IFRoZXJlIGhh
dmUgYmVlbiBzdWdnZXN0aW9ucyBmbG9hdGVkIHRvIGltcGxlbWVudCB0aGUgbXVjaCByZXF1
ZXN0ZWQgbmFtZWQgcGFyYW1ldGVycyBpbiBzb21ldGhpbmcgbGlrZSB0aGlzIG1hbm5lci4g
SG93ZXZlciwgdGhlcmUgYXJlIHNpZ25pZmljYW50IChpbiBvdXIgb3BpbmlvbikgcmVhc29u
cyB0byBub3QgYWRkcmVzcyB0aGlzLCBhdCBsZWFzdCBpbml0aWFsbHkuIEZpcnN0LCBpdCBp
cyB3aWRlbHkgY29udGVzdGVkIHRoYXQgdGhpcyBpcyBub3QgYW4gb3B0aW1hbCBzb2x1dGlv
biB0byB0aGUgcHJvYmxlbSAobmFtZWQgcGFyYW1ldGVycykgaW4gdGhlIGZpcnN0IHBsYWNl
LiBTZWNvbmQsIGl0IGRlcGVuZHMgb24gbmFtZWQgaW5pdGlhbGl6ZXJzLCB3aGljaCBpcyBh
biBhcmVhIG9mIG9uZ29pbmcgd29yay4gVGhpcmQsIHRoaXMgcHJvcG9zYWwgd29ya3MgbGFy
Z2VseSBiZWNhdXNlIEMrKyBmb3JiaWRzIG92ZXJsb2FkaW5nIG9uIHJldHVybiB0eXBlLCB3
aGljaCBtYXkgYmUgbGV2ZXJhZ2VkIHRvIGVsaW1pbmF0ZSBhbnkgYW1iaWd1aXR5IGFzIHRv
IHRoZSBkZWR1Y3Rpb24gb2YgdGhlIGFjdHVhbCB0eXBlIG9mIDxjb2RlIGNsYXNzPSJjcHAg
YysrIj48c3BhbiBjbGFzcz0ibmFtZSI+ZGVjbHR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9InB1
bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+
PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4pPC9zcGFuPjwvY29kZT4uIFRoaXMgaXMgbm90
IHRoZSBjYXNlIGZvciBwYXJhbWV0ZXJzOyB0aGUgYWJpbGl0eSB0byBvdmVybG9hZCBmdW5j
dGlvbnMgd291bGQgbWFrZSBhIHNpbWlsYXIgY2hhbmdlIGZvciBwYXJhbWV0ZXJzIG11Y2gg
bW9yZSBjb21wbGljYXRlZC48L3A+CjxwPldoaWxlIHdlIGRvIG5vdCB3aXNoIHRvIGNhdGVn
b3JpY2FsbHkgcnVsZSBvdXQgZnV0dXJlIGNoYW5nZXMgaW4gdGhpcyBkaXJlY3Rpb24sIHdl
IGZlZWwgdGhhdCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgZm9yIHRoaXMgcHJvcG9zYWwgdG8g
YXR0ZW1wdCB0byBhZGRyZXNzIHRoZXNlIGlzc3Vlcy48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNz
PSJzZWN0aW9uIiBpZD0id2hhdC1hYm91dC1wYXNzLXRocm91Z2gtb2YtcmV0dXJuLXZhbHVl
cy1oYXZpbmctZXF1aXZhbGVudC10eXBlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYi
IGhyZWY9IiNpZDEzIj5XaGF0IGFib3V0ICZxdW90O3Bhc3MtdGhyb3VnaCZxdW90OyBvZiBy
ZXR1cm4gdmFsdWVzIGhhdmluZyBlcXVpdmFsZW50IHR5cGVzPzwvYT48L2gyPgo8cD5Bbm90
aGVyIHF1ZXN0aW9uIHRoYXQgaGFzIGNvbWUgdXAgaXMgaWYgc29tZXRoaW5nIGxpa2UgdGhp
cyBzaG91bGQgYmUgYWxsb3dlZDo8L3A+CjxwcmUgY2xhc3M9ImNvZGUgYysrIGxpdGVyYWwt
YmxvY2siPgo8c3BhbiBjbGFzcz0ia2V5d29yZCI+c3RydWN0PC9zcGFuPiA8c3BhbiBjbGFz
cz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJrZXl3b3JkIHR5cGUiPmlu
dDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im5hbWUiPnJlc3VsdDwvc3Bhbj48c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPjs8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+fTwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPigpPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+Li4uPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRp
b24iPn08L3NwYW4+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5zdHJ1Y3Q8L3NwYW4+IDxzcGFu
IGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9ImtleXdvcmQgdHlw
ZSI+aW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+cmVzdWx0PC9zcGFuPjxzcGFuIGNs
YXNzPSJwdW5jdHVhdGlvbiI+Ozwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFtZSI+YmFyPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+KCk8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bhbj4K
ICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0ibmFt
ZSI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+KCk7PC9zcGFuPgo8c3Bh
biBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8cD5TcGVjaWZpY2FsbHks
IG90aGVycyBoYXZlIGV4cHJlc3NlZCBhbiBpbnRlcmVzdCBpbiB0cmVhdGluZyBsYXlvdXQt
Y29tcGF0aWJsZSB0eXBlcyBhcyBlcXVpdmFsZW50IChvciBhdCBsZWFzdCwgaW1wbGljaXRs
eSBjb252ZXJ0aWJsZSksIHBhcnRpY3VsYXJseSBpbiB0aGUgY29udGV4dCBvZiByZXR1cm4g
dmFsdWVzIGFzIGluIHRoZSBhYm92ZSBleGFtcGxlLjwvcD4KPHA+VW5kZXIgdGhlIGN1cnJl
bnQgcnVsZXMgKHBsdXMgcmVsYXhlZCBbZGNsLmZjdF0vMTEpLCB0aGVzZSB0d28gZGVmaW5p
dGlvbnMgaGF2ZSBkaWZmZXJlbnQgcmV0dXJuIHR5cGVzIHdoaWNoIGFyZSBub3QgY29udmVy
dGlibGUuIEl0IGlzIG91ciBvcGluaW9uIHRoYXQgdGhlIHJ1bGVzIG1ha2luZyB0aGVzZSB0
eXBlcyBkaWZmZXJlbnQgYXJlIGluIGZhY3QgY29ycmVjdCBhbmQgZGVzaXJhYmxlLCBhbmQg
dGhpcyBwcm9wb3NhbCBzcGVjaWZpY2FsbHkgZG9lcyA8ZW0+bm90PC9lbT4gaW5jbHVkZSBh
bnkgY2hhbmdlcyB3aGljaCB3b3VsZCBtYWtlIHRoZSB0eXBlcyBjb21wYXRpYmxlLiBUaGF0
IHNhaWQsIHdlIG5vdGUgdGhhdCA8YSBocmVmPSIjaWQyMSI+PHNwYW4gY2xhc3M9InByb2Js
ZW1hdGljIiBpZD0iaWQyMiI+RklYTUVfPC9zcGFuPjwvYT4gcHJvdmlkZXMgYSByZWFkeSBz
b2x1dGlvbiB0byB0aGlzIHByb2JsZW06PC9wPgo8cHJlIGNsYXNzPSJjb2RlIGMrKyBsaXRl
cmFsLWJsb2NrIj4KPHNwYW4gY2xhc3M9ImtleXdvcmQiPnN0cnVjdDwvc3Bhbj4gPHNwYW4g
Y2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPiA8c3BhbiBjbGFzcz0ia2V5d29yZCB0eXBl
Ij5pbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5yZXN1bHQ8L3NwYW4+PHNwYW4gY2xh
c3M9InB1bmN0dWF0aW9uIj47PC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08
L3NwYW4+IDxzcGFuIGNsYXNzPSJuYW1lIj5iYXI8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0
dWF0aW9uIj4oKTwvc3Bhbj4KPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj57PC9zcGFuPgog
IDxzcGFuIGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5j
dHVhdGlvbiI+ezwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj5bPC9zcGFuPjxz
cGFuIGNsYXNzPSJvcGVyYXRvciI+Ojwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24i
Pl08L3NwYW4+PHNwYW4gY2xhc3M9Im5hbWUiPmZvbzwvc3Bhbj48c3BhbiBjbGFzcz0icHVu
Y3R1YXRpb24iPigpLi4uPC9zcGFuPiA8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn07PC9z
cGFuPgo8c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8L2Rpdj4K
PGRpdiBjbGFzcz0ic2VjdGlvbiIgaWQ9ImRvZXMtdGhpcy1jb25mbGljdHMtd2l0aC1mdXR1
cmUtdHJ1ZS1tdWx0aXBsZS1yZXR1cm4tdmFsdWVzIj4KPGgyPjxhIGNsYXNzPSJ0b2MtYmFj
a3JlZiIgaHJlZj0iI2lkMTQiPkRvZXMgdGhpcyBjb25mbGljdHMgd2l0aCBmdXR1cmUgJnF1
b3Q7dHJ1ZSZxdW90OyBtdWx0aXBsZSByZXR1cm4gdmFsdWVzPzwvYT48L2gyPgo8cD5UaGVy
ZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gb2YgJnF1b3Q7dHJ1ZSZxdW90OyBtdWx0aXBs
ZSByZXR1cm4gdmFsdWVzLCBpbiBwYXJ0aWN1bGFyIHdpdGggcmVzcGVjdCB0byBSVk8gYW5k
IHNpbWlsYXIgaXNzdWVzLiBJbiBwYXJ0aWN1bGFyLCBzb21lIGZlYXR1cmVzIHByb3Bvc2Vk
IGJ5IDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxp
bmsvcDAzNDEiPlAwMzQxPC9hPiBhcmUgdmVyeSBtdWNoIGluIHRoaXMgdmVpbi4gQSBwb2lu
dCB0aGF0IGJlYXJzIGNvbnNpZGVyYXRpb24gaXMgaWYgbW92aW5nIGRvd24gdGhlIHBhdGgg
b2YgdXNpbmcgYW5vbnltb3VzIChvciBub3QpIHN0cnVjdHMgZm9yIG11bHRpcGxlIHJldHVy
biB2YWx1ZXMgd2lsbCAmcXVvdDtwYWludCB1cyBpbnRvIGEgY29ybmVyJnF1b3Q7IHdoZXJl
IGZ1dHVyZSBvcHRpbWl6YXRpb24gcG90ZW50aWFsIGlzIHByZW1hdHVyZWx5IGVsaW1pbmF0
ZWQuPC9wPgo8cD5JdCBpcyBvdXIgaG9wZSB0aGF0IHRoZXNlIGlzc3VlcyBjYW4gYmUgYWRk
cmVzc2VkIHdpdGggZXhpc3RpbmcgY29tcG91bmQgdHlwZXMgKHdoaWNoIHdpbGwgaGF2ZSBm
dXJ0aGVyIHJlYWNoaW5nIGJlbmVmaXQpLiBNb3Jlb3ZlciwgYXMgcHJldmlvdXNseSBzdGF0
ZWQsIHRoZSB1c2Ugb2YgY29tcG91bmQgdHlwZXMgZm9yIG11bHRpcGxlIHJldHVybiB2YWx1
ZXMgdXNlcyBleGlzdGluZyB0ZWNobmlxdWVzIGFuZCBpcyB3ZWxsIHVuZGVyc3Rvb2QsIHdo
ZXJlYXMgaW50cm9kdWNpbmcgJnF1b3Q7Zmlyc3QgY2xhc3MmcXVvdDsgbXVsdGlwbGUgcmV0
dXJuIHZhbHVlcyBpbnRyb2R1Y2VzIHF1ZXN0aW9ucyBvZiBBQkkgYW5kIG90aGVyIGlzc3Vl
cy48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0id2hhdC1hYm91dC1kZWR1
Y2VkLXJldHVybi10eXBlcyI+CjxoMj48YSBjbGFzcz0idG9jLWJhY2tyZWYiIGhyZWY9IiNp
ZDE1Ij5XaGF0IGFib3V0IGRlZHVjZWQgcmV0dXJuIHR5cGVzPzwvYT48L2gyPgo8cD5UaGlz
IGZlYXR1cmUgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBkZWR1Y2VkIHJldHVybiB0eXBlcyBh
dCB0aGlzIHRpbWUuIEluIGxpZ2h0IG9mIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwi
IGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAzMjkiPlAwMzI5PC9hPiwgaXQgbWlnaHQgYmUg
cG9zc2libGUgdG8gbGlmdCB0aGlzIHJlc3RyaWN0aW9uOjwvcD4KPHByZSBjbGFzcz0iY29k
ZSBjKysgbGl0ZXJhbC1ibG9jayI+CjxzcGFuIGNsYXNzPSJrZXl3b3JkIj5hdXRvPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibmFtZSBmdW5jdGlvbiI+Zm9vPC9zcGFuPjxzcGFuIGNsYXNzPSJw
dW5jdHVhdGlvbiI+KCk8L3NwYW4+CjxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+ezwvc3Bh
bj4KICA8c3BhbiBjbGFzcz0ia2V5d29yZCI+cmV0dXJuPC9zcGFuPiA8c3BhbiBjbGFzcz0i
cHVuY3R1YXRpb24iPns8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVhdGlvbiI+Ljwvc3Bh
bj48c3BhbiBjbGFzcz0ibmFtZSI+eDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im9wZXJhdG9yIj49
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibGl0ZXJhbCBudW1iZXIgaW50ZWdlciI+Mzwvc3Bhbj48
c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPiw8L3NwYW4+IDxzcGFuIGNsYXNzPSJwdW5jdHVh
dGlvbiI+Ljwvc3Bhbj48c3BhbiBjbGFzcz0ibmFtZSI+eTwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im9wZXJhdG9yIj49PC9zcGFuPiA8c3BhbiBjbGFzcz0ibGl0ZXJhbCBudW1iZXIgaW50ZWdl
ciI+Mjwvc3Bhbj4gPHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj59Ozwvc3Bhbj4gPHNwYW4g
Y2xhc3M9ImNvbW1lbnQgc2luZ2xlIj4vLyBkZWR1Y2U6IHN0cnVjdCB7IGludCB4LCB5OyB9
Cjwvc3Bhbj48c3BhbiBjbGFzcz0icHVuY3R1YXRpb24iPn08L3NwYW4+CjwvcHJlPgo8cD5I
b3dldmVyLCB3ZSBoYXZlIHJlc2VydmF0aW9ucyBhYm91dCBhbGxvd2luZyB0aGlzLCBhbmQg
ZG8gbm90IGF0IHRoaXMgdGltZSBwcm9wb3NlIHRoYXQgdGhpcyBleGFtcGxlIHdvdWxkIGJl
IHdlbGwtZm9ybWVkLjwvcD4KPC9kaXY+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBp
ZD0iZnV0dXJlLWRpcmVjdGlvbnMiPgo8aDE+PGEgY2xhc3M9InRvYy1iYWNrcmVmIiBocmVm
PSIjaWQxNiI+RnV0dXJlIERpcmVjdGlvbnM8L2E+PC9oMT4KPHA+SW4gdGhlIDxhIGNsYXNz
PSJyZWZlcmVuY2UgaW50ZXJuYWwiIGhyZWY9IiNkaXNjdXNzaW9uIj5EaXNjdXNzaW9uPC9h
PiBzZWN0aW9uIGFib3ZlLCB3ZSBwcmVzZW50ZWQgYSB1dGlsaXR5IGZvciBleHRyYWN0aW5n
IHRoZSByZXR1cm4gdHlwZSBmcm9tIGEgZnVuY3Rpb24gcG9pbnRlciB0eXBlLiBUaGUgZmFj
aWxpdHkgYXMgcHJlc2VudGVkIGhhcyBzaWduaWZpY2FudCBsaW1pdGF0aW9uczsgbmFtZWx5
LCBpdCBkb2VzIG5vdCB3b3JrIG9uIG1lbWJlciBmdW5jdGlvbnMgYW5kIHRoZSBzZXZlcmFs
IHZhcmlhdGlvbnMgKGUuZy4gQ1YtcXVhbGlmaWNhdGlvbikgd2hpY2ggYXBwbHkgdG8gdGhl
IHNhbWUuIFdlIGRvIG5vdCBoZXJlIHByb3Bvc2UgYSBzdGFuZGFyZCBsaWJyYXJ5IGltcGxl
bWVudGF0aW9uIG9mIHRoaXMgZmFjaWxpdHksIHdoaWNoIHByZXN1bWFibHkgd291bGQgY292
ZXIgdGhlc2UgY2FzZXMsIGhvd2V2ZXIgdGhlcmUgaXMgcm9vbSB0byBpbWFnaW5lIHRoYXQg
c3VjaCBhIGZhY2lsaXR5IGNvdWxkIGJlIHVzZWZ1bCwgZXNwZWNpYWxseSBpZiB0aGUgcHJv
cG9zYWxzIHdlIHByZXNlbnQgaGVyZSBhcmUgYWRvcHRlZC4gKERhdmlkIEtyYXVzcyBwb2lu
dHMgb3V0IHRoYXQgPHR0IGNsYXNzPSJkb2N1dGlscyBsaXRlcmFsIj48c3BhbiBjbGFzcz0i
cHJlIj5zdGQ6OnJlZmVyZW5jZV93cmFwcGVyPC9zcGFuPjwvdHQ+IGNhbiBiZSB1c2VkIHRv
IHNpbWlsYXIgZWZmZWN0Li4uIG9uIDxlbT5zb21lPC9lbT4gY29tcGlsZXJzLiBIb3dldmVy
LCBpbXBlcmZlY3QgcG9ydGFiaWxpdHkgYW5kIHRoZSBkaXNwYXJpdHkgYmV0d2VlbiBpbnRl
bmRlZCBmdW5jdGlvbiBhbmQgdXNlIGZvciB0aGlzIHJlc3VsdCBzdWdnZXN0IHRoYXQgdGhp
cyBpcyBub3QgdGhlIG9wdGltYWwgZmFjaWxpdHkgZm9yIHRoZSBwcm9ibGVtLik8L3A+Cjxw
PkFub3RoZXIgY29uc2lkZXJhdGlvbiB0aGF0IHNlZW1zIGxpa2VseSB0byBjb21lIHVwIGlz
IGlmIHdlIHNob3VsZCBmdXJ0aGVyIHNpbXBsaWZ5IHRoZSBzeW50YXggZm9yIHJldHVybmlu
ZyBtdWx0aXBsZSB2YWx1ZXMgKGNvbmNlaXZhYmx5LCB0aGlzIGNvdWxkIGFwcGx5IHRvIGJv
dGggYW5vbnltb3VzIHN0cnVjdHMgYW5kIHRvIDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0ZXJh
bCI+PHNwYW4gY2xhc3M9InByZSI+c3RkOjpwYWlyPC9zcGFuPjwvdHQ+IC8gPHR0IGNsYXNz
PSJkb2N1dGlscyBsaXRlcmFsIj48c3BhbiBjbGFzcz0icHJlIj5zdGQ6OnR1cGxlPC9zcGFu
PjwvdHQ+KS4gU29tZSBoYXZlIHN1Z2dlc3RlZCBhbGxvd2luZyB0aGF0IHRoZSA8dHQgY2xh
c3M9ImRvY3V0aWxzIGxpdGVyYWwiPnN0cnVjdDwvdHQ+IGtleXdvcmQgbWF5IGJlIG9taXR0
ZWQuIEluIGxpZ2h0IG9mIDxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0
dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUv
cDAxNTFyMC5wZGYiPlAwMTUxPC9hPiBhbmQgPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5h
bCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDM0MSI+UDAzNDE8L2E+LCB3ZSBjYW4gY29u
Y2VpdmUgdGhhdCBhbGxvd2luZyB0aGUgc3ludGF4IDx0dCBjbGFzcz0iZG9jdXRpbHMgbGl0
ZXJhbCI+Jmx0O2ludCB4LCBkb3VibGUgeSZndDsgZm9vKCk8L3R0PiBtaWdodCBiZSBpbnRl
cmVzdGluZyAoaW4gY29udHJhc3QgdG8gPGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIg
aHJlZj0iaHR0cDovL3dnMjEubGluay9wMDM0MSI+UDAzNDE8L2E+LCB3ZSB3b3VsZCBzdWdn
ZXN0IHRoYXQgdGhpcyBiZSBzaG9ydGhhbmQgZm9yIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48
c3BhbiBjbGFzcz0ibmFtZSI+c3RkPC9zcGFuPjxzcGFuIGNsYXNzPSJvcGVyYXRvciI+Ojo8
L3NwYW4+PHNwYW4gY2xhc3M9Im5hbWUiPnR1cGxlPC9zcGFuPjwvY29kZT4pLiBBdCB0aGlz
IHRpbWUsIHdlIHByZWZlciB0byBmb2N1cyBvbiB0aGUgZmVhdHVyZSBoZXJlIHByZXNlbnRl
ZCByYXRoZXIgdGhhbiByaXNrIG92ZXJleHRlbmRpbmcgdGhlIHJlYWNoIG9mIHRoaXMgcHJv
cG9zYWwuIEhvd2V2ZXIsIGlmIHRoaXMgcHJvcG9zYWwgaXMgYWNjZXB0ZWQsIGl0IHJlcHJl
c2VudHMgYW4gb2J2aW91cyBmaXJzdCBzdGVwIHRvIGNvbnNpZGVyaW5nIHN1Y2ggZmVhdHVy
ZXMgaW4gdGhlIGZ1dHVyZS48L3A+CjxwPkEgZmluYWwgY29uc2lkZXJhdGlvbiBpcyB0aGUg
ZXh0ZW5zaW9uIG9mIDxjb2RlIGNsYXNzPSJjcHAgYysrIj48c3BhbiBjbGFzcz0ibmFtZSI+
ZGVjbHR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9uIj4oPC9zcGFuPjxzcGFu
IGNsYXNzPSJrZXl3b3JkIj5yZXR1cm48L3NwYW4+PHNwYW4gY2xhc3M9InB1bmN0dWF0aW9u
Ij4pPC9zcGFuPjwvY29kZT4gdG8gYWxsb3cgdXNlIHdpdGhpbiBhIGZ1bmN0aW9uIGJvZHku
IEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIHdlIGFyZSBub3QgYXdhcmUgb2YgYSBwcm9wb3Nh
bCB0byBkbyBzbywgYWx0aG91Z2ggdGhlIGlkZWEgaGFzIGJlZW4gZmxvYXRlZCBvbiBudW1l
cm91cyBvY2Nhc2lvbnMuIFdlIHdvdWxkIGhvcGUgdG8gc2VlIHN1Y2ggYW4gYWRkaXRpb24s
IHdoaWNoIGNhbiBiZSBvcnRob2dvbmFsIHRvIHRoaXMgcHJvcG9zYWwsIGluIHRoZSBuZWFy
IGZ1dHVyZS48L3A+CjwvZGl2Pgo8ZGl2IGNsYXNzPSJzZWN0aW9uIiBpZD0iYWNrbm93bGVk
Z21lbnRzIj4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3JlZiIgaHJlZj0iI2lkMTciPkFja25v
d2xlZGdtZW50czwvYT48L2gxPgo8cD5XZSB3aXNoIHRvIHRoYW5rIGV2ZXJ5b25lIG9uIHRo
ZSA8dHQgY2xhc3M9ImRvY3V0aWxzIGxpdGVyYWwiPjxzcGFuIGNsYXNzPSJwcmUiPnN0ZC1w
cm9wb3NhbHM8L3NwYW4+PC90dD4gZm9ydW0sIGVzcGVjaWFsbHkgQmVuZ3QgR3VzdGFmc3Nv
biwgQXJ0aHVyIE8nRHd5ZXIgYW5kIFIuICZxdW90O1RpbSZxdW90OyBTb25nLCBmb3IgdGhl
aXIgdmFsdWFibGUgZmVlZGJhY2sgYW5kIGluc2lnaHRzLjwvcD4KPC9kaXY+CjxkaXYgY2xh
c3M9InNlY3Rpb24iIGlkPSJyZWZlcmVuY2VzIj4KPGgxPjxhIGNsYXNzPSJ0b2MtYmFja3Jl
ZiIgaHJlZj0iI2lkMTgiPlJlZmVyZW5jZXM8L2E+PC9oMT4KPHVsPgo8bGk+PHAgY2xhc3M9
ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cy
MS5saW5rL240NjE4Ij5ONDYxODwvYT4gV29ya2luZyBEcmFmdCwgU3RhbmRhcmQgZm9yIFBy
b2dyYW1taW5nIExhbmd1YWdlIEMrKzwvcD4KPHA+PGEgY2xhc3M9InJlZmVyZW5jZSBleHRl
cm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9uNDYxOCI+aHR0cDovL3dnMjEubGluay9u
NDYxODwvYT48L3A+CjwvbGk+CjwvdWw+Cjx1bD4KPGxpPjxwIGNsYXNzPSJmaXJzdCI+PGEg
Y2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5v
cmcvanRjMS9zYzIyL3dnMjEvZG9jcy9wYXBlcnMvMjAxNS9uNDU2MC5wZGYiPk40NTYwPC9h
PiBFeHRlbnNpb25zIGZvciBSYW5nZXM8L3A+CjxwPjxhIGNsYXNzPSJyZWZlcmVuY2UgZXh0
ZXJuYWwiIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2Rv
Y3MvcGFwZXJzLzIwMTUvbjQ1NjAucGRmIj5odHRwOi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMx
L3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDE1L240NTYwLnBkZjwvYT48L3A+CjwvbGk+Cjwv
dWw+Cjx1bD4KPGxpPjxwIGNsYXNzPSJmaXJzdCI+PGEgY2xhc3M9InJlZmVyZW5jZSBleHRl
cm5hbCIgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9j
cy9wYXBlcnMvMjAxNS9wMDE1MXIwLnBkZiI+UDAxNTE8L2E+IFByb3Bvc2FsIG9mIE11bHRp
LURlY2xhcmF0b3JzIChha2EgU3RydWN0dXJlZCBCaW5kaW5ncyk8L3A+CjxwPjxhIGNsYXNz
PSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0
YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvcDAxNTFyMC5wZGYiPmh0dHA6Ly93d3cu
b3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTUvcDAxNTFyMC5w
ZGY8L2E+PC9wPgo8L2xpPgo8L3VsPgo8dWw+CjxsaT48cCBjbGFzcz0iZmlyc3QiPjxhIGNs
YXNzPSJyZWZlcmVuY2UgZXh0ZXJuYWwiIGhyZWY9Imh0dHA6Ly93ZzIxLmxpbmsvcDAxOTci
PlAwMTk3PC9hPiBEZWZhdWx0IFR1cGxlLWxpa2UgQWNjZXNzPC9wPgo8cD48YSBjbGFzcz0i
cmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMTk3Ij5odHRw
Oi8vd2cyMS5saW5rL3AwMTk3PC9hPjwvcD4KPC9saT4KPC91bD4KPHVsPgo8bGk+PHAgY2xh
c3M9ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8v
d2cyMS5saW5rL3AwMjIyIj5QMDIyMjwvYT4gQWxsb3dpbmcgQW5vbnltb3VzIFN0cnVjdHMg
YXMgUmV0dXJuIFZhbHVlczwvcD4KPHA+PGEgY2xhc3M9InJlZmVyZW5jZSBleHRlcm5hbCIg
aHJlZj0iaHR0cDovL3dnMjEubGluay9wMDIyNCI+aHR0cDovL3dnMjEubGluay9wMDIyNDwv
YT48L3A+CjwvbGk+CjwvdWw+Cjx1bD4KPGxpPjxwIGNsYXNzPSJmaXJzdCI+PGEgY2xhc3M9
InJlZmVyZW5jZSBleHRlcm5hbCIgaHJlZj0iaHR0cDovL3dnMjEubGluay9wMDIyNCI+UDAy
MjQ8L2E+IEltcGxpY2l0IFJldHVybiBUeXBlPC9wPgo8cD48YSBjbGFzcz0icmVmZXJlbmNl
IGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMjI0Ij5odHRwOi8vd2cyMS5s
aW5rL3AwMjI0PC9hPjwvcD4KPC9saT4KPC91bD4KPHVsPgo8bGk+PHAgY2xhc3M9ImZpcnN0
Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5r
L3AwMzI5Ij5QMDMyOTwvYT4gRGVzaWduYXRlZCBJbml0aWFsaXplciBXb3JkaW5nPC9wPgo8
cD48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5r
L3AwMzI5Ij5odHRwOi8vd2cyMS5saW5rL3AwMzI5PC9hPjwvcD4KPC9saT4KPC91bD4KPHVs
Pgo8bGk+PHAgY2xhc3M9ImZpcnN0Ij48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVybmFsIiBo
cmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMzQxIj5QMDM0MTwvYT4gUGFyYW1ldGVyIFBhY2tz
IE91dHNpZGUgb2YgVGVtcGxhdGVzPC9wPgo8cD48YSBjbGFzcz0icmVmZXJlbmNlIGV4dGVy
bmFsIiBocmVmPSJodHRwOi8vd2cyMS5saW5rL3AwMzQxIj5odHRwOi8vd2cyMS5saW5rL3Aw
MzQxPC9hPjwvcD4KPC9saT4KPC91bD4KPCEtLSBGSVhNRSBsaW5rIHRvIGdlbi11bnBhY2sg
LS0+CjwhLS0gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4g
Li4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLi4gLS0+CjwhLS0ga2F0ZTogaGwgcmVTdHJ1
Y3R1cmVkVGV4dCAtLT4KPC9kaXY+CjxkaXYgY2xhc3M9InN5c3RlbS1tZXNzYWdlcyBzZWN0
aW9uIj4KPGgxPkRvY3V0aWxzIFN5c3RlbSBNZXNzYWdlczwvaDE+CjxkaXYgY2xhc3M9InN5
c3RlbS1tZXNzYWdlIiBpZD0iaWQxOSI+CjxwIGNsYXNzPSJzeXN0ZW0tbWVzc2FnZS10aXRs
ZSI+U3lzdGVtIE1lc3NhZ2U6IEVSUk9SLzMgKDx0dCBjbGFzcz0iZG9jdXRpbHMiPmR4eHh4
LWltcGxpY2l0LXJldHVybi1hbmQtYW5vbnltb3VzLXN0cnVjdHMucnN0PC90dD4sIGxpbmUg
MzcpOyA8ZW0+PGEgaHJlZj0iI2lkMjAiPmJhY2tsaW5rPC9hPjwvZW0+PC9wPgpVbmtub3du
IHRhcmdldCBuYW1lOiAmcXVvdDtmaXhtZSZxdW90Oy48L2Rpdj4KPGRpdiBjbGFzcz0ic3lz
dGVtLW1lc3NhZ2UiIGlkPSJpZDIxIj4KPHAgY2xhc3M9InN5c3RlbS1tZXNzYWdlLXRpdGxl
Ij5TeXN0ZW0gTWVzc2FnZTogRVJST1IvMyAoPHR0IGNsYXNzPSJkb2N1dGlscyI+ZHh4eHgt
aW1wbGljaXQtcmV0dXJuLWFuZC1hbm9ueW1vdXMtc3RydWN0cy5yc3Q8L3R0PiwgbGluZSAy
MjYpOyA8ZW0+PGEgaHJlZj0iI2lkMjIiPmJhY2tsaW5rPC9hPjwvZW0+PC9wPgpVbmtub3du
IHRhcmdldCBuYW1lOiAmcXVvdDtmaXhtZSZxdW90Oy48L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8
L2JvZHk+CjwvaHRtbD4K
--------------050900060409010603020009--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 19 Dec 2016 16:52:09 -0500
Raw View
On 2016-12-19 16:03, Arthur O'Dwyer wrote:
> On Mon, Dec 19, 2016 at 12:04 PM, Matthew Woehlke <mwoehlke.floss@gmail.c=
om>
> wrote:
>>
>> Updated version attached. Thanks all for the feedback so far!
>=20
> From your reply to my message:
>=20
>>> template<class T> struct S { } vt2; // ERROR in C++14: definition of
> S<T> can't also declare vt2
>>
>> Riiiight... particularly, `vt2` would have to be a template here, or
>> else you'd somehow need an argument list.
>=20
> Right, but I suspect you didn't notice that if you remove the body "{ }",
> then the above becomes
>=20
> template<class T> struct S vt2; // OK in C++14: declares variable
> template vt2<T> of type S
>=20
> So the specific grammatical quirk here is that variable templates behave
> differently from variable non-templates. (Your proposal intends to
> introduce the same quirk for function templates vis-a-vis function
> non-templates, thus making functions behave more like variables.)
I think I follow. Do you consider this a problem, or just an observation?
>>> struct { int x, y; } f() { ??? s; return s; }
>>> where you additionally want-but-explicitly-do-not-propose
>>> "decltype(return)" as the appropriate syntax for "???".
>>
>> Um... it's *meant* to be explicitly proposed. Can you please clarify why
>> you think I haven't done so, so I can fix it?
>=20
> The current proposal says under "Future Directions": "A final considerati=
on
> is the extension of decltype(return) to allow use *within a function body=
*.
> At the time of writing, we are not aware of a proposal to do so, although
> the idea has been floated on numerous occasions. We would hope to see suc=
h
> an addition, which can be *orthogonal to this proposal*, in the near
> future."
D'oh. You are right; I misread your original example. Sorry.
I do want that (see also
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/sfeZ_rR2BvQ/JrML=
G0bVAQAJ),
but it's not necessary for this proposal. I also want that for cases
that don't involve anonymous types. (I think most people asking for it
aren't even thinking about anonymous types.)
> From the updated proposal:
>=20
>> The critical problem with this, which we wish specifically to address,
>> is that a forward declaration of such a function is not possible.
>=20
> Actually, you *can* forward-declare such a function; specifically what's
> missing is a way to forward-declare such a function and its return type.
> That is:
>=20
> auto f();
>=20
> is a valid forward declaration in C++14. (It was not valid in C++11 due =
to
> the lack of a trailing return type.)
Well... it's not *useful* without the return type :-). (I've added
"useful" to the quoted sentence.) The intent, as I'm sure you know, is
to *declare* the function in a header and *define* it elsewhere.
>> This feature is not compatible with deduced return types at this time.
>=20
> Agreed, but I don't think P0329 is relevant at all. I admit I've only
> skimmed it, but I don't think P0329 adds the ability to deduce a type fro=
m
> a braced-initializer-list as in your example.
All P0329 really adds is that we've finally decided we're okay with
designated initializer lists. I've rephrased: "In light of P0329_, we
might imagine a further extension that would allow us to lift this
restriction".
> The actually relevant example
> would be like this:
>=20
> auto f(); // declare function with return type
> int f() { return 0; } // ERROR in C++14: "ambiguating declaration" =
=E2=80=94
> perhaps this should be proposed as OK?
>
> int f(); // declare function with return type
> auto f() { return 0; } // ERROR in C++14: "ambiguating declaration" =
=E2=80=94
> perhaps this should be proposed as OK?
I'm going to say "no". This was explored in the context of P0224. My
general feeling is that `auto f(...);` is weird and I don't want to muck
with it.
> int f(); // declare function with return type
> decltype(return) f() { return 0; } // presumably OK: define function
> without redeclaring return type
Definitely okay; this is very explicitly just the `decltype(return)`
part of the proposal. I wouldn't *advise* using it for a simple return
type, but for a long, awkward return type it becomes more attractive.
> auto f(); // declare function without declaring return type
> decltype(return) f() { return 0; } // presumably ERROR:
> decltype(return) used before return type has been deduced
Oh... I see; the trouble is that you are mistaking "this feature" for
`decltype(return)`, when it is meant to refer to defining types as
return types. This is because this section was copied from P0222.
Reworded: "The relaxation of [dcl.fct]/11 is not intended to extend to
deduction of new types via deduced return types. In light of P0329_, we
might imagine a further extension that would allow us to lift this
restriction:" (following text unchanged).
Thanks!
--=20
Matthew
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58585689.8040302%40gmail.com.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 19 Dec 2016 19:48:29 -0800 (PST)
Raw View
------=_Part_5357_1131322101.1482205709740
Content-Type: multipart/alternative;
boundary="----=_Part_5358_1676813147.1482205709740"
------=_Part_5358_1676813147.1482205709740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, December 19, 2016 at 1:52:12 PM UTC-8, Matthew Woehlke wrote:
>
> On 2016-12-19 16:03, Arthur O'Dwyer wrote:=20
> > On Mon, Dec 19, 2016 at 12:04 PM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:=20
> >>=20
> >> Updated version attached. Thanks all for the feedback so far!=20
> >=20
> > From your reply to my message:=20
> >=20
> >>> template<class T> struct S { } vt2; // ERROR in C++14: definition of=
=20
> > S<T> can't also declare vt2=20
> >>=20
> >> Riiiight... particularly, `vt2` would have to be a template here, or=
=20
> >> else you'd somehow need an argument list.=20
> >=20
> > Right, but I suspect you didn't notice that if you remove the body "{=
=20
> }",=20
> > then the above becomes=20
> >=20
> > template<class T> struct S vt2; // OK in C++14: declares variable=
=20
> > template vt2<T> of type S=20
> >=20
> > So the specific grammatical quirk here is that variable templates behav=
e=20
> > differently from variable non-templates. (Your proposal intends to=20
> > introduce the same quirk for function templates vis-a-vis function=20
> > non-templates, thus making functions behave more like variables.)=20
>
> I think I follow. Do you consider this a problem, or just an observation?=
=20
>
Just an observation at this point. Initially I thought it was a problem=20
because I thought the inconsistency between templates and non-templates was=
=20
new in your proposal, but then I discovered that "the current state of=20
affairs isn't as consistent as I'd thought" in the current standard; you're=
=20
not making it any worse in that respect.
=20
> > From the updated proposal:=20
> >=20
> >> The critical problem with this, which we wish specifically to address,=
=20
> >> is that a forward declaration of such a function is not possible.=20
> >=20
> > Actually, you *can* forward-declare such a function; specifically what'=
s=20
> > missing is a way to forward-declare such a function and its return type=
..=20
> > That is:=20
> >=20
> > auto f();=20
> >=20
> > is a valid forward declaration in C++14. (It was not valid in C++11 du=
e=20
> to=20
> > the lack of a trailing return type.)=20
>
> Well... it's not *useful* without the return type :-). (I've added=20
> "useful" to the quoted sentence.) The intent, as I'm sure you know, is=20
> to *declare* the function in a header and *define* it elsewhere.
>
You can still declare a function with "auto" in a header and define it=20
elsewhere; you just can't declare the function with its complete return=20
type in a header and then define it elsewhere. As I showed in my last email=
,
auto f();
auto f() { return 42; }
is well-formed C++14. Now, this doesn't get you what you want (re=20
anonymous struct return types that would be complete at the point of call),=
=20
but it does "declare the function in a header and define it elsewhere." So=
=20
what I'm saying is, you should choose your words more carefully in that=20
part of the proposal so that you're not claiming "one can't do X in C++14"=
=20
when in fact one *can*.
All this "auto" discussion got me thinking briefly that maybe "int f();=20
auto f() { return 0L; }" should be accepted and define f() to return int...=
=20
but then I didn't like where that was leading me with respect to this=20
question:
*In what positions does the keyword 'auto' mean 'not yet specified; will be=
=20
filled in later' and in what positions does it mean 'my surrounding entity=
=20
is a template'?*
I also didn't like how the meaning of "auto f() { return 0L; }" could=20
change based on whether that previous declaration was in scope or not.=20
(With the previous declaration, f() returns int; without it, f() defaults=
=20
to returning long.) But OTOH, we already have similar things happen with=20
'extern "C"' and 'inline' and so on. (With a previous declaration involving=
=20
the appropriate keywords, f() is extern "C" and/or inline; without it, f()=
=20
defaults to non-"C" and non-inline.)
I see that indeed this ground has already been covered (by you!) in P0224=
=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0224r0.html>.
I'm going to say "no". This was explored in the context of P0224=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0224r0.html>.=
=20
> My=20
> general feeling is that `auto f(...);` is weird and I don't want to muck=
=20
> with it.=20
>
Once bitten, twice shy. But then my devil's-advocate question is: are you=
=20
just proposing decltype(return) as an uglier way to get the same semantics=
=20
that P0224 would have assigned to 'auto'? And if so, might it be better to=
=20
push harder on P0224 and really iron out the kinks of 'auto', than=20
introduce this new grammatical quirk 'decltype(return)'?
As my bolded question above indicates, I agree that 'auto' is weird and=20
messy; but I'd rather someone clean up the mess, than just run away and=20
start creating a new mess somewhere else because they don't want to deal=20
with the old mess. (Especially since it's not *very* messy, just a *little=
*=20
messy. I might even prefer one *medium-sized* mess over two little messes.)
Just so it's clear: kudos on actually writing these proposals. That's more=
=20
than I've done. :)
=20
>
> > auto f(); // declare function without declaring return type=20
> > decltype(return) f() { return 0; } // presumably ERROR:=20
> > decltype(return) used before return type has been deduced=20
>
> Oh... I see; the trouble is that you are mistaking "this feature" for=20
> `decltype(return)`, when it is meant to refer to defining types as=20
> return types. This is because this section was copied from P0222.=20
>
> Reworded: "The relaxation of [dcl.fct]/11 is not intended to extend to=20
> deduction of new types via deduced return types. In light of P0329_, we=
=20
> might imagine a further extension that would allow us to lift this=20
> restriction:" (following text unchanged).=20
>
I suppose that's better. I can't imagine how we could ever get to the point=
=20
of being able to "deduce" a *new*, previously undeclared, type; but since=
=20
you're only mentioning the possibility in order to say you're not proposing=
=20
it, I guess it's safely ignoreable. ;)
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7df961fc-89f4-4ce0-88fa-6695052e2dba%40isocpp.or=
g.
------=_Part_5358_1676813147.1482205709740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, December 19, 2016 at 1:52:12 PM UTC-8, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-12-19 16=
:03, Arthur O'Dwyer wrote:
<br>> On Mon, Dec 19, 2016 at 12:04 PM, Matthew Woehlke <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2t74aWRsCwAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">mwoehlk...@gmail.=
com</a>>=C2=A0wrote:
<br>>>
<br>>> Updated version attached. Thanks all for the feedback so far!
<br>>=20
<br>> From your reply to my message:
<br>>=20
<br>>>> template<class T> struct S { } vt2; =C2=A0// ERROR i=
n C++14: definition of
<br>> S<T> can't also declare vt2
<br>>>
<br>>> Riiiight... particularly, `vt2` would have to be a template he=
re, or
<br>>> else you'd somehow need an argument list.
<br>>=20
<br>> Right, but I suspect you didn't notice that if you remove the =
body "{ }",
<br>> then the above becomes
<br>>=20
<br>> =C2=A0 =C2=A0 template<class T> struct S vt2; =C2=A0// OK in=
C++14: declares variable
<br>> template vt2<T> of type S
<br>>=20
<br>> So the specific grammatical quirk here is that variable templates =
behave
<br>> differently from variable non-templates. (Your proposal intends to
<br>> introduce the same quirk for function templates vis-a-vis function
<br>> non-templates, thus making functions behave more like variables.)
<br>
<br>I think I follow. Do you consider this a problem, or just an observatio=
n?
<br></blockquote><div><br></div><div>Just an observation at this point. Ini=
tially I thought it was a problem because I thought the inconsistency betwe=
en templates and non-templates was new in your proposal, but then I discove=
red that "the current state of affairs isn't as consistent as I=
9;d thought" in the current standard; you're not making it any wor=
se in that respect.</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">> From the updated proposal:
<br>>=20
<br>>> The critical problem with this, which we wish specifically to =
address,
<br>>> is that a forward declaration of such a function is not possib=
le.
<br>>=20
<br>> Actually, you *can* forward-declare such a function; specifically =
what's
<br>> missing is a way to forward-declare such a function and its return=
type.
<br>> That is:
<br>>=20
<br>> =C2=A0 =C2=A0 auto f();
<br>>=20
<br>> is a valid forward declaration in C++14. =C2=A0(It was not valid i=
n C++11 due to
<br>> the lack of a trailing return type.)
<br>
<br>Well... it's not *useful* without the return type :-). (I've ad=
ded
<br>"useful" to the quoted sentence.) The intent, as I'm sure=
you know, is
<br>to *declare* the function in a header and *define* it elsewhere.<br></b=
lockquote><div><br></div><div>You can still declare a function with "a=
uto" in a header and define it elsewhere; you just can't declare t=
he function with its complete return type in a header and then define it el=
sewhere. As I showed in my last email,</div><div><br></div><div>auto f();</=
div><div>auto f() { return 42; }</div><div><br></div><div>is well-formed C+=
+14. =C2=A0Now, this doesn't get you what you want (re anonymous struct=
return types that would be complete at the point of call), but it does &qu=
ot;declare the function in a header and define it elsewhere." =C2=A0So=
what I'm saying is, you should choose your words more carefully in tha=
t part of the proposal so that you're not claiming "one can't =
do X in C++14" when in fact one=C2=A0<i>can</i>.</div><div><br></div><=
div>All this "auto" discussion got me thinking briefly that maybe=
"int f(); auto f() { return 0L; }" should be accepted and define=
f() to return int... but then I didn't like where that was leading me =
with respect to this question:</div><div><b>In what positions does the keyw=
ord 'auto' mean 'not yet specified; will be filled in later'=
; and in what positions does it mean 'my surrounding entity is a templa=
te'?</b><br></div><div>I also didn't like how the meaning of "=
auto f() { return 0L; }" could change based on whether that previous d=
eclaration was in scope or not. (With the previous declaration, f() returns=
int; without it, f() defaults to returning long.) But OTOH, we already hav=
e similar things happen with 'extern "C"' and 'inline=
' and so on. (With a previous declaration involving the appropriate key=
words, f() is extern "C" and/or inline; without it, f() defaults =
to non-"C" and non-inline.)</div><div>I see that indeed this grou=
nd has already been covered (by you!) in <a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2016/p0224r0.html">P0224</a>.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">I'm going to say "=
no". This was explored in the context of <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2016/p0224r0.html">P0224</a>. My
<br>general feeling is that `auto f(...);` is weird and I don't want to=
muck
<br>with it.
<br></blockquote><div><br></div><div>Once bitten, twice shy. =C2=A0But then=
my devil's-advocate question is: are you just proposing decltype(retur=
n) as an uglier way to get the same semantics that P0224 would have assigne=
d to 'auto'? =C2=A0And if so, might it be better to push harder on =
P0224 and really iron out the kinks of 'auto', than introduce this =
new grammatical quirk 'decltype(return)'?<br></div><div>As my bolde=
d question above indicates, I agree that 'auto' is weird and messy;=
but I'd rather someone clean up the mess, than just run away and start=
creating a new mess somewhere else because they don't want to deal wit=
h the old mess. =C2=A0(Especially since it's not <i>very</i> messy, jus=
t a <i>little</i> messy. I might even prefer one <i>medium-sized</i> mess o=
ver two little messes.)</div><div>Just so it's clear: kudos on actually=
writing these proposals. That's more than I've done. :)</div><div>=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br=
>> =C2=A0 =C2=A0 auto f(); =C2=A0// declare function without declaring r=
eturn type
<br>> =C2=A0 =C2=A0 decltype(return) f() { return 0; } =C2=A0// presumab=
ly ERROR:
<br>> decltype(return) used before return type has been deduced
<br>
<br>Oh... I see; the trouble is that you are mistaking "this feature&q=
uot; for
<br>`decltype(return)`, when it is meant to refer to defining types as
<br>return types. This is because this section was copied from P0222.
<br>
<br>Reworded: "The relaxation of [dcl.fct]/11 is not intended to exten=
d to
<br>deduction of new types via deduced return types. In light of P0329_, we
<br>might imagine a further extension that would allow us to lift this
<br>restriction:" (following text unchanged).
<br></blockquote><div><br></div><div>I suppose that's better. I can'=
;t imagine how we could ever get to the point of being able to "deduce=
" a <i>new</i>, previously undeclared, type; but since you're only=
mentioning the possibility in order to say you're not proposing it, I =
guess it's safely ignoreable. ;)</div><div><br></div><div>=E2=80=93Arth=
ur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7df961fc-89f4-4ce0-88fa-6695052e2dba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7df961fc-89f4-4ce0-88fa-6695052e2dba=
%40isocpp.org</a>.<br />
------=_Part_5358_1676813147.1482205709740--
------=_Part_5357_1131322101.1482205709740--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 20 Dec 2016 10:33:20 -0500
Raw View
On 2016-12-19 22:48, Arthur O'Dwyer wrote:
> You can still declare a function with "auto" in a header and define it
> elsewhere; you just can't declare the function with its complete return
> type in a header and then define it elsewhere. As I showed in my last email,
>
> auto f();
> auto f() { return 42; }
>
> is well-formed C++14. Now, this doesn't get you what you want (re
> anonymous struct return types that would be complete at the point of call),
> but it does "declare the function in a header and define it elsewhere."
....which is why I added the qualification that the declaration be
"useful", meaning "can be called without seeing the definition".
auto foo();
auto bar()
{
return foo(); // error: use of 'auto' before deduction of 'auto'
}
> All this "auto" discussion got me thinking briefly that maybe "int f();
> auto f() { return 0L; }" should be accepted and define f() to return int...
> [...]
> I see that indeed this ground has already been covered (by you!) in P0224
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0224r0.html>.
Indeed :-). For various of the reasons you noted (snipped) and others
(mentioned in the paper), `decltype(return)` seems much saner. (Also,
see below.)
> On Monday, December 19, 2016 at 1:52:12 PM UTC-8, Matthew Woehlke wrote:
>> My general feeling is that `auto f(...);` is weird and I don't want
>> to muck with it.
>
> Once bitten, twice shy. But then my devil's-advocate question is: are you
> just proposing decltype(return) as an uglier way to get the same semantics
> that P0224 would have assigned to 'auto'?
I would say I'm proposing it as a *less* ugly P0224. As noted, P0224
would overload `auto`, which has existing meaning, to sometimes mean
something else. I think the point that it's confusing if `auto` means
"deduce" or "infer" depending if a previous declaration exists is...
pretty serious. Using `decltype(return)` instead solves that problem by
being completely unambiguous; `decltype(return)` *always* means "use the
return type from a prior declaration".
I also consider it a feature that it is more typing; for the cases you
really need it, it is still an improvement (even besides that you *have*
to use it in such a case, it is still less typing than repeating even a
trivial anonymous type), but being longer will hopefully help to
discourage "frivolous" use.
On top of all this, of course, I hope that `decltype(return)` will also
be allowed at some point in function bodies as well, which also lends
argument to using one syntax consistently.
All that said, I'm only very mildly opposed to the P0224 approach, but I
do think that `decltype(return)` is superior. I'm entirely willing to
put it to the committee, though.
(See also "Is `decltype(return)` dangerous?" in the paper.)
>> Reworded: "The relaxation of [dcl.fct]/11 is not intended to extend to
>> deduction of new types via deduced return types. In light of P0329_, we
>> might imagine a further extension that would allow us to lift this
>> restriction:" (following text unchanged).
>
> I suppose that's better. I can't imagine how we could ever get to the point
> of being able to "deduce" a *new*, previously undeclared, type; but since
> you're only mentioning the possibility in order to say you're not proposing
> it, I guess it's safely ignoreable. ;)
I can imagine it pretty easily :-). As in the example in the paper:
return { .x = 3, .y = 2 };
....this would be effectively:
struct {
auto x = 3; // really: decltype(3) x = 3;
auto y = 2; // really: decltype(2) y = 2;
} result;
return result;
Obviously, this requires that every initializer is named, and that
multiple returns are consistent. For each name, the resulting anonymous
struct has a member of that name, whose type is deduced from the
assigned value, with said values having the same order in the struct as
the order in which they are named in the return statement. Multiple
returns must be consistent, of course.
That's how I imagine it being *possible*. Mind, I'm *not* saying I think
it's a good idea :-).
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58594F40.4020902%40gmail.com.
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Sun, 1 Jan 2017 14:30:14 -0500
Raw View
> On Dec 19, 2016, at 12:14 PM, Matthew Woehlke <mwoehlke.floss@gmail.com> =
wrote:
>=20
> On 2016-12-17 16:10, Bryce Glover wrote:
>> I couldn=E2=80=99t help but note that your paper=E2=80=99s section on =
=E2=80=98What about=20
>> deduced return types?=E2=80=99 is now somewhat inaccurate due to progres=
s on=20
>> P0329 <http://wg.link/p0329> (currently titled =E2=80=99Designated=20
>> Initialization Wording=E2=80=99 as of revisions 1 and 2, but originally=
=20
>> christened simply =E2=80=98Designated Initialization=E2=80=99 in rev. 0,=
) which, as
>> far as I can recall, has been accepted for inclusion post-C++17.
>=20
> Thanks; I wasn't aware of that paper or its progress. Do you just mean
> that "if ... is ever accepted" is now inaccurate, or does my example
> need to be adjusted also?
>=20
> --=20
> Matthew
The former, not the latter (at least as far as I can tell right away after =
coming back to this after the holidays=E2=80=A6)
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
P. S.: Sorry for the long reply delay; like I implied above, this holiday =
season was a bit more hectic than I expected it to be (in fact, things are =
still wrapping up here on my end) so I haven=E2=80=99t been able to keep up=
with my correspondence as well as I would like. =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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/811B83A7-E70B-4B00-B442-53D3345204A6%40gmail.com=
..
.