on Thu Jun 23 2016, Xiaodi Wu <swift-evolution@swift.org> wrote: > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > On Jun 22, 2016, at 19:35, Dmitri Gribenko <griboz...@gmail.com> wrote: >> > >> >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris <daveswee...@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
