Problems with deprecated methods in Swift

[mbeaty]

There are multiple versions of the lineGraph:labelOnXAxisForIndex: method. One is not Swift-compatible and deprecated and in the delegate protocol. The other is Swift-compatible and in the data source protocol. If your class conforms to both the delegate and the data source protocol, there is no way to properly use the Swift-compliant version of this method, because of the conflict between the two methods that get bridged. I can only use this method in Swift if I implement it as

func lineGraph(graph: BEMSimpleLineGraphView, labelOnXAxisForIndex index: Int) -> String! {...}

This is not correct and results in an Xcode warning. It should be

func lineGraph(graph: BEMSimpleLineGraphView, labelOnXAxisForIndex index: Int) -> String? {...}

but due to the conflict introduced by conforming to both protocols, it's impossible to implement it that way.

[dbmrq]

Is there any way to work around this?
I tried creating a separate delegate class and xcode stopped complaining and I could implement the labelOnXAxisForIndex method, but my x axis labels still don't show.
I'm not sure if the problem is related to this or if I'm doing something wrong. Should this work with a separate delegate?

[slangley]

@danielbmarques A workaround that worked for me was to define the labelOnXAxisForIndex delegate call with a String! return value e.g.

func lineGraph(graph: BEMSimpleLineGraphView, labelOnXAxisForIndex index: Int) -> String! 

While not entirely correct, it does allow the X axis labels to be displayed, at the cost of a couple of warnings in the project.

I think this is actually an Apple/Swift bug, since the non-optional return version is attributed with __unavailable which should not allow it to be visible to the Swift compiler.

[AvdLee]

I'm encountering this as well in my Swift project.

[slangley]

@Boris-Em are you open to a pull request that will remove the deprecated delegate calls?

[Boris-Em]

@slangley,
Absolutely. Just make sure that you take a quick look at the contributing document.

[Sam-Spencer]

Don't want to be Johnny Raincloud ☁️ here, but just keep in mind that removing methods from the public API is a breaking change and thus requires (according to semantic versioning) upping the first digit in the release number. This isn't really a huge issue, but it would be nice to bundle a few more breaking changes into the same major release (this will save some headache for those using Cocoapods, or who may have deep integration of this project, etc).

So to compromise, if you do a pull request, can you send it to the feature branch rather than master? That will allow us to make a few more changes in the same release before making it final.

[Sam-Spencer]

@mbeaty @danielbmarques @slangley @AvdLee This issue should be fixed in the latest commit to the feature branch (83e8acd). Hope this helps!