Sent from my iPad
> On Feb 19, 2017, at 9:57 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@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@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
