Comment by mihaic

3 days ago

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword?

That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning.

Even the "function" from Javascript seems fine to me.

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

  • I don't even code in kotlin but I know that kotlin has function as fun :P

    Such small things as using __ __ in python and small inconveniences (lua's 1 instead of 0) really has a lot of people, what do I say.. yea, polarized on this matter.

    • 0 vs 1 indexing has an actual semantic difference that you have to keep in your head at ~all times, but could have a text editor plugin that rewrites func<->fn since it's purely syntactical.

      What is inconvenient about it?

I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.

I use emacs' prettify-symbol mode to turn every language's function keyword into ʩ. Don't think I incurred in God's wrath just yet.

  • Why not just write it as fun, that way you are having fun while writing a function just as (God intended,[pun intended]) :P

How about "proc"? Too different? I don't like fn either but function is too much. Fun and func aren't great either. I'd go with proc or fn.

  • fun, press tab, modern IDE fills in the remaing function characters.

    Unfortunately we keep designing languages for people using notepad.

    Nowadays my editor even writes full blocks at a time.

    • If "fun" and "func" are already "not great" (because, I presume, they're too long), then "fun[TAB]" is not the solution.

      Mind you, I'm not saying that your solution doesn't work. Just that it doesn't work for the GP.

      1 reply →

"func" is fine; "function" is too long. "fn" is also good, but for example, Go was designed with "func," and it's one of the most successful, readable languages in the world, so why not?

C++ does not have a function keyword at all, I wonder why did they add it in the first place.

F# uses “fun” and I like it. The vowel does help a bit and I never confuse it with the English word. The worst one IMHO is Haskell’s “\”.

Since interop is such a big design goal I wonder if fn was chosen after analyzing the impact of alternative keywords present in large c++ code based that would impact interop in a negative way (eg requiring more escaping).

Pony's keywords are the best. "fun" and "be" are just, well, fun lol.

I agree, I hate fn. Also not a fan of func though.

In C++ you can use indifferently either the class or typename keyword to introduce template arguments (because of course you can). A lot of styleguides suggest using typename because class is slightly misleading (the type could be anything not just a class).

In practice everybody just uses class, because who as the time to type the full keyword and signature declarations in C++ are already unwieldy as it is.

  • Anyone using a proper IDE instead of notepad like editor.

    • I have that and still prefer class, easier to type(not just shorter, but easier keys) and less to read. Only use typename in the rare case where it is required

    • I do use a proper ide with with clangd completion and all kind of helper macros, but I can still type 'class' faster than I can trigger completion.

Tbh, I wonder why modern languages still have a function keyword at all, e.g.:

    const add = (a: i32, b: i32): i32 => a + b;

...or any variation of the arrow-function idea...

  • It's the other way around. Modern languages and grammars use explicit leading keywords to clearly indicate what sort of context they're about to parse, rather than blindly forging ahead in a superposition while waiting for some future sequence of tokens to clarify what the context is.

  • It's hard for a naive parser (one-token lookahead, for example), to tell after parsing `const add = (` if this defines a function or a variable.

    A "function" keyword often exists just to help the parser. C3, for example, to simply the parser of its language that's a superset of C, adds a "fn" keyword for this very purpose of disambiguation.

  • That looks like a variable that points to an anonymous function. For simple small functions here and there it may not matter, but if the entire call stack in a debugger is full of anonymous functions then it could be a problem.

  • IMO it is far easier to read this:

        function add(a: i32, b: i32): i32 {
            return a + b;
        }
    

    Than the example you provided and it is approximately the same length. I used to arrow functions everywhere in TS/JS and it made it difficult to read IME, and there was zero benefit. They are find for things like event handlers, promises chains etc. But I'd rather just use function when I don't have to worry about the value of this.

  • You're assuming that named lambda is the same thing as a function, which often isn't true. Unless you mean that `=>` should be ambiguous depending on scope (lambda inside a function, a function in global scope)? That would also be a bit problematic, wouldn't it?