Personally I think the ability to use references, etc. is worth it, as well as allowing for further improvements in the future like interfacing with other areas of Blender that use types like Span which I see as a huge improvement.
However in the interest of just getting this finished I changed this new file to C.

I had to do this at the top of the file: #include "../intern/bpy_rna.h"
If that's not okay I can revert this change.

*picky* I normally put each "\n" on it's own line so this reads roughtly as it would as plain-text.

This if fine, although we could move this to a more generic define that doesn't pull in the whole Python RNA API.

This is no longer needed.

Changes to type comparison would be better handled in a separate patch so it's not just limited to lines this patch touches.

There can be a benefit in the function it's self not being able to modify the argument (similar to const local variables).

If this is something to avoid it should probably be handled at the level of code style proposal, there are many instances of this in the code base. The code-style page even uses braces in it's examples.

I'd rather keep the successful return last, otherwise it complicates adding other kind of arguments later on, as well as cleanup functions which are fairly common with C/Python API.

With the error returns here, it's possible to half-initialize data.

In general this should be avoided, it means a try/except could run the command, changing min/max but not defaults - for eg.

It might be simplest to operate on a copy of ui_data, writing it back at the very end, before returning true.

Yes, but that is only effective when you declare the parameter as const in the definition. As I said, in the declaration it has no meaning, and should thus be removed to avoid confusion.

I think it's a very bad idea to avoid clearer code now. Reduction of cognitive complexity is important. If there is a desire to do cleanup after the code runs, it might be an indication that it should be split up into smaller functions (init, work, cleanup).

What you propose is keeping code more complex, just for the hypothetial case that the code might be expanded in the future; this usually is a bad way to design code, unless those expansions are already known & to be taken into account.

What you propose is keeping code more complex, just for the hypothetial case that the code might be expanded in the future; this usually is a bad way to design code.

It's quite reasonable to write code so adding new arguments doesn't require existing shuffling code blocks about.

To avoid half initialized data it's likely some cleanup/finalizing functionality will need to run before the function exists.

As you've suggested the code was split into a function so this should settle both our concerns.

I think refactoring this to use separate classes would just increase the complexity, and anyway, it would require a larger refactor of the surrounding code which I don't want to do in this patch.

In this case I'm just rearranging the code that was already here: prop_type == float, etc.

I get your point, but I'd rather keep this patch focused on its goal, not refactoring/improving type comparisons in this operator.

Agreed. Currently it's pretty easy to understand the change looking at this diff. With the change suggested above the change becomes less obvious.

Because these are the property types that support having a default.

I started adding a comment here, but decided not to, since I was just restating the logic of the code itself.

Generally I think this operator could be refactored, there could be some UX improvements like selecting the property type from a dropdown.
But I'm trying to work within the logic already here, so I'd really like to avoid larger changes for now.

Those are the types that support these UI data values.

Good point, thanks!

Yeah, but Sybren's point is that the declaration doesn't need to have const by-value arguments, only the definition.

Personally I disagree (I'd much rather have the declaration and definition exactly the same), but it's in the style guide apparently, so I will change this.

Yes, good point.

I'd rather have them be consistent with the other cases that do need the braces.

I'll split it to a separate function, but I don't want to return early in the second way you suggested because I don't think it's more readable-- the two cases are around the same size, and it's only one if statement in a function-- 2 levels of indentation.

I got into the habit of matching const otherwise MSVC throws a lot of warnings, if that changed recently, we could consider removing const values in headers.

According to @Ray Molenkamp (LazyDodo) this still warns with MSVC 2017, which is still supported. But it's no longer an issue in MSVC 2019.