[swift-evolution] [Draft] open and public protocols

[Xiaodi Wu]

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.zubarev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/41fd5a95/attachment.html>