Deprecated functions

[Mr. X]

Since this commit, SFML started to make use of the SFML_DEPRECATED feature:
https://github.com/SFML/SFML/commit/957cabb816f69a3d7a3909d24b9e773ffc9a65b5

In my opinion, this is a bad idea for two reasons:
- Since the new methods are not available, using the new function setFillColor means breaking compatibility with older SFML versions - even if the new feature outlined text is not used. In general, I think it is a bad idea to mark an old function as deprecated immediately after an alternative was introduced.
- The implementation of SFML_DEPRECATED causes MSVC to issue warnings that turn into compilation errors if /sdl is enabled. This is not what I would call API compatibility, so, the policy until now, that minor releases are backward compatible would be dropped.

Hence, I would recommend to wait a few releases until using SFML_DEPRECATED for sf::Text::setColor().

[eXpl0it3r]

We introduce a new function which deprecates the old one, thus it gets marked as deprecated. I don't see a reason to wait x amount of time till one should be allowed to mark something as deprecated and it also is not breaking the API.

The deprecation warnings can be disabled by simply defining SFML_NO_DEPRECATED_WARNINGS in your project settings. The warnings however are useful for us SFML developers and for the developers using SFML, because we get to tell people that there are better alternatives for these functions and you can adapt the code for the better alternatives and future proof your code base.

[Mr. X]

Ok, SFML_NO_DEPRECATED_WARNINGS provides a way to get rid of the warnings. Good to know.

However, I still think that at the moment the code gets worse if setFillColor is used. It stops to work with SFML 2.0, 2.1, 2.2 and 2.3 for no reason (as long as no feature introduced in next SFML version is used).

it also is not breaking the API

It is breaking the API for projects that use /sdl or something like -Werror.

[Serapth]

As an industry practice, marking a method or variable as depricated is basically just saying "this is no longer the prefered way of doing this and could go away at any point!"


Your issues with the warning are easily countered, either via the library as Exploiter( sorry... too lazy to do it right..   ) said, or can be handled on your end with ease.  Having LESS information available to the developer is almost always the wrong choice.  Now, if fields are marked as depricated that aren't, that's a different issue.


Now, to actually be useful, since you are using Visual Studio, you should be aware of the ability to disable warnings via the #pragma warning command ( https://msdn.microsoft.com/en-us/library/441722ys.aspx ).  This should work on other compilers as well, but #pragma cross platform implementation is spotty at best, so I'm not saying that with confidence.  You can also suppress warnings via the project settings.

[Nexus]

- Since the new methods are not available, using the new function setFillColor means breaking compatibility with older SFML versions

The same is true for feature additions. Backwards compatibility means that older code still compiles under a newer library version, not vice versa.

The implementation of SFML_DEPRECATED causes MSVC to issue warnings that turn into compilation errors if /sdl is enabled.

I know, and I already mentioned that when we discussed the pull request. There were no objections during a month. Furthermore, we already had a detailed discussion about deprecation that started 3/4 years ago, and the conclusion was that it is a good thing. You also see this concept in all kinds of libraries or programming languages.

However, I still think that at the moment the code gets worse if setFillColor is used. It stops to work with SFML 2.0, 2.1, 2.2 and 2.3 for no reason

And the same is true if we introduce it at a later stage. Only that people have less time to adapt their code until we remove the function, and then code actually becomes backwards-incompatible.

What if we didn't mark it as deprecated? There would be two functions in the API with identical semantics, and people would never know which one to use, or if there is a difference at all. And older SFML versions would still break if setFillColor() is used. Marking setColor() deprecated on the other hand makes users aware that it is going to be removed, and gives them time to migrate their code. Whether they care or not is their decision, we intentionally left the option to disable warnings.