Code with types on the right like this makes me very sad

    static
    auto create(const char* data) -> Result<String>

Types are a lot more ergonomic on the left - the return type of a function and the type of a variable are very important for understanding and skimming code. When the return type is on the right, it is physically very far from the name of the object and I have to scan the entire line with my eyes to get the same amount of information I would get by just looking at the left column and scrolling down if it were on the left. I am pretty sure in another 20 years types on the right will be regarded as one of the ergonomic fails of current language design. At least, if have to do this, put the type right under the object name, like so:

    static auto
    create(const char* data)
    -> Result<String>

Future readers will thank you.

▲ 3836293648 7 months ago | parent | next [-]

Types are only nicer on the left when it isn't also annotated with all the other static constexpr [[nodiscard]] nonsense. And left types are actually greppable seperately from variable declarations.

Having both left and right types is stupid, but as a whole right types are easier to deal with

▲ winocm 7 months ago | parent [-]

I learned of a cute side effect when one puts the function name on its own line, like above.

In BSD of yore and modern contemporaries, one could often perform `grep '^function'` and end up finding the source file quite easily. I think it also makes using ctags(1) a bit easier too, but not entirely sure on that bit.

▲ Iwan-Zotow 7 months ago | parent [-]

you could grep `grep '^auto function'` with the same efforts

▲ 3836293648 7 months ago | parent [-]

No, that clashes with variable declarations. Sure, you could have a naming scheme that doesn't have that issue, but that doesn't help with library code.

▲ winocm 7 months ago | parent [-]

Pretty much.

Here's some declarations from an ancient UNIX (remember, UNIX(R) is a registered trademark of "The Open Group") ctags file to help show how that type of scheme works:

  ISDOT rm.c    /^#define ISDOT(a)      ((a)[0] == '.' && (!(a)[1] || (a)/
  Mrm   rm.c    /^main(argc, argv)$/
  PASS  rm.c    /^#define       PASS(byte) {                                    \\$/
  check rm.c    /^check(path, name, sp)$/
  checkdot      rm.c    /^checkdot(argv)$/
  rm_file       rm.c    /^rm_file(argv)$/
  rm_overwrite  rm.c    /^rm_overwrite(file, sbp)$/
  rm_tree       rm.c    /^rm_tree(argv)$/
  usage rm.c    /^usage()$/

Side note: https://unix.org/trademark.html

▲ PittleyDunkin 7 months ago | parent | prev | next [-]

I cannot disagree more strongly. Putting the name of the function (or method) in the middle of the declaration drastically lowers readability.

C-style type declarations were always the most painful part of reading C.

▲ binary132 7 months ago | parent | prev | next [-]

FWIW I completely agree, I think -> rt is a very silly idiom in declarations. It’s fine and useful for lambdas.

▲ bigstrat2003 7 months ago | parent | prev [-]

No they won't. Your example is way more unpleasant to read.