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