> On Apr 14, 2016, at 10:27 AM, Milos Rankovic via swift-evolution
> <swift-evolution@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..
-DW
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
