There is no data type problem I'm trying to solve, also I could life with anonymous tuples.
Remember the old VFL (Visual Format Language) for AutoLayout? Right now I'm building a small library which will do the same thing with some extra options. Enforced argument labeling will result in some good syntax sugar for my library. For example a VFL string "H:|-10-[view]" might look lile this '|-(margin: 10)-(view)' with some custom operator magic, labeled tuples and actual view instances compared to the old string parsing version. Lets say I want to build a more complex VFL layout: |-(margin: 10, option: .CenterBoth, priority: 400)-(view)-(otherView)-| Developer A might just ignore the labeling and write: |-(10, .CenterBoth, 400)-(view)-(otherView)-| A half year later developer B will read this code and wonder whats the meaning of these values of the tuple. In your example you're totally right that using internal anonymous tuples might be easier but as you said yourself one could reconstruct the tuple with the corresponding labels. -- Adrian Zubarev Am 20. April 2016 um 17:40:57, William Dillon (will...@housedillon.com(mailto:will...@housedillon.com)) schrieb: > > At the moment, I'm against this (though it's possible to convince me with > sufficiently reasoned arguments). > > The reason being is that if I want the protection from the compiler, I think > I would construct a struct for the purpose. I don't believe that making a > struct would create enough overhead that a tuple would be preferable in this > case. > > An example of a scenario where this change would be inconvenient would be the > case where you're building an application composed of libraries using > different conventions. Consider that you're doing signals processing with > complex numbers: > > The filtering is coming from library A, that uses (r: Double, i: Double): > func firFilter(input: [(r: Double, i: Double)], taps [(r: Double, i: > Double)]) -> [(r: Double, i: Double)] { } > > The source driver uses anonymous tuples (Double, Double): > func getSamples() -> [(Double, Double)] { } > > And the plotting library (B) uses real and imaginary spelled out (real: > Double, imaginary: Double): > func plotSamples([real: Double, imaginary: Double)]) { } > > This is a somewhat contrived example, and I know that it would be possible to > re-construct the tuples so that they match, but that would be ugly at best > and inefficient at worst. > > What is the problem you're trying to solve that can't be fixed using policy > (thou shalt label tuple arguments) at your organization, or structs? > > Cheers, > - Will > > > > On Apr 20, 2016, at 6:23 AM, Adrian Zubarev via swift-evolution > > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > I would like to discuss about the following topic. > > > > Wouldn't it be better to enforce argument labels on tuples types, if the > > tuple type defines them? > > > > ```swift > > > > func foo(tuple: (a: Int, b: Int)) { /* do something */ } > > > > let test1 = (10, 100) > > let test2: (a: Int, c: Int) = test > > let test3: (Int, Int) = test2 > > > > foo(test1) > > foo(test3) > > > > /* > > cannot convert value of type '(a: Int, c: Int)' > > to expected argument type '(a: Int, b: Int)' > > */ > > foo(test2) > > > > ``` > > > > Function `foo` awaits a tuple of type `(a: Int, b: Int)` but `test1` and > > `test3` are both just of type `(Int, Int)`. > > As expected `test2` will raise an error because it has indeed a wrong type > > `(a: Int, c: Int)`. > > > > I'd suggest to enforce argument labeling on tuple types for better > > readability, because wasn't it the idea behind labels inside tuples? > > > > `foo(test1)` should raise an error `cannot convert value of type '(Int, > > Int)' to expected argument type '(a: Int, b: Int)'` as long as `test1` is > > not written like `let test1 = (a: 10, b: 100)` or `let test1: (a: Int, b: > > Int) = (a: 10, b: 100)` > > > > This will impact current codebase if you used labels but provided tuples > > without labels like the example above. The migrator could solve this by > > providing labels automatically to tuples where this error occurs. > > > > I'm not good at writing proposals for the GitHub repository at all, so if > > the community likes this idea, I'd be glad to see some help for this little > > proposal. > > -- > > Adrian Zubarev > > Sent with Airmail _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
