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 parameter). Jacob On Mon, Jul 11, 2016 at 5:22 PM, David Sweeris <[email protected]> wrote: > On Jul 11, 2016, at 19:13, Jacob Bandes-Storch via swift-evolution < > [email protected]> wrote: > > > I'd be happy with a warning + fix-it too. > > On Mon, Jul 11, 2016 at 5:05 PM, Xiaodi Wu <[email protected]> wrote: > >> Maybe just a warning + fix-it would be sufficient? >> >> On Mon, Jul 11, 2016 at 19:02 Jacob Bandes-Storch via swift-evolution < >> [email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
