The reason you should not conform to _ExpressibleByBuiltinIntegerLiteral is that your type does not conform to the semantics of that protocol.
Every protocol guarantees both syntax and semantics. (Well, almost every protocol; Error has no syntactic requirements at all, only semantic ones.) However, the compiler (in general) checks only syntax. For instance, it can ensure that your Equatable type implements ==, but it cannot check whether that function actually adheres to the three semantic requirements for equality. So, in that light, you can offer an infinite list of examples where you conform a type to a protocol that others might judge questionable. You might implement == to check for inequality, and then conform that type to Equatable. You might name a type Success and conform it to Error. It's a non-goal for the compiler to stop you. I would imagine (although the core team should correct me if I'm wrong) that a similar line of reasoning is why the standard library authors are not extremely bothered that you are not restrained by the compiler from conforming to _ExpressibleByBuiltinIntegerLiteral. It'd be quite the sledgehammer to bring down source-breaking syntax changes in order to help the compiler enforce one particular semantic requirement, no? As to enums, I'm sure you're aware that it's a straw man argument you're bringing up. On Sun, Feb 19, 2017 at 18:02 Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > struct A : _ExpressibleByBuiltinIntegerLiteral { > init() {} > init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {} > } > > struct B : ExpressibleByIntegerLiteral { > init(integerLiteral value: A) {} > } > > B(integerLiteral: A()) > > Here is another example. Am I supposed to do that? Definitely not. Your > lovely question: *Why not?* Because the protocol starts with an > underscore. So? Doesn’t prevent me from abusing all semi-hidden protocols. > > Where is the enum now to stop me from doing this? > > Enums are so heavily abused in Swift, just because they have a special > ability not being extensible with a constructor. >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution