<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 3:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><div class=""><div class="m_198149996986737806h5"><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 3:24 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_198149996986737806m_1257890731088026351Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><div class=""><div class="m_198149996986737806m_1257890731088026351h5"><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 3:05 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson<span class="m_198149996986737806m_1257890731088026351m_8134965734137653328Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.co<wbr class="">m</a>></span><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 2:25 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson<span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.co<wbr class="">m</a>></span><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 2:01 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson<span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.co<wbr class="">m</a>></span><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-"><div class=""><br class="">On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Cool. Another avenue of improvement here is relaxing the single-class spelling rule for the sake of composing typealiases.<br class=""><br class="">As Matthew mentioned, if I have class Base and typealiases Foo = Base & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & Bar.<br class=""><br class="">It'd be nice to go one step further: given class Derived : Base, if I have typealiases Foo2 = Base & Protocol1 and Bar2 = Derived & Protocol2, then it could be permitted to write Foo2 & Bar2, since there is effectively only one subclass requirement (Derived).<br class=""><br class="">As I understand it, the rationale for allowing only one subclass requirement is that Swift supports only single inheritance. Thus, two disparate subclass requirements Base1 & Base2 would make your existential type essentially equivalent to Never. But Base1 & Base1 & Base1 is fine for the type system, the implementation burden (though greater) shouldn't be too awful, and you would measurably improve composition of typealiases.<br class=""></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, this is what I was indicating in my post as well.</div><div class=""><br class=""></div><div class="">Are you suggesting that Base1 & Base2 compose to a type that is treated identically to Never do you think it should be an immediate compiler error? I remember having some discussion about this last year and think somebody came up with a very interesting example of where the former might be useful.</div></div></blockquote><div class=""><br class=""></div><div class="">Last year's discussion totally eludes me for some reason. But sure, if deferring the error until runtime is actually useful then why not? In the absence of an interesting use case, though, I think it'd be nice for the compiler to warn you that Base1 & Base2 is not going to be what you want.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Deferring to runtime isn’t what I mean. If you try to actually *do* anything that requires an instance of `Base1 & Based` (which you almost always would) you would still get a compile time error.</div><div class=""><br class=""></div><div class="">I managed to dig up the example from last year’s thread and it is definitely a good one:</div><div class=""><br class=""></div><div class="">func intersection<T, U>(ts; Set<T>, us: Set<U>) -> Set<T & U></div><div class=""><br class=""></div><div class="">The desire is that we are always able to produce a result set. When T & U is uninhabitable it will simply be an empty set just like Set<Never> has a single value which is the empty set.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Currently, Set<Never> is impossible because Never is not Hashable :)</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Ahh, good point. I hadn’t tried it. It can easily be made Hashable with a simple extension though - this code compiles today:</div><div class=""><br class=""></div><div class="">extension Never: Hashable {<br class=""> public var hashValue: Int { <wbr class="">return 0 }<br class="">}<br class="">public func ==(lhs: Never, rhs: Never) -> Bool { return false }<br class="">let s = Set<Never>()</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Since concrete types *can't* be used, this example seems like it'd be of little use currently. How widely useful would it be to have an intersection facility such as this when T != U even if that restriction were lifted, though? Seems like the only real useful thing you can do with generic Set<T & U> is based on the fact that it'd be Set<Hashable>. Other than those immediate thoughts, I'll have to think harder on this.</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Sure, it’s possible that this is the only interesting example and may not have enough value to be worthwhile. But I found it interesting enough that it stuck around in the back of my mind for 8 months! :) </div></div></div></blockquote><div class=""> </div><div class="">Hmm, it had not occurred to me: instantiating a Set<Hashable> is not supported (and you can substitute for Hashable any protocol you want). Thus, for any Set<T> and Set<U> that you can actually instantiate, unless T and U are both classes and one inherits from the other (in which case the generic `intersection<X>(a: Set<X>, b: Set<X>) -> Set<X>` already suffices), Set<T & U> must be the empty set. This is not a very interesting result.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Yes, but this is a limitation due to the fact the existentials for a protocol do not conform to the protocol. In some cases the existential *cannot* conform to the protocol but in many cases (especially common cases) it *can*. It just doesn’t today. There is widespread desire to see this situation improve.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure, but when will be the day that existentials conform to their own protocol when they can do so, *and* we extend `&` to value types (probably not until they can express some sort of meaningful subtyping relationship to each other)?</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">I hope it isn’t *too* long before existentials conform to their own protocol at least in simple cases - Swift 5 if it doesn’t make it into Swift 4.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I will bet you two virtual alcoholic beverages that it won't happen before Swift 7 or one that it won't happen before Swift 9.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">I am suggesting this proposal be generalized such that it discusses concrete subtype / supertype relationships rather than restricting it’s scope to classes. If that approach is adopted then `&` would allow value types as soon as this proposal is implemented.</div><div class=""><br class=""></div><div class="">It seems arbitrary and unnecessary to restrict it to classes even if that is where it would be most useful when it is first implemented.</div></div></div></blockquote><div class=""><br class=""></div><div class="">One can naturally relax the rules in tandem with the design and implementation of prerequisite features that make the more relaxed rules useful. The point I'm trying to make is: there is currently no value of X for which the following statement holds true--</div><div class=""><br class=""></div><div class="">"If only it weren't for the restriction against writing `Base1 & Base2`, I'd be able to implement the interesting algorithm X."</div><div class=""><br class=""></div><div class="">So it seems reasonable to error on `Base1 & Base2`.</div></div></div></div></div></blockquote><div><br class=""></div>If you’re right about the timeline for existentials conforming to their protocols I would agree with you wholeheartedly. I’m not sure why we have such different perspectives on when that might happen. It has certainly received plenty of demand from the community and caused some degree of confusion, usually in relatively simple cases (since we only have relatively simple existentials today).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">At that point, I'd advocate for using compiler magic to make uninhabited types like Never a subtype of all types conforming to all protocols. Then, we could actually write Set<Never> without having to implement conformance to Hashable by writing a bogus `==` function. And we could replace EmptyCollection with Collection<Never> and simplify the standard library API surface that way (since Array<Never>() would then be a value of type Array<T>, etc.). And, your demonstrated use case would become interesting. Since there is a pretty good chance that you and I won't be alive by then, I'm happy to punt on the ideation process for this :)</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">It generalizes easily to any cases where you have a generic type that is useful despite not necessarily having access to instances of the parameterized type.</div><div class=""><br class=""></div><div class="">If we allow this, I *think* all uninhabitable types could be unified semantically by making `Never` a protocol and giving them implicit conformance.</div><span class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">This example points even more strongly in the direction of allowing *any* concrete type to be used, not just classes - even today we could produce uninhabitable existentials like this using value types.</div><div class=""><br class=""></div><div class="">Here’s the link to the thread:<span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019463.html" target="_blank" class="">https://lists.swift.or<wbr class="">g/pipermail/swift-evolution/We<wbr class="">ek-of-Mon-20160523/019463.html</a></div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-"><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jan 29, 2017 at 12:41 Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The "class comes first" requirement made more sense when the proposed syntax was still "Any<T, U, V>", intentionally mirroring how the superclass and conformances are declared on a class declaration (the archives contain more detailed arguments, both pro and con). Now that the syntax is "T & U & V", I agree that privileging the class requirement is counterintuitive and probably unhelpful.<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">Austin<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> On Jan 29, 2017, at 10:37 AM, Matt Whiteside via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> Thanks for writing this proposal David.<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">>> On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">>><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">>> As Matthew mentioned, the rules can certainly later be relaxed, but given that this proposal has the compiler generating fix-its for subclasses in second position, is there a reason other than stylistic for demanding MyClass & MyProtocol instead of MyProtocol & MyClass?<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">>><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">>> From a naive perspective, it seems that if the compiler understands my meaning perfectly, it should just accept that spelling rather than complain.<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> I had that thought too. Since ‘and’ is a symmetric operation, requiring the class to be in the first position seems counter-intuitive.<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> -Matt<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> ______________________________<wbr class="">_________________<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">> swift-evolution mailing list<br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">><span class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">https://lists.swift.org/mail<wbr class="">man/listinfo/swift-evolution</a><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_198149996986737806m_1257890731088026351m_8134965734137653328m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"></blockquote></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></span></div></blockquote></span></div></blockquote></div></div></div></div></blockquote></span></div></div></blockquote></div></div></div></blockquote></span></div></div></blockquote></div></div></div></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>