Overhaul Rect2 & Rect2i Documentation

[Mickeon]

Continuation of bla-bla-bla... #68838, #68983, #69594, #69451... You get the gist.

• Made the wording match how other classes are documented a lot more closely;
• Made use of [param] and several other strong references more often;
• Changed words where it felt necessary, where they could be mistaken for another concept of Godot's API, where technical terms are more appropriate. For example:
  • "borders" -> "edges".
• Added more examples.
• Added "boolean context" note.
• Changed most self-referential mentions of "Rect2" to "rectangle".
  • The reasoning for this is still debatable in my head, but I feel like it makes Rect2 as a concept much easier to explain and imagine when described as an actual rectangle (because it really just is).

---

Feedback is very, very welcome.

[Mickeon]

Rebased.

[Mickeon]

Pushed a commit that should hopefully address all of the aforementioned issues.
Edit: missed a Rect2 instead of Rect2i.

[Mickeon]

Updated with the aforementioned suggestions (also mirrored in the Rect2 documentation)

[kleonc]

Suggested change

	Returns [code]true[/code] if the [member position] and [member size] of the rectangles are not equal.
	Returns [code]true[/code] if either [member position] or [member size] of the rectangles are not equal, respectively.

[Mickeon]

Now for this one I'm not sure if the... "the" is needed after "either" or not. I also don't know what the "respectively" is referring to.

[kleonc]

Respectively was meant to mean that positions are compared against each other and sizes are compared against each other (position is not being compared against size). But I think I've added it firstly, after the change to "either+or" maybe it's no longer needed indeed. 🤔
Actually making them plural should do the thing I think:

Suggested change

	Returns [code]true[/code] if the [member position] and [member size] of the rectangles are not equal.
	Returns [code]true[/code] if either [member position]s or [member size]s of the rectangles are not equal.

[Mickeon]

I would avoid appending letters to property names. I like the former more, perhaps, but I could be trying something else...

[kleonc]

Suggested change

	Returns [code]true[/code] if the [member position] and [member size] of the rectangles are exactly equal.
	Returns [code]true[/code] if both [member position] and [member size] of the rectangles are exactly equal, respectively.

(I don't think "exactly" is needed but oh well)

[Mickeon]

I wanted to specify here because there's 4 very precise floating-point numbers that have to be equal to return true. I suppose the adjective is not really necessary for Rect2i, however.

[kleonc]

Yeah, I get the reasoning. I mean "equal" and "exactly equal" are the same thing. 🙃 But if it's clearer then sure.
(and I skipped / haven't looked at the Rect2i part)

[Mickeon]

Pushed a commit that accepts most of the suggestions above (also mirrored in the Rect2i documentation)

Still unconvinced on how to describe the == and != operators without using the same generic one liner as before this PR.

One sentence I had in mind is "Returns true if all values (position and size) of both rectangles are equal." but it's quite generic, still.

[kleonc]

Still unconvinced on how to describe the == and != operators without using the same generic one liner as before this PR.

Same here. OTOH let's be honest: probably everyone understands what these operators do anyway. 🙃 So these could probably be left even as before this PR indeed.

---

Anyway, overall LGTM.
(Maybe the merger will have some suggestion regarding the wording for == and != operators... 😉)

[akien-mga]

Thanks!

[groud]

I am pretty sure this change is wrong. It was specifically modified because, when expanded to the right or bottom, the to point is not included in the rectangle by the has_point. (and this is on purpose)

[Mickeon]

Agh, this reply is technically correct. Saying "expanded to include" does imply that by calling has_point with the same point on the new rectangle , the result may or may not be true. I would like to think of a way to say this in a simpler way. At worst, the description needs to be mostly reverted back.

[Mickeon]

#80217