[swift-evolution] TreeLiteralConvertible

[davesweeris at mac.com]

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 at swift.org> wrote:
> 
>> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon <brent at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution