<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=""><div class="">Indeed, the case shown in Josh's example was the motivation for this thread and will be solved by the proposal.</div><div class=""><br class=""></div><div class="">The current discussion has been around whether it should be solved by ignoring invisible characters or prohibiting them and explicitly highlighting them as an error. I originally proposed prohibiting them and was convinced into thinking that ignoring them would suffice. Upon further reading of the unicode normalisation and security documents, I agree that prohibiting them outside of the situations described in UAX #31 is the best and safest choice.</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">João Pinheiro</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 23 Jun 2016, at 21:45, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Let me correct myself: what I think Josh's example is should be corrected whether we prohibit or ignore. However, since no one can see the invisible characters he used, I can't say for sure.<br class=""><br class="">If he found a clever way to reorder or change spacing between letters (e.g. superimpose two characters so that "var11" looks like "var1"), then the problem can only be fixed by prohibition.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 23, 2016 at 15:36 James Hillhouse <<a href="mailto:jdhillhouse4@icloud.com" class="">jdhillhouse4@icloud.com</a>> wrote:<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="">Thanks Xiaodi. That’s a relief to know.</div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 3:32 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class="">FWIW, Josh's example would be fixed whether we prohibit or ignore invisible characters, but there are other potential strings for which prohibition would be more secure.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 23, 2016 at 15:27 James Hillhouse <<a href="mailto:jdhillhouse4@icloud.com" target="_blank" class="">jdhillhouse4@icloud.com</a>> wrote:<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="">+1 on this. Josh Wisenbaker’s example says enough. Yikes!</div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class="">+1</div><div class="">I didn't even know there were any invisible characters until this thread came up.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class="">On Jun 23, 2016, at 15:13, 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=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro <span dir="ltr" class=""><<a href="mailto:joao@joaopinheiro.org" target="_blank" class="">joao@joaopinheiro.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br class="">
> On 23 Jun 2016, at 20:43, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class="">
> That's cool, although my preferred solution would be more closely aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX #31, then afterwards internally represent the identifier as its NFC-normalized string.<br class="">
<br class="">
</span>Explicitly disallowing them was my initial idea, but I think it would end up being a confusing error for users to encounter. Ignoring the invisible characters and leaving it up to a linter to remove them is less likely to cause confusion for users.<br class="">
<br class="">
I'll be sure to describe the alternative of explicitly prohibiting them in the proposal though.<br class=""></blockquote><div class=""><br class=""></div><div class="">I would strongly urge you to propose explicitly prohibiting them just as UAX #31 recommends. Their reasoning is that these characters, which include those that reverse text direction or control joining, can cause one identifier to be maliciously changed to look like another. If you ignore these characters instead of prohibiting them, an identifier that visually appears as one string could in fact be a different one to the compiler.</div><div class=""><br class=""></div><div class="">Moreover, a compiler error can be made helpful by saying that the offending character is potentially invisible and it can come with a fix-it to remove the offending character. I don't think that would confuse the user at all. It would be more confusing if invisible characters that caused one thing to look identical to another were silently permitted.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
Sincerely,<br class="">
João Pinheiro</blockquote></div><br class=""></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span 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/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>