I'd call it an antipattern: it pretty much defeats the purpose of having
the ExpressibleBy*Literal protocols.
If you just want a type to be constructible from a value of some other type
(literal or not), that's what regular initializers are for. For example, in
addition to its ArrayLiteralConvertible conformance, Set provides init<S:
Sequence where S.Iterator.Element == Element>(_ seq: S), so you can write
Set([1, 2, 3]). The literal protocols are different because they're invoked
*implicitly*: doSomethingWithASet([1, 2, 3]).
They're also awkward, because the argument labels (integerLiteral:,
arrayLiteral:, nilLiteral:) provide only type information, and not "role"
information — and if you're invoking one of these inits explicitly, there's
no way the compiler can enforce that you're actually passing a *literal* in
for those parameters (in fact, you *can't* pass an array literal to
init(arrayLiteral:), because it's a variadic parameter rather than an array
On Mon, Jul 11, 2016 at 5:22 PM, David Sweeris <email@example.com> wrote:
On Jul 11, 2016, at 19:13, Jacob Bandes-Storch via swift-evolution < > firstname.lastname@example.org> wrote:
I'd be happy with a warning + fix-it too.
On Mon, Jul 11, 2016 at 5:05 PM, Xiaodi Wu <email@example.com> wrote:
Maybe just a warning + fix-it would be sufficient?
On Mon, Jul 11, 2016 at 19:02 Jacob Bandes-Storch via swift-evolution < >> firstname.lastname@example.org> wrote:
Tangential: Is there any way to make it impossible to call these
literal-initializers explicitly, instead requiring "<literal> as T" or just
"<literal>" in a typed context?
I have seen several explicit calls of these initializers where literals
would have been more appropriate, such as "Set(arrayLiteral: foo, bar)",
and I think this only happens because folks find these initializers via
code completion. I can't think of any reason why you'd want to invoke one
by name rather than by using a literal.
I don't see how this is a problem.
- Dave Sweeris