<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 Jun 27, 2016, at 8:46 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Mon Jun 27 2016, Erica Sadun <<a href="http://erica-at-ericasadun.com" class="">erica-AT-ericasadun.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Maybe we could say that the type gives form to the literal or embodies<br class="">the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or<br class="">`IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class=""><br class="">The first two names are so esoteric that I can't imagine them being anything but<br class="">confusing, and “Modeling” is redundant; everything that conforms to a<br class="">protocol models that protocol.<br class=""><br class="">If we were to add words to the name, I'd go with<br class=""><br class=""> IntegerLiteralExpressible<br class=""><br class="">I *think* I still would want to sink this name into the Syntax<br class="">namespace, though.<br class=""></blockquote><br class="">You didn't respond to my earlier suggestion so I'd like to pitch it again.<br class=""><br class="">What about "Syntax.IntegerLiteralConsumer", which suggests that<br class="">conforming types can consume integer literal syntax as native to their<br class="">type.<br class=""></blockquote><br class="">To me, the idea of a type (other than, say, a parser) consuming syntax<br class="">is pretty alien. So this one is sorta esoteric too, IMO.<br class=""><br class="">-- <br class="">Dave<br class=""></div></div></blockquote></div><br class=""><div class="">It may be sorta esoteric, but I'd say it's a fair degree clearer to the intended</div><div class="">audience of Swift developers.</div><div class=""><br class=""></div><div class="">I ran a one-question poll last night about "Syntax.IntegerLiteralExpressible".</div><div class="">I asked what Swift developers (who were not following this discussion) thought it</div><div class="">meant.</div><div class=""><br class=""></div><div class="">The results can be found here:</div><div class=""><a href="https://www.surveymonkey.com/results/SM-FGMC93JT/" class="">https://www.surveymonkey.com/results/SM-FGMC93JT/</a></div><div class=""><div class="">A tab at the top lets you view individual answers paired with explanations.</div></div><div class=""><br class=""></div><div class="">By a margin of at least like 9:1 (more if you include the freeform answers of "why" such as</div><div class="">answer 80, which says "It reminds me of StringLiteralExpressible which behaves that way.</div><div class="">But you're right, the name sounds like the other option.") developers thought that the </div><div class="">protocol meant (or should mean) that the conforming type could express itself as an integer </div><div class="">literal, and not that an integer literal can be expressed as the conforming type.</div><div class=""><br class=""></div><div class="">I encourage you to look at the individual responses. They include the freeform answers</div><div class="">that describe why each person chose as they did.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></body></html>