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

[Matthew Johnson]

Sent from my iPad

> On Feb 19, 2017, at 9:57 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

+1.  I cover a design to enable this in my value subtyping manifesto.

> 
> 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.

I would love to hear your thoughts on my value subtyping manifesto which covers a plethora of enum enhancements, including everything relevant to and discussed in this thread.

That said, there are cases where enums are not appropriate and a closed protocol is more appropriate.  Specifically when the set of types is expected to evolve over time or is large enough that an enum is a bit unwieldy, but is still intended to be controlled by the library.  In these cases you may well prefer to use polymorphism rather than switch statements in the implementation.  

I see no reason to have "one true way".  Each approach has pros and cons.  An engineering tradeoff is required.  The fact that one solution may be the most appropriate in the majority of cases is no reason to preclude the alternative from being available.  It may be the better choice in a nontrivial minority of cases, which is plenty frequently enough to justify its availability.

> 
> 
>> 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
> _______________________________________________
> 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/20170219/42c7ac4a/attachment.html>