I've just updated an old project to Swift 3.0 and had to swap to the "feature" branch to get the benefits of #214 to allow my project to build. To expand upon that fix though, I'd love to see a minor enhancement.
When it comes to Swift, uses of NSUInteger instead of just NSInteger for delegate calls such as:
- (NSUInteger)numberOfPointsInLineGraph:(BEMSimpleLineGraphView *)graph;
and
- (CGFloat)lineGraph:(BEMSimpleLineGraphView *)graph valueForPointAtIndex:(NSUInteger)index;
can cause issues in regards to casting.
These translate to UInt (as you'd expect), but because Swift is such a strict language, using them in a simple way, requires casting between UInt and Int (and vice versa).
For example:
func numberOfPoints(inLineGraph graph: BEMSimpleLineGraphView) -> UInt {
return myArray.count
}
The above will show a build error unless you specifically cast myArray.count in Int(myArray.count).
func numberOfPoints(inLineGraph graph: BEMSimpleLineGraphView) -> UInt {
return Int(myArray.count)
}
Likewise:
func lineGraph(_ graph: BEMSimpleLineGraphView, valueForPointAt index: UInt) -> CGFloat {
let myItem = myArray[index]
// Code using the item
}
This also fails unless you add an extra line of let index = Int(index) to make sure you're passing a Int to the array subscript.
func lineGraph(_ graph: BEMSimpleLineGraphView, valueForPointAt index: UInt) -> CGFloat {
let index = Int(index)
let myItem = myArray[index]
// Code using the item
}
I understand why NSUInteger has been used, as an array is unlikely to have an index < 0, but this sadly does cause extra code issues for Swift users (minimal, I agree, but still). Also, this is going away from the standards that delegate calls in UITableViewDataSource and UICollectionViewDataSource use, where just NSInteger is used.
I'd love to hear what you think, and allow this to be considered, as it would help a lot with some unnecessary code for Swift users, with minimal impact for Objective-C users.