Remove sf::View::reset in favor of assignment operations

[ChrisThrasher]

Description

It's rare that a type truly needs a .reset function. Copy/move assignment typically accomplishes the same thing with less code and is easier to maintain since it doesn't require updating your .reset() function as new data members are added.

To reset a type is conceptually the same thing as simply assigning from a newly constructed instance of the same type.

[coveralls]

Pull Request Test Coverage Report for Build 9145160170

Details

• 3 of 3 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.01%) to 55.704%

---

Totals
Change from base Build 9129910660:	-0.01%
Covered Lines:	11486
Relevant Lines:	19539

---

💛 - Coveralls

[kimci86]

Worth noting that reset method was not doing the same as assigning a new constructed view because it was not changing viewport and scissor.

[ChrisThrasher]

Worth noting that reset method was not doing the same as assigning a new constructed view because it was not changing viewport and scissor.

Good point. I wonder if that is an oversight or intentional. What could be the use case for resetting part of a view but not all of it?

[ChrisThrasher]

Rebased on master. No changes made.

[ChrisThrasher]

Worth noting that reset method was not doing the same as assigning a new constructed view because it was not changing viewport and scissor.

I did some digging in the commit history.

m_viewport was added in 7cc00085 which came after the addition of the reset function. It's feasible it was an oversight that reset was not amended to include this new data member.

A similar story is feasible for m_scissor which was added much more recently in #1451. It's so easy to forget to update this kind of reset function when adding more data members.

I think .reset() was never intended to skip those two data members.