<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="">On 20 Jun 2016, at 21:07, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Mon, Jun 20, 2016 at 2:42 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=""><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="">I agree that treating zero-width spaces as non-existent would be a possible solution, but I think it would make more sense to consider it as white space and thus not admissible in identifier names.</div></blockquote><div class=""><br class=""></div><div class="">If you treat it like whitespace, then you get interesting behaviors that I don't think you would want. For example, something that looks like `if letter...` could be parsed as conditional binding `if let ter...` if I put in a zero-width space in the right place.</div></div></div></div></div></blockquote><div><br class=""></div>I hadn't thought of that possibility. Ignoring them has the problem of creating multiple valid representations for the same identifier though. Not allowing invisible characters in identifiers sounds like the best solution to me.</div><div><br class=""></div><div><blockquote type="cite" class=""><div dir="ltr" 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="">I'm not sure of what the best way to handle left-to-right and right-to-left markers would be. Does it make sense to allow mixed text orientation in identifiers?</div></blockquote><div class=""><br class=""></div><div class="">How do other languages that support Unicode handle these markers in identifiers? I'd be interested to know.</div></div></div></div></blockquote><div><br class=""></div><div>Me too.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" 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=""><div class="">Removing ambiguity between unicode confusables is a much more complicated issue which implies defining a canonical unicode representation for identifiers and a way to resolve them. It would also make it impractical to use certain valid mathematical symbols as identifiers.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Most interesting mathematical symbols are reserved for operators anyway. As a result, `x` and the multiplication symbol are not readily confusable in most contexts in Swift, and confusable resolution could be built in such a way that identifier characters are not regarded as confusable with operator characters.</div></div></div></div></blockquote><br class=""></div><div>That would require maintaining a large list of exception characters though. Just like the problem with ignoring invisible characters mentioned above, eliminating confusables has the problem of creating multiple representations for the same identifier, which could become quite confusing and result in additional problems of its own. I think it would probably be best to avoid a situation where it's necessary to resolve different representations of an identifier.</div><div><br class=""></div><div>Sincerely,</div><div>João Pinheiro</div></body></html>