> On Jul 11, 2016, at 7:34 PM, Jacob Bandes-Storch <[email protected]> wrote: > > 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).
Agreed... I don’t see the harm in letting someone use them if they want to. To be clear, I’m only pointing out that, IMHO, there’s not really a need to do the work of specifically disallowing this “antipattern”. If others think it’s important enough to bother with, I won’t complain. If we weren’t in the Swift 3 crunch, I might not have raised it at all. - Dave Sweeris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
