<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>By the way, there is a pretty clever library that allows you to approximate this in Swift today. It's more verbose than first class language support would be, but not bad given the lack of language support.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><a href="https://github.com/Ben-G/Validated">https://github.com/Ben-G/Validated</a></div><div id="AppleMailSignature"><br><br>Sent from my iPad</div><div><br>On May 18, 2016, at 7:49 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">As you guys brought my idea back to life and I’ve done some effort of digging into the Swifts generic future I can show you some fresh ideas.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">`Refinement Types` could be really handy, but put them aside for a moment.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Actually we could achieve something like Int<minValue, maxValue> in Swift 3. Take a look at this section here: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-value-parameters">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-value-parameters</a></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">There is a slightly problem with this, we cannot rewrite all types to be generic with default parameters. That said it would be nice if we could overload types somehow (Int vs. Int<Range>), but I’m not sure if this idea would suit the language like this.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Anyways we could then have:</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">struct Int<_ range: Range<Int>> { … }</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Sadly this makes the type not safe at compile time but only signals the user that at runtime you can’t use any number our of its range.</div> <br> <div id="bloop_sign_1463574830069963008" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 18. Mai 2016 bei 14:13:09, Vladimir.S via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div> > I generally think it’s a cool idea and that it can be useful in minimizing<br> > partial functions by requiring that these cases are explicitly handled.<br><br>Support this opinion.<br><br>Other example where such feature could be useful: some public property in <br>type that can accept values from some interval. For example we have class <br>with transparency property that can be 0.0 ... 0.1:<br><br>class MyShape {<br> public var transparency: Double = 1.0 // 0.0 ... 0.1<br>}<br><br>yes, we can use willSet/didSet to check this every time. But if we have a <br>number of such properties, we have a lot of repetitive and boilerplate code:<br><br>class C {<br> var transparancy : Double = 1.0 {<br> didSet { check(transparancy, 0.0...1.0) }<br> }<br><br> var prop1 : Int = 1 {<br> didSet { check(prop1, from: -10...10) }<br> }<br><br> var prop2 : Int = 1 {<br> didSet { check(prop2, from: 0...100) }<br> }<br>}<br><br>, and all will be worse if we also need didSet observers to do some <br>'useful' work here.<br>Proposed solution will looks like:<br><br>class C {<br> var transparancy : Double<0.0...1.0> = 1.0<br><br> var prop1 : Int<-10...10> = 1<br><br> var prop2 : Int<0...100> = 1<br>}<br><br>Probably the alternative could be some kind of `where` or `bounded` clause <br>for numeric types and arguments:<br><br>class C {<br> var transparancy : Double = 1.0 where 0.0...1.0<br> //var transparancy : Double bounded 0.0...1.0 = 1.0<br><br> var prop1 : Int = 1 where -10...10<br><br> var prop2 : Int = 1 where 0.0...1.0<br><br> //var prop3 : Float bounded 0.0..<100.0 = 0.0<br>}<br><br><br>On 18.05.2016 11:30, David Rönnqvist via swift-evolution wrote:<br>> It reminds me of "Refinement Types" (see for example [this blog post][1] or<br>> [this paper][2]).<br>><br>> I generally think it’s a cool idea and that it can be useful in minimizing<br>> partial functions by requiring that these cases are explicitly handled.<br>> For example, highlighting that the following `average` implementation<br>> divides by zero when the list is empty:<br>><br>> func average(numbers: [Int]) -> Int {<br>> return sum(numbers) / numbers.count<br>> }<br>><br>><br>> and requiring that the empty list case is handled separately:<br>><br>> func average(numbers: [Int]) -> Int {<br>> guard !numbers.isEmpty else { return 0 }<br>> return sum(numbers) / numbers.count<br>> }<br>><br>><br>> Regards,<br>> David<br>><br>> [1]: <a href="http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/">http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/</a><br>> <<a href="http://goto.ucsd.edu/%7Erjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/">http://goto.ucsd.edu/%7Erjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/</a>><br>> [2]: <a href="http://goto.ucsd.edu/~nvazou/refinement_types_for_haskell.pdf">http://goto.ucsd.edu/~nvazou/refinement_types_for_haskell.pdf</a><br>> <<a href="http://goto.ucsd.edu/%7Envazou/refinement_types_for_haskell.pdf">http://goto.ucsd.edu/%7Envazou/refinement_types_for_haskell.pdf</a>><br>><br>><br>>> On 11 May 2016, at 20:00, Adrian Zubarev via swift-evolution<br>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>>> wrote:<br>>><br>>> Okay I’m fine with that for now. If you’d have to decide on some syntax<br>>> for such a future, how would it look like? I’m just curious.<br>>><br>>> I tend to square brackets Double[0.0 … 1.0], because otherwise it might<br>>> look like a generic type, but I’m not sure if this type refinement could<br>>> be applied to other types as well so we actually would stick to the<br>>> generic type syntax here Float<-1.0 … 1.0>.<br>>><br>>> --<br>>> Adrian Zubarev<br>>> Sent with Airmail<br>>><br>>> Am 11. Mai 2016 bei 19:54:09, Matthew Johnson (<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a><br>>> <<a href="mailto:matthew@anandabits.com">mailto:matthew@anandabits.com</a>>) schrieb:<br>>><br>>>> This is called a refinement type. It would be cool to explore that<br>>>> direction in the future but it is definitely well out of scope for Swift 3.<br>>>><br>>>> Sent from my iPad<br>>>><br>>>> On May 11, 2016, at 12:45 PM, Adrian Zubarev via swift-evolution<br>>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>>> wrote:<br>>>><br>>>>> Hello Swift community. I'd like to discuss with you if we need<br>>>>> something like this in Swift 3 or any future Swift version.<br>>>>><br>>>>> As you may know there is no way to constrain a numeric type expect for<br>>>>> some scope internal assertion or precodintions which may produce a<br>>>>> runtime error if the input value is out of the defined bound.<br>>>>><br>>>>> func foo(value: Int) {<br>>>>> assert(value > 0 && value <= 10)<br>>>>><br>>>>> // passed<br>>>>> }<br>>>>><br>>>>> How would it be if Swift would allow us to constraint numeric typs with<br>>>>> ranges/intervals?<br>>>>><br>>>>> func newFoo(value: Int<1...10>) {<br>>>>> // no need for an assertion any more<br>>>>> }<br>>>>><br>>>>> We could go even further and add more then one range/interval:<br>>>>><br>>>>> func someFoo(value: Int<0...20, 40...60>) { /* do some work */ }<br>>>>><br>>>>> Not only integers should have this ability but also floating point<br>>>>> types like Double and Float.<br>>>>><br>>>>> Alternative form might look like this:<br>>>>><br>>>>> Double[1.0...10.0]<br>>>>> Float[0.0...1.0, 10.0...100.0]<br>>>>><br>>>>> One downside of half opened ranges/intervals is the left side of its<br>>>>> set. How do we exclude the left element?<br>>>>><br>>>>> 1...10 means 1..<11 equals [1, 11)<br>>>>><br>>>>> But how can we create something like (0.0, 1.0), do we need a strange<br>>>>> looking binary operator 0.0>..<1.0?<br>>>>><br>>>>> What do you think? I'd love to hear any feedback to this.<br>>>>><br>>>>> --<br>>>>> Adrian Zubarev<br>>>>> Sent with Airmail<br>>>>> _______________________________________________<br>>>>> swift-evolution mailing list<br>>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>><br>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>>> _______________________________________________<br>>> swift-evolution mailing list<br>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org">mailto:swift-evolution@swift.org</a>><br>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></span></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>