<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>I'm still not 100% sure that mixing the exhaustiveness and the closeness is a good idea,</div><div>again because<br></div><div>- you may want closeness of non user named types<br data-mce-bogus="1"></div><div>- you may want exhaustiveness not only types (on values by example)<br data-mce-bogus="1"></div><div>but it makes the feature simple, so let's go that way.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Allowing public auxillary subtype of a primary sealed type is the sweet spot for me, better than trying to introduce either a nesting which is not exactly nesting or a rule than only works for pattern matching.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I don't understand how "semi-final" can be a good keyword, the name is too vague. Given that the proposal introduce the notion of sealed types, "sealed" is a better keyword.</div><div>For un-sealing a subtype, "unsealed" seems to be a good keyword.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi</div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>À: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Mercredi 9 Janvier 2019 19:44:12<br><b>Objet: </b>Sealed types -- updated proposal<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="markdown-here-wrapper" style="">
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;"> Here's an update on the sealed type proposal based on recent discussions.  
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Definition.</strong>
        A <em>sealed type</em> is one for which subclassing is
        restricted according to guidance specified with the type’s
        declaration; finality can be considered a degenerate form of
        sealing, where no subclasses at all are permitted. Sealed types
        are a sensible means of modeling <em>algebraic sum types</em>
        in a nominal type hierarchy; they go nicely with records (<em>algebraic
          product types</em>), though are also useful on their own.</p>
      <p style="margin: 0px 0px 1.2em !important;">Sealing serves two
        distinct purposes. The first, and more obvious, is that it
        restricts who can be a subtype. This is largely a
        declaration-site concern, where an API owner wants to defend the
        integrity of their API. The other is that it potentially enables
        exhaustiveness analysis at the use site when switching over
        sealed types (and possibly other features.) This is less
        obvious, and the benefit is contingent on some other things, but
        is valuable as it enables better compile-time type checking. </p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Declaration.</strong>
        We specify that a class is sealed by applying the <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">semi-final</code>
        modifier to a class, abstract class, or interface:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">semi-final interface Node { ... }
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;">In this streamlined
        form, <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">Node</code>
        may be extended only by named classes declared in the same nest.
        This may be suitable for many situations, but not for all; in
        this case, the user may specify an explicit <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">permits</code>
        list:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">semi-final interface Node 
    permits FooNode, BarNode { ... }
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;"><em>Note: <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">permits</code>
          here is a contextual keyword.</em></p>
      <p style="margin: 0px 0px 1.2em !important;">The two forms may not
        be combined; if there is a permits list, it must list all the
        permitted subtypes. We can think of the simple form as merely
        inferring the <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">permits</code>
        clause from information in the nest. </p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Exhaustiveness.</strong>
        One of the benefits of sealing is that the compiler can
        enumerate the permitted subtypes of a sealed type; this in turn
        lets us perform exhaustiveness analysis when switching over
        patterns involving sealed types. Permitted subtypes must belong
        to the same module (or, if not in a module, the same package.)</p>
      <p style="margin: 0px 0px 1.2em !important;"><em>Note:</em> It is
        superficially tempting to have a relaxed but less explicit form,
        say which allows for a type to be extended by package-mates or
        module-mates without listing them all. However, this would
        undermine the compiler’s ability to reason about exhaustiveness.
        This would achieve the desired subclassing restrictions, but not
        the desired ability to reason about exhaustiveness. </p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Classfile.</strong>
        In the classfile, a sealed type is identified with an <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">ACC_FINAL</code>
        modifier, and a <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">PermittedSubtypes</code>
        attribute which contains a list of permitted subtypes (similar
        in structure to the nestmate attributes.)</p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Transitivity.</strong>
        Sealing is transitive; unless otherwise specified, an abstract
        subtype of a sealed type is implicitly sealed (permits list to
        be inferred), and a concrete subtype of a sealed type is
        implicitly final. This can be reversed by explicitly modifying
        the subtype with the <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">non-final</code>
        modifier.</p>
      <p style="margin: 0px 0px 1.2em !important;">Unsealing a subtype
        in a hierarchy doesn’t undermine the sealing, because the
        (possibly inferred) set of explicitly permitted subtypes still
        constitutes a total covering. However, users who know about
        unsealed subtypes can use this information to their benefit
        (much like we do with exceptions today; you can catch <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">FileNotFoundException</code>
        separately from <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">IOException</code>
        if you want, but don’t have to.) </p>
      <p style="margin: 0px 0px 1.2em !important;"><em>Note:</em> Scala
        made the opposite choice with respect to transitivity, requiring
        sealing to be opted into at all levels. This is widely believed
        to be a source of bugs; it is rare that one actually wants a
        subtype of a sealed type to not be sealed. I suspect the
        reasoning in Scala was, at least partially, the desire to not
        make up a new keyword for “not sealed”. This is understandable,
        but I’d rather not add to the list of “things for which Java got
        the defaults wrong.”</p>
      <p style="margin: 0px 0px 1.2em !important;">An example of where
        explicit unsealing (and private subtypes) is useful can be found
        in the JEP-334 API:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">semi-final interface ConstantDesc
    permits String, Integer, Float, Long, Double, 
            ClassDesc, MethodTypeDesc, MethodHandleDesc, 
            DynamicConstantDesc { }

