<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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&lt;minValue, maxValue&gt; in Swift 3. Take a look at this section here:&nbsp;<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&lt;Range&gt;), 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&lt;_ range: Range&lt;Int&gt;&gt; { … }</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">--&nbsp;<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> &gt; I generally think it’s a cool idea and that it can be useful in minimizing<br> &gt; 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&lt;0.0...1.0&gt; = 1.0<br><br>     var prop1 : Int&lt;-10...10&gt; = 1<br><br>     var prop2 : Int&lt;0...100&gt; = 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..&lt;100.0 = 0.0<br>}<br><br><br>On 18.05.2016 11:30, David Rönnqvist via swift-evolution wrote:<br>&gt; It reminds me of "Refinement Types" (see for example [this blog post][1] or<br>&gt; [this paper][2]).<br>&gt;<br>&gt; I generally think it’s a cool idea and that it can be useful in minimizing<br>&gt; partial functions by requiring that these cases are explicitly handled.<br>&gt; For example, highlighting that the following `average` implementation<br>&gt; divides by zero when the list is empty:<br>&gt;<br>&gt;     func average(numbers: [Int]) -&gt; Int {<br>&gt;         return sum(numbers) / numbers.count<br>&gt;     }<br>&gt;<br>&gt;<br>&gt; and requiring that the empty list case is handled separately:<br>&gt;<br>&gt;     func average(numbers: [Int]) -&gt; Int {<br>&gt;         guard !numbers.isEmpty else { return 0 }<br>&gt;         return sum(numbers) / numbers.count<br>&gt;     }<br>&gt;<br>&gt;<br>&gt; Regards,<br>&gt; David<br>&gt;<br>&gt; [1]: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/<br>&gt; &lt;http://goto.ucsd.edu/%7Erjhala/liquid/haskell/blog/blog/2013/01/01/refinement-types-101.lhs/&gt;<br>&gt; [2]: http://goto.ucsd.edu/~nvazou/refinement_types_for_haskell.pdf<br>&gt; &lt;http://goto.ucsd.edu/%7Envazou/refinement_types_for_haskell.pdf&gt;<br>&gt;<br>&gt;<br>&gt;&gt; On 11 May 2016, at 20:00, Adrian Zubarev via swift-evolution<br>&gt;&gt; &lt;swift-evolution@swift.org &lt;mailto:swift-evolution@swift.org&gt;&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; Okay I’m fine with that for now. If you’d have to decide on some syntax<br>&gt;&gt; for such a future, how would it look like? I’m just curious.<br>&gt;&gt;<br>&gt;&gt; I tend to square brackets Double[0.0 … 1.0], because otherwise it might<br>&gt;&gt; look like a generic type, but I’m not sure if this type refinement could<br>&gt;&gt; be applied to other types as well so we actually would stick to the<br>&gt;&gt; generic type syntax here Float&lt;-1.0 … 1.0&gt;.<br>&gt;&gt;<br>&gt;&gt; --<br>&gt;&gt; Adrian Zubarev<br>&gt;&gt; Sent with Airmail<br>&gt;&gt;<br>&gt;&gt; Am 11. Mai 2016 bei 19:54:09, Matthew Johnson (matthew@anandabits.com<br>&gt;&gt; &lt;mailto:matthew@anandabits.com&gt;) schrieb:<br>&gt;&gt;<br>&gt;&gt;&gt; This is called a refinement type.  It would be cool to explore that<br>&gt;&gt;&gt; direction in the future but it is definitely well out of scope for Swift 3.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Sent from my iPad<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On May 11, 2016, at 12:45 PM, Adrian Zubarev via swift-evolution<br>&gt;&gt;&gt; &lt;swift-evolution@swift.org &lt;mailto:swift-evolution@swift.org&gt;&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Hello Swift community. I'd like to discuss with you if we need<br>&gt;&gt;&gt;&gt; something like this in Swift 3 or any future Swift version.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As you may know there is no way to constrain a numeric type expect for<br>&gt;&gt;&gt;&gt; some scope internal assertion or precodintions which may produce a<br>&gt;&gt;&gt;&gt; runtime error if the input value is out of the defined bound.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; func foo(value: Int) {<br>&gt;&gt;&gt;&gt; assert(value &gt; 0 &amp;&amp; value &lt;= 10)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; // passed<br>&gt;&gt;&gt;&gt; }<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; How would it be if Swift would allow us to constraint numeric typs with<br>&gt;&gt;&gt;&gt; ranges/intervals?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; func newFoo(value: Int&lt;1...10&gt;) {<br>&gt;&gt;&gt;&gt; // no need for an assertion any more<br>&gt;&gt;&gt;&gt; }<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; We could go even further and add more then one range/interval:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; func someFoo(value: Int&lt;0...20, 40...60&gt;) { /* do some work */ }<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Not only integers should have this ability but also floating point<br>&gt;&gt;&gt;&gt; types like Double and Float.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Alternative form might look like this:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Double[1.0...10.0]<br>&gt;&gt;&gt;&gt; Float[0.0...1.0, 10.0...100.0]<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; One downside of half opened ranges/intervals is the left side of its<br>&gt;&gt;&gt;&gt; set. How do we exclude the left element?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; 1...10 means 1..&lt;11 equals [1, 11)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; But how can we create something like (0.0, 1.0), do we need a strange<br>&gt;&gt;&gt;&gt; looking binary operator 0.0&gt;..&lt;1.0?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; What do you think? I'd love to hear any feedback to this.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; --<br>&gt;&gt;&gt;&gt; Adrian Zubarev<br>&gt;&gt;&gt;&gt; Sent with Airmail<br>&gt;&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt;&gt; swift-evolution mailing list<br>&gt;&gt;&gt;&gt; swift-evolution@swift.org &lt;mailto:swift-evolution@swift.org&gt;<br>&gt;&gt;&gt;&gt; https://lists.swift.org/mailman/listinfo/swift-evolution<br>&gt;&gt; _______________________________________________<br>&gt;&gt; swift-evolution mailing list<br>&gt;&gt; swift-evolution@swift.org &lt;mailto:swift-evolution@swift.org&gt;<br>&gt;&gt; https://lists.swift.org/mailman/listinfo/swift-evolution<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; swift-evolution mailing list<br>&gt; swift-evolution@swift.org<br>&gt; https://lists.swift.org/mailman/listinfo/swift-evolution<br>&gt;<br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>