<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jun 3, 2016, at 8:51 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 10:31 PM, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><div class=""><div dir="auto" class=""><div class="">On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class="">The official way to build a literal of a specific type is to write the literal in an explicitly-typed context, like so:<div class=""><font face="Andale Mono" class=""> let x: UInt16 = 7</font></div><div class="">or</div><div class=""><font face="Andale Mono" class=""> let x = 7 as UInt16</font></div><div class=""><br class=""></div><div class="">Nonetheless, programmers often try the following:</div><div class=""><font face="Andale Mono" class=""> UInt16(7)</font></div><div class=""><br class=""></div><div class="">Unfortunately, this does <i class="">not</i> attempt to construct the value using the appropriate literal protocol; it instead performs overload resolution using the standard rules, i.e. considering only single-argument unlabelled initializers of a type which conforms to IntegerLiteralConvertible. Often this leads to static ambiguities or, worse, causes the literal to be built using a default type (such as Int); this may have semantically very different results which are only caught at runtime.</div><div class=""><br class=""></div><div class="">In my opinion, using this initializer-call syntax to build an explicitly-typed literal is an obvious and natural choice with several advantages over the "as" syntax. However, even if you disagree, it's clear that programmers are going to continue to independently try to use it, so it's really unfortunate for it to be subtly wrong.</div><div class=""><br class=""></div><div class="">Therefore, I propose that we adopt the following typing rule:</div><div class=""><br class=""></div><div class=""> Given a function call expression of the form A(B) (that is, an <i class="">expr-call</i> with a single, unlabelled argument) where B is an <i class="">expr-literal</i> or <i class="">expr-collection</i>, if A has type T.Type for some type T and there is a declared conformance of T to an appropriate literal protocol for B, then the expression is always resolves as a literal construction of type T (as if the expression were written "B as A") rather than as a general initializer call.</div></div></blockquote><div class=""><br class=""></div><div class="">Looking transversally at all literal protocols as this proposes to operates reminds me that the knowledge that a protocol has the right semantic is based on a convention, rather than on conformance. Would it be conceibable to look into something like the following, that all others would specialize.</div><div class=""><br class=""></div><div class="">protocol LiteralConvertible {}</div><div class=""><br class=""></div><div class="">This might offer a stronger identification than the name. It might also be interesting to define an associated type, but that would exclude NilLiteralConvertible.</div><div class=""><br class=""></div><div class=""><br></div></div></div></blockquote><div><br class=""></div>I don't know what you're saying here. Literal types already do explicitly conform to a protocol that's specific to the literal; it's not just convention. </div></blockquote><div><br></div><div>Sorry for my lack of clarity. Each literal type (string/int/array...) is independent from the others, forming a 'set' only in appearance. And in the compiler, they must all be declared individually in knownprotocols.def. Which then means that these are the only literals, which the compiler knows and can reason about now and for ever. And then if users write a hypothetical XyzLiteralConvertible, there is no chance for the compiler to ever treat it like the builins.</div><br><blockquote type="cite"><div><div> There's nothing linking those protocols because there's no useful operation in common: there is no useful generic code that you can write that works for an arbitrary type that allows some unknown kind of literal.</div></div></blockquote><div><br></div><div>I believe I understand. I come from a heavy java/scala background, with lots of reflection/invokedynamic/bytecode work, so it looked like a bit of missed opportunities for some future proofing of the runtime. Particularly being able to discover at compile-time additional protocols than those listed statically in knownprotocols.def</div><br><blockquote type="cite"><div><div> We intentionally do not add protocols that do not serve some useful purpose in generic programming.</div></div></blockquote><div><br></div><div>I understand and respecfully point to a discrepancy with this logic: the existance of the _builtinxxx underlying layer. To me it says that some protocols (there are others) do carry a compiler oriented semantic, and when i found it i took it as the sign that the team was willing to consider that it was worth using the language constructs to encode some of its semantics, in the name of creating future proofing or simplifying the compiler source. <span style="background-color: rgba(255, 255, 255, 0);">But your answer is clear, and I now understand it as: _builtinxxxliteral is an exceptional case, not necessarily a design principle or future proofing tool.</span></div><div><br></div><blockquote type="cite"><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Note: as compiler expert, I would appreciate your thinking on the notion of formally expressing what might otherwise be a known strong semantic relationship. Is there any incentive to pursue, known disavantages, ...</span></font></div></div></div></blockquote></blockquote><div><br></div>This part was an extension on future proofing another part of the library where there is IMHO a real incentive for formalizing what exists today, considering it will likely never change and is already a source of questions. I am still trying to find a formalism that would align with how the library and compiler are designed, so it will be its own topic. Thank you for taking the time.<div><div><div><br><blockquote type="cite"><div><div><br class=""></div><div>John.</div></div></blockquote></div></div></div></body></html>