src: fix modernize-return-braced-init-list

[gengjiawen]

Fix https://clang.llvm.org/extra/clang-tidy/checks/modernize-return-braced-init-list.html.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[gengjiawen]

@addaleax Can you review this, thanks.

[addaleax]

@gengjiawen I’m not sure I see the harm in being explicit about return types…

[gengjiawen]

Give another thought, I agree with you.

[gengjiawen]

But from another way, this is less verbose in most cases ...
I am not sure which style should we follow.

Any opinion ?
@refack@bnoordhuis@jasnell@joyeecheung@cjihrig@targos

[refack]

Personally I prefer being tarse, but the concensus seems to be with being explicit #23028

[gengjiawen]

Reopen it to give this more discussion.

[devsnek]

i've literally never seen this before, and i suspect the same is true of others. i feel this would be more confusing than anything else.

[gengjiawen]

See https://github.com/empyrical/react-native/blob/d85e1875e0b6e68785547d74d4c136b1e4a7b645/ReactCommon/fabric/components/view/ViewProps.cpp#L94

[joyeecheung]

I can't really see the benefit this brings, aside from that it makes the return statements more succinct and potentially keeps them separate from return type changes, but then in the case of Maybes I like to see them explicit so it's easier to tell whether you are propagating the JS errors properly.

[gengjiawen]

Perhaps another time.