[swift-evolution] Revisiting SE-0041 Names

[Dave Abrahams]

on Thu Jun 23 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jun 22, 2016, at 19:35, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> >
>> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <davesweeris at mac.com>
>> wrote:
>> >> That's a really interesting idea. Is "Syntax" a placeholder, or is that
>> the intended name?
>> >
>> > It is the best name we could come up with, we are open to better
>> suggestions.
>>
>> I guess it depends on the intended semantics of the "namespace". If the
>> purpose is to be a container for the various LiteralConvertible protocols,
>> then maybe something like `AcceptsLiteralType.Integer` might be better?
>> It's a bit wordy, though.
>>
>
> I get what's being aimed at here, but I think the meaning of `Syntax` in
> this context is indecipherable. IIUC, the point to be conveyed by the term
> is that a literal has no type until it is supplied as an argument to the
> initializer and becomes typed. 

No, it has no type until its type is deduced.  No initializer call
appears in the source.  Supplying the argument to the initializer is
merely the mechanism by which the compiler constructs the value once the
type is deduced.  

> Maybe we could say that the type gives form to the literal or embodies
> the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or
> `IntegerLiteralManifestation`, maybe even `IntegerLiteralModeling`.

The first two names are so esoteric that I can't imagine them being anything but
confusing, and “Modeling” is redundant; everything that conforms to a
protocol models that protocol.

If we were to add words to the name, I'd go with

   IntegerLiteralExpressible

I *think* I still would want to sink this name into the Syntax
namespace, though.

>> >> Also, why an enum? Especially one without any cases...
>> >
>> > It is not possible to create an instance of an enum that does not have
>> > cases.  It becomes essentially a namespace.
>>
>> Oh that's a clever work-around. I like it :-)
>>
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave