The topic’s come up before. I’m in favor of it, but IIRC there are two problems
that need to be resolved first:
(I *think* I’m remembering this correctly… don’t quote me on this…)
First, it can cause the type-checker to become “pathological”.
Second, it can cause some *very* unexpected behavior if things are implicitly
converted through different types than you thought.
- Dave Sweeris
> On Apr 14, 2016, at 4:24 PM, John McCall via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon <br...@architechies.com>
>> wrote:
>>> No, you just need Tree to conform to both ArrayLiteralConvertible and
>>> IntegerLiteralConvertible, and it implements the latter by building a Value
>>> out of it.
>>
>> That not only doesn't work if your type isn't a LiteralConvertible, it also
>> doesn't work if you want to build a literal with variables:
>>
>> let myTree: Tree = [1, [2, three]]
>>
>> The real missing feature here is implicit lifting like Optional offers. With
>> a LiftingConvertible protocol, you could say something like this:
>>
>> enum Tree<Value> {
>> case leaf(Value)
>> case branches([Tree<Value>])
>> }
>>
>> extension Tree: ArrayLiteralConvertible {
>> init(arrayLiteral branches: Tree<Value>...) {
>> self = .branches(branches)
>> }
>> }
>>
>> extension Tree: LiftingConvertible {
>> init(lifting value: Value) {
>> self = .leaf(value)
>> }
>> }
>
> Another name for this feature is "user-defined implicit conversions".
>
> John.
> _______________________________________________
> 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
