Re: [swift-evolution] TreeLiteralConvertible

> Aren’t JSON arrays and objects actually the same thing? They’re both > essentially just ordered dictionaries, with objects mapping keys to > properties, functions etc., while arrays are just a dictionary where the keys > are consecutive integer (or should be, as long as you don’t mess with the

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 19:54, Haravikk wrote: > > While the original post is an interesting way to define this structure, I > think a specialised type is required to really capture this usefully. Sure. I never meant it as a replacement. It was a response to someone’s challenge whether one could

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 16:48, John McCall via swift-evolution > wrote: > The JSONValue type needs to be able to embed both JSON arrays and JSON > objects, Aren’t JSON arrays and objects actually the same thing? They’re both essentially just ordered dictionaries, with objects mapping keys to pr

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 08:24, Andrey Tarantsov wrote: >> On 14 Apr 2016, at 19:23, Andrey Tarantsov wrote: >> >> Can you please give us a few real-world examples… > > I can't think of any real use cases for the kind of literals you want, > though, hence the question. (And I don't think it's wor

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 15, 2016, at 1:29 AM, Milos Rankovic > wrote: >> On 15 Apr 2016, at 03:22, John McCall > > wrote: >> Your JSON literal example is already pretty well modeled by simply making a >> JSONValue type that conforms to all the literal protocols. It is completely >

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 03:22, John McCall wrote: > > The heterogeneity that I'm referring to is the mix of sub-trees and leaves at > a single level. … which is why I was making the point that that part of the heterogeneity problem is solved. > Your JSON literal example is already pretty well mod

Re: [swift-evolution] TreeLiteralConvertible

Hey! >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data structure in code would be useful? > > I suppose we always prefer to move *all* data into databases or files with > dedicated data formats, *including* arrays, strings, dictionaries, etc.

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 10:27 AM, Milos Rankovic via swift-evolution > 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 wh

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:56 PM, Milos Rankovic > wrote: > Hi John and Brent, > >> On 14 Apr 2016, at 22:22, John McCall > > wrote: >> >> multiple-conformance idea doesn't work > > > The idea is not multiple-conformance (or overloading), but multiple (two) > initial

Re: [swift-evolution] TreeLiteralConvertible

Hi John and Brent, > On 14 Apr 2016, at 22:22, John McCall 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 { associ

Re: [swift-evolution] TreeLiteralConvertible

>> extension Tree: LiftingConvertible { >> init(lifting value: Value) { >> self = .leaf(value) >> } >> } > > Another name for this feature is "user-defined implicit conversions". This is absolutely a form of user-defined implicit conversion

Re: [swift-evolution] TreeLiteralConvertible

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

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon > 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 LiteralConvertibl

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:03 PM, Milos Rankovic > wrote: >> On 14 Apr 2016, at 21:36, John McCall > > wrote: >> >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> ou

Re: [swift-evolution] TreeLiteralConvertible

I think a better solution than just adding a TreeLiteral (and the accompanying TreeLiteralConvertible protocol) would be to allow user-defined literal types using regex (or something similar). This would not only allow for tremendous flexibility, but it’d remove some compiler magic as well. The

Re: [swift-evolution] TreeLiteralConvertible

> 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 variabl

Re: [swift-evolution] TreeLiteralConvertible

> On 14 Apr 2016, at 21:36, John McCall 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. You mean this: public enum IntTree { case Leaf(Int) case Branche

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 1:34 PM, Milos Rankovic > wrote: > Hi John, > >> On 14 Apr 2016, at 21:09, John McCall > > wrote: >> >> I mean, you could just make your Tree type implement all the individual >> literal-convertible protocols. > > It does sound like something l

Re: [swift-evolution] TreeLiteralConvertible

Hi John, > On 14 Apr 2016, at 21:09, John McCall wrote: > > I mean, you could just make your Tree type implement all the individual > literal-convertible protocols. It does sound like something like that should be doable, but it isn’t. The literal-convertible protocols only require one initia

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 12:01 PM, Milos Rankovic via swift-evolution > wrote: > Hi Andrey and Laurent, > >> On 14 Apr 2016, at 19:23, Andrey Tarantsov > > wrote: >> >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data

Re: [swift-evolution] TreeLiteralConvertible

Hi Andrey and Laurent, > On 14 Apr 2016, at 19:23, Andrey Tarantsov wrote: > > Can you please give us a few real-world examples where initializing a > nontrivial tree-like data structure in code would be useful? > > It's an honest question — I have never felt the need in my life, and I always

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 8:23 PM, Andrey Tarantsov via swift-evolution > wrote: > > Hey, Milos! > > Can you please give us a few real-world examples where initializing a > nontrivial tree-like data structure in code would be useful? > > It's an honest question — I have never felt the need in m

Re: [swift-evolution] TreeLiteralConvertible

Hey, Milos! Can you please give us a few real-world examples where initializing a nontrivial tree-like data structure in code would be useful? It's an honest question — I have never felt the need in my life, and I always preferred to move the data into something like a bundled json or CSV, rath

Re: [swift-evolution] TreeLiteralConvertible

> On 14 Apr 2016, at 13:26, Milos Rankovic via swift-evolution > wrote: Please disregard this, the earlier of the two posts with the subject “TreeLiteralConvertible". I appears it escaped me while composing. With embarrassment and apologies, milos_

Re: [swift-evolution] TreeLiteralConvertible

Thanks for the comment, Vladimir. > On 14 Apr 2016, at 18:14, Vladimir.S wrote: > > Well, actually we can compile : > > var zz : [Any] = [[Int](), 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] > Sure. I just wasn’t sure it was worth mentioning (it was a long post anyway): annotating the variable wit

Re: [swift-evolution] TreeLiteralConvertible

Well, actually we can compile : var zz : [Any] = [[Int](), 1, [2, 3], [[4, 5], [6, 7], [8, 9]]] [] - is empty array of unknown type, I think this is why you can't compile. We need good language tools to process such kind of array, I agree with you. As for your proposal.. I have no idea if thi

[swift-evolution] TreeLiteralConvertible

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,

[swift-evolution] TreeLiteralConvertible

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,