<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro <span dir="ltr"><<a href="mailto:jonathan.s.shapiro@gmail.com" target="_blank">jonathan.s.shapiro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>A few other thoughts:</div><div><br></div><div>* One of our (or at least my) overarching goals for this proposal is to refine identifier and operator sets by moving away from an ad-hoc character-by-character approach to a systematic treatment that relies on well-defined criteria to select blocks of characters for inclusion.</div></div></blockquote><div><br></div><div>I completely agree with this, up to the point where you wrote "select blocks". That doesn't seem to be the way things are selected in the Unicode universe.</div><div><br></div><div>We can choose to adopt blocks as an interim measure, but we should not loose sight of the notion that this should eventually be property-driven.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* Particularly if the community insists on emoji being identifiers, we will have to critically evaluate how to proceed on that in tandem with operators, because there exist emojified operators and arrows, and certain emoji are encoded in blocks that are otherwise symbols, which Unicode is likely to deem as operators in the future.</div></div></blockquote><div><br></div><div>This is not correct. The current view in the UAX31 discussion is that emojis and pictographics should be excluded from <i>both</i> types of identifiers so that individual programming languages can make language-specific choices.</div></div></div></div></blockquote><div><br></div><div>This proposed approach raises some issues with apparent inconsistency as well as forward compatibility issues. What I'm saying is that today, among a chunk of symbols which Unicode may deem to be operators, there will be some with emoji variants and others without. It seems kinda arbitrary to exclude specific arrows or specific dingbats from valid operator characters on the criterion that they have an emoji variant. For instance, if curly leftwards arrow has an emoji variant but curly upwards arrow does not, one is considered an invalid operator but the other is valid? Now, going forward, if an existing codepoint is today part of IDC_Start but tomorrow gains an emoji variant, what happens then?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The main current problem is that there is no clear-cut Unicode property covering Emojis at the present time, which is something that needs to be resolved over in Unicode-land. There is a list given in the antique texty UCD file format, but it isn't part of the XML formulation of the UCD database. I'll be generating a proposed update shortly, and when I have that I can provide a working list in the form of a C file that can be used by Swift.</div><div><br></div><div>I have a mild preference that emojis should live in conventional identifiers if they are adopted.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> Moreover, IIUC, certain codepoints can be either emoji or non-emoji symbols and variant selectors can specify which they are...</div></div></blockquote><div><br></div><div>Can you expand on this and (hopefully) point me at the appropriate spot in one of the Unicode TRs?</div><div><br></div><div><br></div><div>Thanks!</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Jonathan</div></font></span></div></div></div>
</blockquote></div><br></div></div>