semi-final interface ClassDesc extends ConstantDesc
    permits PrimitiveClassDescImpl, ReferenceClassDescImpl { }

private class PrimitiveClassDescImpl implements ClassDesc { }
 private class ReferenceClassDescImpl implements ClassDesc { }

semi-final interface MethodTypeDesc extends ConstantDesc
     permits MethodTypeDescImpl { }

 semi-final interface MethodHandleDesc extends ConstantDesc
     permits DirectMethodHandleDesc, MethodHandleDescImpl { }

semi-final interface DirectMethodHandleDesc extends MethodHandleDesc
    permits DirectMethodHandleDescImpl

// designed for subclassing
non-final class DynamicConstantDesc extends ConstantDesc { ... }
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Enforcement.</strong>
        Both the compiler and JVM should enforce sealing.</p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Accessibility.</strong>
        Subtypes need not be as accessible as the sealed parent. In this
        case, not all clients will get the chance to exhaustively switch
        over them; they’ll have to make these switches exhaustive with a
        <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">default</code>
        clause or other total pattern. When compiling a switch over such
        a sealed type, the compiler can provide a useful error message
        (“I know this is a sealed type, but I can’t provide full
        exhaustiveness checking here because you can’t see all the
        subtypes, so you still need a default.”) </p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Javadoc.</strong>
        The list of permitted subtypes should probably be considered
        part of the spec, and incorporated into the Javadoc. Note that
        this is not exactly the same as the current “All implementing
        classes” list that Javadoc currently includes, so a list like
        “All permitted subtypes” might be added (possibly with some
        indication if the subtype is less accessible than the parent.)</p>
      <p style="margin: 0px 0px 1.2em !important;"><strong>Auxilliary
          subtypes.</strong> With the advent of records, which allow us
        to define classes in a single line, the “one class per file”
        rule starts to seem both a little silly, and constrain the
        user’s ability to put related definitions together (which may be
        more readable) while exporting a flat namespace in the public
        API. </p>
      <p style="margin: 0px 0px 1.2em !important;">One way to do get
        there would be to relax the “no public auxilliary classes” rule
        to permit for sealed classes, say: allowing public auxilliary
        subtypes of the primary type, if the primary type is public and
        sealed. </p>
      <p style="margin: 0px 0px 1.2em !important;">Another would be to
        borrow a trick from enums; for a sealed type with nested
        subtypes, when you <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">import</code>
        the sealed type, you implicitly import the nested subtypes too.
        That way you could declare:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">semi-final interface Node { 
    class A implements Node { }
    class B implements Node { }
}
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;"> ​but clients could
        import Node and then refer to A and B directly:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">switch (node) { 
    case A(): ...
    case B(): ...
}
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;">We do something
        similar for <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">enum</code>
        constants today.</p>
      <div title="MDH:CiAgICA8dHQ+SGVyZSdzIGFuIHVwZGF0ZSBvbiB0aGUgc2VhbGVkIHR5cGUgcHJvcG9zYWwgYmFzZWQgb24gcmVjZW50IGRpc2N1c3Npb25zLiZuYnNwOyA8YnI+PC90dD48dHQ+PGJyPjxicj4qKkRl
