Hi John and Brent,
> On 14 Apr 2016, at 22:22, John McCall <rjmcc...@apple.com> wrote:
>
> multiple-conformance idea doesn't work
The idea is not multiple-conformance (or overloading), but multiple (two)
initialisers required by the literal-convertible protocols:
protocol TreeLiteralConvertible {
associatedtype LeafValue
init(literal: Self.LeafValue...)
init(literal: Self...)
}
… and:
protocol DictionaryTreeLiteralConvertible {
associatedtype Key
associatedtype LeafValue
init(literal: Self.LeafValue...)
init(literal: (Key, Self)...)
}
> Note that all of your examples rely not just on recursion but on
> heterogeneous recursion
The crux of the matter is not heterogeneity in general, but of the leaf value
in particular. This is what Brent is addressing. All my examples, save one, had
a uniform leaf value type (even the Tree<SKAction> example). The one exception
is my second JSON example. There I did not post the lift operator overload as
you can probably imagine it. Minimally:
enum JSONValue {
case Text(String)
case Integer(Int)
}
prefix func ◊ <Key> (leaf: String) -> DictionaryTree<Key, JSONValue> {
return .Leaf(.Text(leaf))
}
prefix func ◊ <Key> (leaf: Int) -> DictionaryTree<Key, JSONValue> {
return .Leaf(.Integer(leaf))
}
let johnny: DictionaryTree<String, JSONValue> =
[
"name": ◊"Johnny Appleseed",
"age": ◊25,
"address": [
"house_number": ◊21,
"street": ◊"2nd Street",
"city": ◊"New York"
]
]
Notice in particular how much contextual information you are getting from the
expected return type. Still though, as Brent, points out, this won’t work with
the two literal-convertable protocols. Nevertheless, I’d be very happy if they
could be added as a first step since I suspect that would be the easiest option
and one that would still allow for all my examples so far to work without the
lift operator; all except this `JSONValue` example.
milos_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
