small sf::rect suggestion

[Shadowblitz16]

can the sfml devs add support "bottom" "right" and "touching()"

bottom and right would return the x2 and y2.
touching() would return true if two objects are right beside each other. but not if they are intersecting.

[Rosme]

bottom and right can already be easily calculated using top+height and left+width.

As for touching, I am not sure what would be the use case. Do you have a use case to present for this because this sound oddly specific to your situtation?

[ZeroZ30o]

bottom and right can already be easily calculated using top+height and left+width.

Yeah but if you store bottom and right you can also easily calculate height and width. It's a matter of what you prefer. I personally also find bottom and right more useful, I use them more often than height and width, thus doing more calculations.

As for touching, I am not sure what would be the use case. Do you have a use case to present for this because this sound oddly specific to your situtation?

Touching doesn't make much sense if it returns false even when they do intersect.
However, it is useful to know if 2 objects are right next to eachother, in some cases like checking if a point is on the edges of the rectangle and other similar operations.

[sjaustirni]

bottom and right can already be easily calculated using top+height and left+width.

Yeah but if you store bottom and right you can also easily calculate height and width. It's a matter of what you prefer. I personally also find bottom and right more useful, I use them more often than height and width, thus doing more calculations.

No, it is not a matter of preference. The way SFML does it is objectively superior.
If you're given x, y, width and height, it is guaranteed you're always given an axis-aligned rectangle. Had you had been given four (random) points instead, the rectangle is not guaranteed  to be axis-aligned. Hell, it is not guaranteed to be a rectangle at all* (it could be any quadrilateral, even a concave one).

* not without cumbersome dedicated checking and error reporting

Touching doesn't make much sense if it returns false even when they do intersect.
However, it is useful to know if 2 objects are right next to eachother, in some cases like checking if a point is on the edges of the rectangle and other similar operations.

SFML is not a collision detection library and you should not treat it so. Besides, thanks to how float-point arithmetic works, you're never going to get a perfect "touch". That's why even in dedicated collision detection/resolution libraries intersections are treated as "touches" (especially if the relative velocity of the colliding objects is small).

[Laurent]

Had you had been given four (random) points instead

It's not 4 random points (the corners), it's 4 values (the edges), so it's indeed completely equivalent, and only a matter of taste.

[sjaustirni]

I thought we were talking about sf::Rect. left and top are defined as coordinates there (corners, not edges).
But I suppose I have misunderstood something here?

[eXpl0it3r]

Yes, you must have misunderstood it.

The rect would be defined through the the two points (left, top) and (right, bottom).

Both can be calculated from each other and thus it's just a question of preference:
1) (right, bottom) = (left, top) + (width, height)
2) (width, height) = (right, bottom) - (left, top)

This is not the first time this has been brought up, so make sure to use the search engine.

[Laurent]

I thought we were talking about sf::Rect. left and top are defined as coordinates there (corners, not edges).

No, they are not. All members of sf::Rect<T> (left, top, width and height) are single values of type T, with T being a scalar type (int and float are used internally in SFML).

[sjaustirni]

Yes, you must have misunderstood it.

The rect would be defined through the the two points (left, top) and (right, bottom).

Both can be calculated from each other and thus it's just a question of preference:
1) (right, bottom) = (left, top) + (width, height)
2) (width, height) = (right, bottom) - (left, top)

Yes, I see I have misunderstood it now. Indeed, they're equivalent approaches of a representation of a rectangle. I made an implicit assumption that the sf::Rect constructor was somehow involved. I am sorry for the annoyance I caused. 

No, they are not. All members of sf::Rect<T> (left, top, width and height) are single values of type T, with T being a scalar type (int and float are used internally in SFML).

Yeah, what I meant was that left and top made together de facto a left a top coordinate, but that's moot now. Stupid me