The reason you should not conform to _ExpressibleByBuiltinIntegerLiteral is that your type does not conform to the semantics of that protocol.<br><br>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.<br><br>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&#39;s a non-goal for the compiler to stop you. I would imagine (although the core team should correct me if I&#39;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.<br><br>It&#39;d be quite the sledgehammer to bring down source-breaking syntax changes in order to help the compiler enforce one particular semantic requirement, no?<br><br>As to enums, I&#39;m sure you&#39;re aware that it&#39;s a straw man argument you&#39;re bringing up.<br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 19, 2017 at 18:02 Adrian Zubarev &lt;<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><pre class="gmail_msg"><code class="m_-297985603781354445swift gmail_msg">struct A : _ExpressibleByBuiltinIntegerLiteral {
    init() {}
    init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {}
}

struct B : ExpressibleByIntegerLiteral {
    init(integerLiteral value: A) {}
}

B(integerLiteral: A())
</code></pre>

<p class="gmail_msg">Here is another example. Am I supposed to do that? Definitely not. Your lovely question: <strong class="gmail_msg">Why not?</strong> Because the protocol starts with an underscore. So? Doesn’t prevent me from abusing all semi-hidden protocols.</p>

<p class="gmail_msg">Where is the enum now to stop me from doing this?</p>

<p class="gmail_msg">Enums are so heavily abused in Swift, just because they have a special ability not being extensible with a constructor. </p></div></blockquote></div>