RFC: Strict Mode. #4
Conversation
ike709
left a comment
ike709
left a comment
There was a problem hiding this comment.
I support the concept; I'll wait until the PR is undrafted before doing a full review.
I wish we had maintained a list of all the cursed behavior we've discovered throughout OD development.
| ### floor(v), ceil(v), round(v), fract(v), trunc(v), sign(v) and other math functions | ||
| These treat any non-numeric value as 0. | ||
| This behavior is not documented. | ||
| ### lowertext(str) and uppertext(str) |
There was a problem hiding this comment.
| ### lowertext(str) and uppertext(str) | |
| ### min(null), max(null) | |
| Any null values in the input should result in an output of null. Any empty strings should do likewise. | |
| ### lowertext(str) and uppertext(str) |
LemonInTheDark
left a comment
LemonInTheDark
left a comment
There was a problem hiding this comment.
What's the like, goal usecase here? If this is meant to be the "ideal standard" for codebases then some of these changes are nonfunctional. Like, if the goal is to get performance benefits out of swapping over then you're going to have issues convincing codebases to switch, but if it's for like a more reliable testing mode (or something?) then that isn't a concern.
I don't want to leave useless feedback basically, assuming this is still even being presued.
| This returns `16777215` on non-numeric x (24-bit negation of 0). | ||
| This behavior is not documented. | ||
| ### `x in y` | ||
| When the lefthand `x` is not a list, atom, or the world, false is always returned. |
There was a problem hiding this comment.
do you mean the righthand y here? or am I not understanding the example
4 participants
This RFC proposes a unified "strict mode" to disallow most undocumented, implementation-exposing behavior in BYOND functions.
https://github.com/OpenDreamProject/rfcs/blob/fa0e5da666823a8e04d6434e0e73558592e86031/docs/strict-mode.md