<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I concur with Taylor and John on this particular issue. As much as I use annotations in my daily work, I wouldn’t want the language cluttered up and there will always be industry unique annotations that would be frustratingly unsupported (e.g. I say “j” and you say “i”). <div class="">dennis.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 02:23 AM, John McCall 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">not to rain on anyone’s parade here but y’all are aware unicode superscripts don’t even form a complete alphabet right? This kind of syntax would really only work for positive integer literals and I don’t think making a wholesale change to the language like this is worth that.<br class=""></div></div></blockquote><div class=""><br class=""></div>I agree with this and would add only that making Swift code look like idiomatic math notation is a huge problem and will probably never yield satisfactory results. Anyone who's really interested in this would probably be much better off writing a source-to-source transformation that started with the mathematical markup of their choice and just rewrote it as idiomatically as possible.</div><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 5, 2017 at 1:19 AM, Swift via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="">Going a little further...<div class=""><br class=""></div><div class="">It’s not hard to imagine a situation where the <i class="">order</i> of a trailing annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared sub 3 ≠ X sub 3 squared)</div><div class=""><br class=""></div><div class="">So i think you’d want an array of trailing annotations and an array of leading annotations, where an annotation is either a .superscript(U) or a .subscript(V). That way you’d be able to preserve the (potentially) relevant order. </div><div class=""><br class=""></div><div class="">Dave<br class=""><br class=""><div id="m_5504207695486733286AppleMailSignature" class="">Sent from my iPhone</div><div class=""><div class="h5"><div class=""><br class="">On Oct 5, 2017, at 12:04 AM, John Payne 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 class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Chris Lattner wrote:<br class=""><br class=""><blockquote type="cite" class="">Just FWIW, IMO, these make sense as operators specifically because they are commonly used by math people as operations that transform the thing they are attached to. Superscript 2 is a function that squares its operand. That said, perhaps there are other uses that I’m not aware of which get in the way of the utilitarian interpretation.<br class=""></blockquote><br class="">But there are SO MANY uses for superscripts, subscripts, and other such annotations, and they are all context specific, just in math, without getting into chemistry, physics, statistics, and so forth.<br class=""><br class="">They’re really more like methods on the object to which they’re attached, or the combination of a method and an argument. <br class=""></blockquote><br class="">I agree.<br class=""><br class=""><blockquote type="cite" class="">Wouldn’t classing them as identifiers lend itself better to this?<br class=""></blockquote><br class="">No, making them an operator is better for this usecase.<br class=""><br class="">You want:<br class=""><br class="">x² to parse as “superscript2(x)” - not as an identifier “xsuperscript2” which is distinct from x.<br class=""><br class="">-Chris</blockquote><br class=""></div><div class="">I’m not competent to evaluate the implications of that, but let me just pass along what makes sense to me. For all I know it may be a restatement in different words, or a higher level view which your approach enables, or I may just have no grasp at all of what’s involved.</div><div class=""><br class=""></div><div class="">For brevity I’ll refer to superscripts, subscripts, etc. as annotations.</div><div class=""><br class=""></div><div class="">An object may have more than one annotation, as with chemical elements which are usually presented at least with both their atomic number and atomic weight. Moreover, in some circumstances it might not be possible to evaluate the significance of any single annotation without taking one or more others into account, so it might be important to present them together, as in a struct or a collection.</div><div class=""><br class=""></div><div class="">Taking them singly, their significance is three part: 1) the type of the object, 2) the position of the annotation, and 3) the value of the annotation.</div><div class=""><br class=""></div><div class="">I would parse x² as x.trailingSuperscript(2), or better yet…</div><div class=""><br class=""></div><div class="">where X is the type of x, X.annotations would be a struct, similar to the following</div><div class=""><br class=""></div><div class="">struct annotations {</div><div class=""> leadingSuperscript: T?</div><div class=""> leadingSubscript: U?</div><div class=""> triailingSuperscript: V?</div><div class=""> trailingSubscript: W?</div><div class="">}</div><div class=""><br class=""></div><div class="">Taking this approach, x² would parse as x.annotations.<wbr class="">trailingSuperscript = 2, and would fail if X made no allowance for trailingSuperscripts.</div><div class=""><br class=""></div><div class="">Annotation values are frequently variables, xⁿ for example, and this is the main reason it seems reasonable to me to class the value as anything permitted by the type associated with an annotation in that position for the overall type in question.</div><div class=""><br class=""></div><div class="">I’ll read any replies with interest, but I don’t think I'll have anything more to say on this subject myself.</div><div class=""><br class=""></div></div></blockquote></div></div><span class=""><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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></div></blockquote></span></div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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=""></div></body></html>