ZmluaXRpb24uKiombmJzcDsKIEEgX3NlYWxlZCB0eXBlXyBpcyBvbmUgZm9yIHdoaWNoIHN1YmNs
YXNzaW5nIGlzIHJlc3RyaWN0ZWQgYWNjb3JkaW5nIHRvCiBndWlkYW5jZSBzcGVjaWZpZWQgd2l0
aCB0aGUgdHlwZeKAmXMgZGVjbGFyYXRpb247IGZpbmFsaXR5IGNhbiBiZSAKY29uc2lkZXJlZCBh
IGRlZ2VuZXJhdGUgZm9ybSBvZiBzZWFsaW5nLCB3aGVyZSBubyBzdWJjbGFzc2VzIGF0IGFsbCBh
cmUgCnBlcm1pdHRlZC4gU2VhbGVkIHR5cGVzIGFyZSBhIHNlbnNpYmxlIG1lYW5zIG9mIG1vZGVs
aW5nIF9hbGdlYnJhaWMgc3VtIAp0eXBlc18gaW4gYSBub21pbmFsIHR5cGUgaGllcmFyY2h5OyB0
aGV5IGdvIG5pY2VseSB3aXRoIHJlY29yZHMgCihfYWxnZWJyYWljIHByb2R1Y3QgdHlwZXNfKSwg
dGhvdWdoIGFyZSBhbHNvIHVzZWZ1bCBvbiB0aGVpciBvd24uPGJyPjxicj5TZWFsaW5nCiBzZXJ2
ZXMgdHdvIGRpc3RpbmN0IHB1cnBvc2VzLiZuYnNwOyBUaGUgZmlyc3QsIGFuZCBtb3JlIG9idmlv
dXMsIGlzIHRoYXQgaXQgCnJlc3RyaWN0cyB3aG8gY2FuIGJlIGEgc3VidHlwZS4mbmJzcDsgVGhp
cyBpcyBsYXJnZWx5IGEgZGVjbGFyYXRpb24tc2l0ZSAKY29uY2Vybiwgd2hlcmUgYW4gQVBJIG93
bmVyIHdhbnRzIHRvIGRlZmVuZCB0aGUgaW50ZWdyaXR5IG9mIHRoZWlyIEFQSS4mbmJzcDsKIFRo
ZSBvdGhlciBpcyB0aGF0IGl0IHBvdGVudGlhbGx5IGVuYWJsZXMgZXhoYXVzdGl2ZW5lc3MgYW5h
bHlzaXMgYXQgdGhlCiB1c2Ugc2l0ZSB3aGVuIHN3aXRjaGluZyBvdmVyIHNlYWxlZCB0eXBlcyAo
YW5kIHBvc3NpYmx5IG90aGVyIApmZWF0dXJlcy4pJm5ic3A7IFRoaXMgaXMgbGVzcyBvYnZpb3Vz
LCBhbmQgdGhlIGJlbmVmaXQgaXMgY29udGluZ2VudCBvbiBzb21lIApvdGhlciB0aGluZ3MsIGJ1
dCBpcyB2YWx1YWJsZSBhcyBpdCBlbmFibGVzIGJldHRlciBjb21waWxlLXRpbWUgdHlwZSAKY2hl
Y2tpbmcuJm5ic3A7IDxicj48YnI+KipEZWNsYXJhdGlvbi4qKiZuYnNwOwogV2Ugc3BlY2lmeSB0
aGF0IGEgY2xhc3MgaXMgc2VhbGVkIGJ5IGFwcGx5aW5nIHRoZSBgc2VtaS1maW5hbGAgbW9kaWZp
ZXIgdG8gYQogY2xhc3MsIGFic3RyYWN0IGNsYXNzLCBvciBpbnRlcmZhY2U6PGJyPjxicj4mbmJz
cDsmbmJzcDsmbmJzcDsgc2VtaS1maW5hbCBpbnRlcmZhY2UgTm9kZSB7IC4uLiB9PGJyPjxicj5J
bgogdGhpcyBzdHJlYW1saW5lZCBmb3JtLCBgTm9kZWAgbWF5IGJlIGV4dGVuZGVkIG9ubHkgYnkg
bmFtZWQgY2xhc3NlcyBkZWNsYXJlZCBpbiB0aGUgc2FtZSBuZXN0LiZuYnNwOyBUaGlzIG1heSBi
ZSBzdWl0YWJsZSBmb3IgbWFueSBzaXR1YXRpb25zLCBidXQgbm90IGZvciBhbGw7IGluIHRoaXMg
Y2FzZSwKIHRoZSB1c2VyIG1heSBzcGVjaWZ5IGFuIGV4cGxpY2l0IGBwZXJtaXRzYCBsaXN0Ojxi
cj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbWktZmluYWwgaW50ZXJmYWNlIE5vZGUgPGJyPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJtaXRzIEZvb05vZGUs
IEJhck5vZGUgeyAuLi4gfTxicj48YnI+X05vdGU6IGBwZXJtaXRzYCBoZXJlIGlzIGEgY29udGV4
dHVhbCBrZXl3b3JkLl88YnI+PGJyPlRoZQogdHdvIGZvcm1zIG1heSBub3QgYmUgY29tYmluZWQ7
IGlmIHRoZXJlIGlzIGEgcGVybWl0cyBsaXN0LCBpdCBtdXN0IGxpc3QKIGFsbCB0aGUgcGVybWl0
dGVkIHN1YnR5cGVzLiZuYnNwOyBXZSBjYW4gdGhpbmsgb2YgdGhlIHNpbXBsZSBmb3JtIGFzIG1l
cmVseSAKaW5mZXJyaW5nIHRoZSBgcGVybWl0c2AgY2xhdXNlIGZyb20gaW5mb3JtYXRpb24gaW4g
dGhlIG5lc3QuJm5ic3A7IDxicj48YnI+KipFeGhhdXN0aXZlbmVzcy4qKiZuYnNwOyBPbmUgb2Yg
dGhlIGJlbmVmaXRzIG9mIHNlYWxpbmcgaXMgCnRoYXQgdGhlIGNvbXBpbGVyIGNhbiBlbnVtZXJh
dGUgdGhlIHBlcm1pdHRlZCBzdWJ0eXBlcyBvZiBhIHNlYWxlZCB0eXBlOwogdGhpcyBpbiB0dXJu
IGxldHMgdXMgcGVyZm9ybSBleGhhdXN0aXZlbmVzcyBhbmFseXNpcyB3aGVuIHN3aXRjaGluZyAK
b3ZlciBwYXR0ZXJucyBpbnZvbHZpbmcgc2VhbGVkIHR5cGVzLiBQZXJtaXR0ZWQgc3VidHlwZXMg
bXVzdCBiZWxvbmcgdG8gdGhlIHNhbWUgbW9kdWxlIChvciwgaWYgbm90IGluCiBhIG1vZHVsZSwg
dGhlIHNhbWUgcGFja2FnZS4pPGJyPjxicj5fTm90ZTpfIEl0IGlzCiBzdXBlcmZpY2lhbGx5IHRl
bXB0aW5nIHRvIGhhdmUgYSByZWxheGVkIGJ1dCBsZXNzIGV4cGxpY2l0IGZvcm0sIHNheSAKd2hp
Y2ggYWxsb3dzIGZvciBhIHR5cGUgdG8gYmUgZXh0ZW5kZWQgYnkgcGFja2FnZS1tYXRlcyBvciBt
b2R1bGUtbWF0ZXMgCndpdGhvdXQgbGlzdGluZyB0aGVtIGFsbC4gSG93ZXZlciwgdGhpcyB3b3Vs
ZCB1bmRlcm1pbmUgdGhlIGNvbXBpbGVy4oCZcyAKYWJpbGl0eSB0byByZWFzb24gYWJvdXQgZXho
YXVzdGl2ZW5lc3MuJm5ic3A7IFRoaXMgd291bGQgYWNoaWV2ZSB0aGUgZGVzaXJlZCAKc3ViY2xh
c3NpbmcgcmVzdHJpY3Rpb25zLCBidXQgbm90IHRoZSBkZXNpcmVkIGFiaWxpdHkgdG8gcmVhc29u
IGFib3V0IApleGhhdXN0aXZlbmVzcy4mbmJzcDsgPGJyPjxicj4qKkNsYXNzZmlsZS4qKiZuYnNw
OyBJbiB0aGUgY2xhc3NmaWxlLCBhIHNlYWxlZCB0eXBlCiBpcyBpZGVudGlmaWVkIHdpdGggYW4g
YEFDQ19GSU5BTGAgbW9kaWZpZXIsIGFuZCBhIGBQZXJtaXR0ZWRTdWJ0eXBlc2AgYXR0cmlidXRl
IAp3aGljaCBjb250YWlucyBhIGxpc3Qgb2YgcGVybWl0dGVkIHN1YnR5cGVzIChzaW1pbGFyIGlu
IHN0cnVjdHVyZSB0byB0aGUKIG5lc3RtYXRlIGF0dHJpYnV0ZXMuKTxicj48YnI+KipUcmFuc2l0
aXZpdHkuKiombmJzcDsgU2VhbGluZyBpcyB0cmFuc2l0aXZlOyAKdW5sZXNzIG90aGVyd2lzZSBz
cGVjaWZpZWQsIGFuIGFic3RyYWN0IHN1YnR5cGUgb2YgYSBzZWFsZWQgdHlwZSBpcyAKaW1wbGlj
aXRseSBzZWFsZWQgKHBlcm1pdHMgbGlzdCB0byBiZSBpbmZlcnJlZCksIGFuZCBhIGNvbmNyZXRl
IHN1YnR5cGUgb2YgYSBzZWFsZWQgdHlwZSBpcyBpbXBsaWNpdGx5CiBmaW5hbC4gVGhpcyBjYW4g
YmUgcmV2ZXJzZWQgYnkgZXhwbGljaXRseSBtb2RpZnlpbmcgdGhlIHN1YnR5cGUgd2l0aCAKdGhl
IGBub24tZmluYWxgIG1vZGlmaWVyLjxicj48YnI+VW5zZWFsaW5nIGEgc3VidHlwZSBpbgogYSBo
aWVyYXJjaHkgZG9lc24ndCB1bmRlcm1pbmUgdGhlIHNlYWxpbmcsIGJlY2F1c2UgdGhlIChwb3Nz
aWJseSAKaW5mZXJyZWQpIHNldCBvZiBleHBsaWNpdGx5IHBlcm1pdHRlZCBzdWJ0eXBlcyBzdGls
bCBjb25zdGl0dXRlcyBhIHRvdGFsCiBjb3ZlcmluZy4mbmJzcDsgSG93ZXZlciwgdXNlcnMgd2hv
IGtub3cgYWJvdXQgdW5zZWFsZWQgc3VidHlwZXMgY2FuIHVzZSB0aGlzCiBpbmZvcm1hdGlvbiB0
byB0aGVpciBiZW5lZml0IChtdWNoIGxpa2Ugd2UgZG8gd2l0aCBleGNlcHRpb25zIHRvZGF5OyAK
eW91IGNhbiBjYXRjaCBgRmlsZU5vdEZvdW5kRXhjZXB0aW9uYCBzZXBhcmF0ZWx5IGZyb20gYElP
RXhjZXB0aW9uYCBpZiB5b3UgCndhbnQsIGJ1dCBkb24ndCBoYXZlIHRvLikmbmJzcDsgPGJyPjxi
cj5fTm90ZTpfIFNjYWxhIG1hZGUgdGhlIG9wcG9zaXRlIApjaG9pY2Ugd2l0aCByZXNwZWN0IHRv
IHRyYW5zaXRpdml0eSwgcmVxdWlyaW5nIHNlYWxpbmcgdG8gYmUgb3B0ZWQgaW50byAKYXQgYWxs
IGxldmVscy4gVGhpcyBpcyB3aWRlbHkgYmVsaWV2ZWQgdG8gYmUgYSBzb3VyY2Ugb2YgYnVnczsg
aXQgaXMgCnJhcmUgdGhhdCBvbmUgYWN0dWFsbHkgd2FudHMgYSBzdWJ0eXBlIG9mIGEgc2VhbGVk
IHR5cGUgdG8gbm90IGJlIApzZWFsZWQuJm5ic3A7IEkgc3VzcGVjdCB0aGUgcmVhc29uaW5nIGlu
IFNjYWxhIHdhcywgYXQgbGVhc3QgcGFydGlhbGx5LCB0aGUgCmRlc2lyZSB0byBub3QgbWFrZSB1
cCBhIG5ldyBrZXl3b3JkIGZvciDigJxub3Qgc2VhbGVk4oCdLiZuYnNwOyBUaGlzIGlzIAp1bmRl
cnN0YW5kYWJsZSwgYnV0IEknZCByYXRoZXIgbm90IGFkZCB0byB0aGUgbGlzdCBvZiAidGhpbmdz
IGZvciB3aGljaCAKSmF2YSBnb3QgdGhlIGRlZmF1bHRzIHdyb25nLiI8YnI+PGJyPkFuIGV4YW1w
bGUgb2Ygd2hlcmUgZXhwbGljaXQgdW5zZWFsaW5nIChhbmQgcHJpdmF0ZSBzdWJ0eXBlcykgaXMg
dXNlZnVsIGNhbiBiZSBmb3VuZCBpbiB0aGUgSkVQLTMzNCBBUEk6PGJyPjxicj4mbmJzcDsmbmJz
cDsmbmJzcDsgc2VtaS1maW5hbCBpbnRlcmZhY2UgQ29uc3RhbnREZXNjPGJyPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJtaXRzIFN0cmluZywgSW50ZWdlciwg
RmxvYXQsIExvbmcsIERvdWJsZSwgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBDbGFzc0Rlc2MsIE1ldGhvZFR5cGVEZXNjLCBNZXRob2RIYW5kbGVEZXNjLCA8YnI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IER5bmFtaWNDb25zdGFudERlc2MgeyB9PGJyPjxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsgPC90dD48dHQ+PHR0PnNlbWktZmluYWwgPC90dD5pbnRlcmZh
Y2UgQ2xhc3NEZXNjIGV4dGVuZHMgQ29uc3RhbnREZXNjPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJtaXRzIFByaW1pdGl2ZUNsYXNzRGVzY0ltcGwsIFJl
ZmVyZW5jZUNsYXNzRGVzY0ltcGwgeyB9PC90dD48YnI+PGJyPjx0dD48dHQ+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHByaXZhdGUgY2xhc3MgUHJpbWl0aXZlQ2xhc3NEZXNjSW1wbCBpbXBsZW1lbnRzIENs
YXNzRGVzYyB7IH08YnI+CjwvdHQ+PC90dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaXZhdGUg
Y2xhc3MgUmVmZXJlbmNlQ2xhc3NEZXNjSW1wbCBpbXBsZW1lbnRzIENsYXNzRGVzYyB7IH08YnI+
CjwvdHQ+PHR0Pjx0dD48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvdHQ+PC90dD48dHQ+PHR0Pjx0
dD5zZW1pLWZpbmFsIDwvdHQ+aW50ZXJmYWNlIE1ldGhvZFR5cGVEZXNjIGV4dGVuZHMgQ29uc3Rh
bnREZXNjPGJyPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVy
bWl0cyBNZXRob2RUeXBlRGVzY0ltcGwgeyB9PGJyPgogIDxicj4KPC90dD48L3R0Pjx0dD48dHQ+
PHR0PiZuYnNwOyZuYnNwOyZuYnNwOyA8L3R0PjwvdHQ+PC90dD48dHQ+PHR0Pjx0dD48dHQ+c2Vt
aS1maW5hbCA8L3R0PmludGVyZmFjZSBNZXRob2RIYW5kbGVEZXNjIGV4dGVuZHMgQ29uc3RhbnRE
ZXNjPGJyPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVybWl0
cyBEaXJlY3RNZXRob2RIYW5kbGVEZXNjLCBNZXRob2RIYW5kbGVEZXNjSW1wbCB7IH08YnI+PGJy
PiZuYnNwOyZuYnNwOyZuYnNwOyA8L3R0PjwvdHQ+PC90dD48dHQ+PHR0Pjx0dD48dHQ+c2VtaS1m
aW5hbCA8L3R0PmludGVyZmFjZSBEaXJlY3RNZXRob2RIYW5kbGVEZXNjIGV4dGVuZHMgTWV0aG9k
SGFuZGxlRGVzYzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
cGVybWl0cyBEaXJlY3RNZXRob2RIYW5kbGVEZXNjSW1wbDxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC8vIGRlc2lnbmVkIGZvciBzdWJjbGFzc2luZzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgbm9u
LWZpbmFsIGNsYXNzIER5bmFtaWNDb25zdGFudERlc2MgZXh0ZW5kcyBDb25zdGFudERlc2MgeyAu
Li4gfTxicj4KICA8YnI+CjwvdHQ+PC90dD48YnI+KipFbmZvcmNlbWVudC4qKiZuYnNwOyBCb3Ro
IHRoZSBjb21waWxlciBhbmQgSlZNIHNob3VsZCBlbmZvcmNlIHNlYWxpbmcuPGJyPjxicj4qKkFj
Y2Vzc2liaWxpdHkuKioKIFN1YnR5cGVzIG5lZWQgbm90IGJlIGFzIGFjY2Vzc2libGUgYXMgdGhl
IHNlYWxlZCBwYXJlbnQuJm5ic3A7IEluIHRoaXMgY2FzZSwKIG5vdCBhbGwgY2xpZW50cyB3aWxs
IGdldCB0aGUgY2hhbmNlIHRvIGV4aGF1c3RpdmVseSBzd2l0Y2ggb3ZlciAKdGhlbTsgdGhleSds
bCBoYXZlIHRvIG1ha2UgdGhlc2Ugc3dpdGNoZXMgZXhoYXVzdGl2ZSB3aXRoIGEgYGRlZmF1bHRg
IApjbGF1c2Ugb3Igb3RoZXIgdG90YWwgcGF0dGVybi4mbmJzcDsgV2hlbiBjb21waWxpbmcgYSBz
d2l0Y2ggb3ZlciBzdWNoIGEgCnNlYWxlZCB0eXBlLCB0aGUgY29tcGlsZXIgY2FuIHByb3ZpZGUg
YSB1c2VmdWwgZXJyb3IgbWVzc2FnZSAoIkkga25vdyAKdGhpcyBpcyBhIHNlYWxlZCB0eXBlLCBi
dXQgSSBjYW4ndCBwcm92aWRlIGZ1bGwgZXhoYXVzdGl2ZW5lc3MgY2hlY2tpbmcgCmhlcmUgYmVj
YXVzZSB5b3UgY2FuJ3Qgc2VlIGFsbCB0aGUgc3VidHlwZXMsIHNvIHlvdSBzdGlsbCBuZWVkIGEg
CmRlZmF1bHQuIikmbmJzcDsgPGJyPjwvdHQ+PGJyPjx0dD48dHQ+KipKYXZhZG9jLioqIFRoZSBs
aXN0IG9mIHBlcm1pdHRlZCBzdWJ0eXBlcyBzaG91bGQgcHJvYmFibHkgYmUgCmNvbnNpZGVyZWQg
cGFydCBvZiB0aGUgc3BlYywgYW5kIGluY29ycG9yYXRlZCBpbnRvIHRoZSBKYXZhZG9jLiZuYnNw
OyBOb3RlIAp0aGF0IHRoaXMgaXMgbm90IGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlIGN1cnJlbnQg
IkFsbCBpbXBsZW1lbnRpbmcgCmNsYXNzZXMiIGxpc3QgdGhhdCBKYXZhZG9jIGN1cnJlbnRseSBp
bmNsdWRlcywgc28gYSBsaXN0IGxpa2UgIkFsbCAKcGVybWl0dGVkIHN1YnR5cGVzIiBtaWdodCBi
ZSBhZGRlZCAocG9zc2libHkgd2l0aCBzb21lIGluZGljYXRpb24gaWYgdGhlCiBzdWJ0eXBlIGlz
IGxlc3MgYWNjZXNzaWJsZSB0aGFuIHRoZSBwYXJlbnQuKTxicj4KPC90dD48YnI+KipBdXhpbGxp
YXJ5IHN1YnR5cGVzLioqJm5ic3A7IDwvdHQ+PHR0Pjx0dD48dHQ+V2l0aCB0aGUgYWR2ZW50IG9m
IHJlY29yZHMsIHdoaWNoIGFsbG93IHVzIHRvIApkZWZpbmUgY2xhc3NlcyBpbiBhIHNpbmdsZSBs
aW5lLCB0aGUgIm9uZSBjbGFzcyBwZXIgZmlsZSIgcnVsZSBzdGFydHMgdG8KIHNlZW0gYm90aCBh
IGxpdHRsZSBzaWxseSwgYW5kIGNvbnN0cmFpbiB0aGUgdXNlcidzIGFiaWxpdHkgdG8gcHV0IApy
ZWxhdGVkIGRlZmluaXRpb25zIHRvZ2V0aGVyICh3aGljaCBtYXkgYmUgbW9yZSByZWFkYWJsZSkg
d2hpbGUgCmV4cG9ydGluZyBhIGZsYXQgbmFtZXNwYWNlIGluIHRoZSBwdWJsaWMgQVBJLiZuYnNw
OyA8YnI+PGJyPk9uZSB3YXkgdG8gZG8gZ2V0IHRoZXJlIHdvdWxkIGJlIHRvIHJlbGF4IHRoZSAi
bm8gcHVibGljIGF1eGlsbGlhcnkgY2xhc3NlcyIgcnVsZSB0byBwZXJtaXQgZm9yIHNlYWxlZCBj
bGFzc2VzLCBzYXk6IAphbGxvd2luZyBwdWJsaWMgYXV4aWxsaWFyeSBzdWJ0eXBlcyBvZiB0aGUg
cHJpbWFyeSB0eXBlLCBpZiB0aGUgcHJpbWFyeSAKdHlwZSBpcyBwdWJsaWMgYW5kIHNlYWxlZC4m
bmJzcDsgPGJyPjxicj5Bbm90aGVyIHdvdWxkIGJlIHRvIGJvcnJvdyBhIHRyaWNrIGZyb20gZW51
bXM7IGZvciBhIHNlYWxlZCB0eXBlIHdpdGggbmVzdGVkIHN1YnR5cGVzLCB3aGVuIHlvdSBgaW1w
b3J0YCB0aGUgc2VhbGVkIHR5cGUsIHlvdSBpbXBsaWNpdGx5IGltcG9ydCB0aGUgbmVzdGVkIHN1
YnR5cGVzIHRvby4mbmJzcDsgVGhhdCB3YXkgeW91IGNvdWxkIGRlY2xhcmU6PGJyPjxicj4mbmJz
cDsmbmJzcDsmbmJzcDsgc2VtaS1maW5hbCBpbnRlcmZhY2UgTm9kZSB7IDxicj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhc3MgQSBpbXBsZW1lbnRzIE5vZGUg
eyB9PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFzcyBC
IGltcGxlbWVudHMgTm9kZSB7IH08YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDxicj4K4oCLYnV0IGNsaWVudHMgY291bGQgaW1wb3J0IE5vZGUgYW5kIHRoZW4g
cmVmZXIgdG8gQSBhbmQgQiBkaXJlY3RseTo8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBzd2l0
Y2ggKG5vZGUpIHsgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBjYXNlIEEoKTogLi4uPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBjYXNlIEIoKTogLi4uPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPjxicj5XZSBkbyBz
b21ldGhpbmcgc2ltaWxhciBmb3IgYGVudW1gIGNvbnN0YW50cyB0b2RheS48YnI+PGJyPjxicj48
        L3R0Pjxicj4KPC90dD48L3R0PgogIAoK" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;">​</div>
    </div><br></blockquote></div></div></body></html>