[swift-evolution] TreeLiteralConvertible

David Waite david at alkaline-solutions.com
Fri Apr 15 01:02:05 CDT 2016

> On Apr 14, 2016, at 10:27 AM, Milos Rankovic via swift-evolution <swift-evolution at swift.org> wrote:
> In Swift, we cannot compile:
> _ = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]
> The reason for the compile-time error is that we are not in fact creating an array, but a tree – a more general structure of which arrays are only a special case. Given the well-deserved and growing reputation of Swift, one would hope that in this instance the compiler would be able to default to something like a:

Actually this error can be simplified to 

_ = []

As the compiler says, the expression is ambiguous. Without an element type, the array literal cannot be used to create an array.

On the other hand:

_ = [[1]]

is fine -  the system assumes the literal your literal was defining an array of int, so the outer type is Array<Array<Int>>

> For this to work in the playground, however, we must manually lift the values into the world of trees first. And to make that chore in turn easier on the eye we can introduce a:
> prefix operator ◊ {} // looks a bit like a leaf (us/uk kbd: ⎇⇧V)
> prefix func ◊ <T> (leaf: T) -> Tree<T> { return .Leaf(leaf) }
> let tree: Tree<Int> = [[], ◊1, [◊2, ◊3], [[◊4, ◊5], [◊6, ◊7], [◊8, ◊9]]]

Yes, because there is no way to have one type be cast implicitly into another type except for the cases the compiler supports via Optional or the various LiteralConvertible protocols/initializers.

So as other point out, if you actually defined a Integer-only tree, you could define that a .leaf was created from integer literals. Then this works without your wrapping operator.

> The point here is that if adding such a fundamental type to the Standard Library would not be a priority at present, it is not the end of the world since we can easily enough write it ourselves… What we cannot do ourselves, however, is to get rid of the need for that operator in the common scenario of initialising with literal values. For this we need a literal-convertible protocol requiring two initialisers:
> protocol TreeLiteralConvertible {
> 	associatedtype LeafValue
> 	init(literal: Self.LeafValue...)
> 	init(literal: Self...)
> }
> Then we could simply:
> let tree: Tree<Int> = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]

If my tree is of Pear objects, there is no “Pear” literal in the language. So I don’t think you are asking for tree literals. I suspect you are asking for implicit type coercion, which if present could possibly replace some of the existing LiteralConvertible protocols..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160415/e066a621/attachment.html>

More information about the swift-evolution mailing list