Similar functionality is already implemented with using slideEnded event: https://github.com/rzajac/angularjs-slider#slider-events

I disagree because it fires only on moveEnd. If I want to update something everytime the value change, I couldn't. Now with this function, it is possible.

Maybe we can replace my implementation by firing a slideMoved event.

How does it differ from watching the model with scope.$watch() ?

The result is the same but it is better to avoid $watches. This is why there is a ng-change on default inputs. My goal is to provide a ng-change like feature.

+ 1 Better than $watch

I think ng-change could be pretty useful.
Imagine a situation:
I have 5 sliders, each value is displayed to the user, for example in blue circle. When user touch/move Slider, his circle turns into green color - to show user that he set value. Or another use case - for some of Sliders additional work has to be done, like in (real-world app use case) Glycemia, where values can be in two units: mmol/L or mg/dL, where is natural to show 2 separate Sliders for each unit - if we don't know which values user will choose we have to do recalculations between .mmol/L and mg/dL.
So maybe @ValentinH changes, if it works correctly, are worth merging?

By the way, I see "This branch is up-to-date with the base branch", was ng-change added to master branch? I can't see it now, maybe I misunderstood this message.

Nope it is not yet merged. For now, there are 2 people that want it merged (3 with me) and one person @rzajac that doesn't really want to merge it. Let's see if there are more people that request it...

How does it differ from watching the model with scope.$watch() ?

Well, it think this approach is much more viable when I have a variable list of objects which have a range. With this pull I am able to use simple markup to achieve my goals, while with the watch I would have to manage the contents of my list and add/remove watchers accordingly.

Implementing this is extremely simple and much more efficient than using watchers, I don't know what the argument against it could possibly be.

So @ValentinH , 4 to 1 :)

OK let's merge it ;)