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

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,

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

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

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)

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

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

Re: [swift-evolution] TreeLiteralConvertible

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

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):

[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,

Re: [swift-evolution] What about a VBA style with Statement?

> On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution > wrote: > > The biggest advantage of the with pattern IMO is Cocoa initializers. It > provides a more unified > initialization scope. Instead of: > > let questionLabel = UILabel() >

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

> On 11 Apr 2016, at 20:47, Taras Zakharko > wrote: > > the question is what is faster: {self[0] < self[1]} or {$1.0 < $1.1} Yes, you are right that this is in fact not obvious! I’ve just measured and, though my implementation is faster,

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi Taras, > On 11 Apr 2016, at 19:38, Taras Zakharko > wrote: > > Your version might be faster for collection with expensive element access, > but it should be slower for arrays and the like, as it involves additional > intermediate

Re: [swift-evolution] divisible-by operator

> On 11 Apr 2016, at 02:39, Jacob Bandes-Storch wrote: > > I'm not suggesting this for the standard library (or anyone's production > code), but it's fun to note that there is actually a standard mathematical > notation for this, and it has a corresponding Unicode

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi Taras, > On 11 Apr 2016, at 08:48, Taras Zakharko via swift-evolution > wrote: > > The implementation should be fairly straightforward. E.g. here is an > extension method I use: > > extension CollectionType { > func order(@noescape isOrderedBefore:

Re: [swift-evolution] divisible-by operator

Thank you for giving this a thought! milos > On 7 Apr 2016, at 15:13, Erica Sadun <er...@ericasadun.com> wrote: > >> >> On Apr 6, 2016, at 10:13 AM, Milos Rankovic via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>&g

Re: [swift-evolution] Generic Alaises

shable, NodeValue, EdgeValue> > func shortestPath(graph: Graph, > startNode, endNode) -> > Path > > genericalias NavigationGraphElements = GraphElements<String, Int, City, > Motorway> > > typealias NavigationGraph = Graph > // navigationGraph.shortestPath() now re

Re: [swift-evolution] Feature proposal: Range operator with step

Hi Ted, > that would imply the ‘by”value should/must always be an absolute value? In a way: Instead of `Strideable.Stride` I would suggest `Strideable.Distance`. At any rate, leaving the sign to be direction indicator makes it forever necessary for everyone to make this counterintuitive metal

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > v1 > v2: is allowed and correctly evaluated. e.g. > (8.0…-3.14159).by(-0.0001) If the range does not assume `start >= end`, is it still necessary to also indicate the traversal

Re: [swift-evolution] Generic Alaises

Chris Lattner has a proposal under review on this topic. milos > On 6 Apr 2016, at 20:41, James Campbell via swift-evolution > wrote: > > This was inspired from the topic

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

> For example, this Standard Library function: > > public func + < > C : RangeReplaceableCollectionType, > S : SequenceType > where S.Generator.Element == C.Generator.Element > > (lhs: C, rhs: S) -> C > > would become: > > public func + (lhs: C, rhs: S) -> C

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

> On 6 Apr 2016, at 19:48, Sean Heber wrote: > > This almost seems like it could work so that it didn't even need the > bracketed parts to be able to figure out the types: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool where >T : SequenceType, >U :

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

With `where` at the end, the Standard Library function: public func != < A : Equatable, B : Equatable, C : Equatable, D : Equatable, E : Equatable, F : Equatable > (lhs: (A, B, C,

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution > wrote: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool > where T : SequenceType, > U : SequenceType, > T.Generator.Element: Equatable, > T.Generator.Element ==

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > > We prefer methods to free functions. However, `(from:to:by)` need not be a free function, it could be a sequence initialiser: Walk(from: 200, to: 0, by: 2) or: Steps(from: 200, to:

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 18:57, Xiaodi Wu via swift-evolution > wrote: > > Meanwhile, I was trying to talk about something like `stride(from: 200, to: > 0, by: -2)`, which is easily expressed today but isn't straightforward at all > to preserve with only ranges.

[swift-evolution] divisible-by operator

Checking for divisibility is very common: 21 % 3 == 0 // true In fact, this is such a common use of the `%` operator that the `== 0` side of the expression seems distracting in this use case. For quite a while now, I’ve been using a custom operator for this, which is steadily growing on

Re: [swift-evolution] Feature proposal: Range operator with step

> On 5 Apr 2016, at 20:54, Dave Abrahams via swift-evolution > wrote: > > IMO this: > > (-9...0).reverse() > > is better than > > stride(from: 0, to: -10, by: -1) > > What do you think? > > -- > Dave Are we absolutely certain that an operator could not be

Re: [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

This could potentially convert to Swift many library developers whose sanity depends on type guaranteed sequence sizes. I was just playing with Swift 2.2 along these lines, and got surprised how far I could get towards that ideal, see: http://codereview.stackexchange.com/q/124797/54297