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

[Xiaodi Wu]

Left unsaid from my reply about enums is that implicit conversions should
absolutely be added. We already have this magic for one particular enum,
Optional.

I'm not arguing with you that enums are currently unsuitable. In fact I
entirely agree. But Chris Lattner and others have said (now I'm
paraphrasing, but I believe accurately) that they *should* be. What will it
take? At minimum, some way to opt into implicit conversions. It's a
no-brainer in my mind.

Bottom line: the language needs one excellent way to model Foo | Bar | Baz,
not two or three mediocre workarounds. The core team has said that they
want that excellence to be built through enums. Let's do it.


On Sun, Feb 19, 2017 at 21:28 Zach Waldowski via swift-evolution <
swift-evolution at swift.org> wrote:

> On Sun, Feb 19, 2017, at 06:40 PM, Xiaodi Wu via swift-evolution wrote:
>
> On Sun, Feb 19, 2017 at 5:15 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> What is the harm of permitting an outside conformance to `SQLiteValue`?
>
>
> I'll put words in Brent's mouth here as an attempt at an answer: you
> sometimes need to exclusively switch a downcast of an existential. Consider
> a serialization type - or SQLiteValue - where need to treat specific
> fundamental types ("primitives") in implementation-dependent ways. In a
> theoretical serialization design, all non-primitives would have an explicit
> protocol of semantics to conform to support serialization, much like the
> stdlib's "Custom" protocol pattern, and you compose from there.
>
> Using an enum to represent this exclusivity remains unconvincing to me,
> unless we choose to add implicit conversions to the language. `.int(42)` is
> an overwhelming level of duplicate type information in any practical,
> non-trivial use case. Yes, (closed) enums model exclusivity. They are not
> the only things to do so.
>
> The stdlib alone is reason enough for this feature to exist, even if not
> exposed publicly.
>
> Zachary
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/6d59115b/attachment.html>