<div dir="ltr">On Mon, Jun 27, 2016 at 6:47 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
on Thu Jun 23 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
</span><span class="">> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
>> ><br>
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>><br>
>> wrote:<br>
>> >> That's a really interesting idea. Is "Syntax" a placeholder, or is that<br>
>> the intended name?<br>
>> ><br>
>> > It is the best name we could come up with, we are open to better<br>
>> suggestions.<br>
>><br>
>> I guess it depends on the intended semantics of the "namespace". If the<br>
>> purpose is to be a container for the various LiteralConvertible protocols,<br>
>> then maybe something like `AcceptsLiteralType.Integer` might be better?<br>
>> It's a bit wordy, though.<br>
>><br>
><br>
> I get what's being aimed at here, but I think the meaning of `Syntax` in<br>
> this context is indecipherable. IIUC, the point to be conveyed by the term<br>
> is that a literal has no type until it is supplied as an argument to the<br>
> initializer and becomes typed.<br>
<br>
</span>No, it has no type until its type is deduced. No initializer call<br>
appears in the source. Supplying the argument to the initializer is<br>
merely the mechanism by which the compiler constructs the value once the<br>
type is deduced.<br></blockquote><div><br></div><div>Right. Sorry, clearly a brainfart there on my part.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> Maybe we could say that the type gives form to the literal or embodies<br>
> the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or<br>
> `IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.<br>
<br>
</span>The first two names are so esoteric that I can't imagine them being anything but<br>
confusing, and “Modeling” is redundant; everything that conforms to a<br>
protocol models that protocol.<br>
<br>
If we were to add words to the name, I'd go with<br>
<br>
IntegerLiteralExpressible<br></blockquote><div><br></div><div>I think that sounds wonderful.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I *think* I still would want to sink this name into the Syntax<br>
namespace, though.<br></blockquote><div><br></div><div>`Syntax.IntegerLiteralExpressible` absolutely makes sense to me. To me, this says, the conforming type is integer literal expressible, which falls under the umbrella of syntax. Somehow, `Syntax.IntegerLiteral` just does not compute in my head, maybe because instinctively it looks like something should come after "literal," and using "syntax" to plug that hole doesn't yield an interpretable name.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="im"><br>
>> >> Also, why an enum? Especially one without any cases...<br>
>> ><br>
>> > It is not possible to create an instance of an enum that does not have<br>
>> > cases. It becomes essentially a namespace.<br>
>><br>
>> Oh that's a clever work-around. I like it :-)<br>
>><br>
>> - Dave Sweeris<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
</span><span class=""><font color="#888888">--<br>
Dave<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>