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?

fun is the best, as it makes the function name align with the code block indented 4 characters :D

    fun main() {
        println("Hello, world!")
    }
        ^ aligned here! \o/

Keywords usually are quite pronounceable, and some of them are even proper words. How do you read fn?

Usually as "function"

fun

fn

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.

It is kind of ironic how people still get stuck discussing syntax to save keystrokes and then write a whole book on the AI chat window.

Probs too archaic?

"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.

The c++ notation for functions (and types in general) is horrible, and makes parsing much more expensive than it needs to be. Fixing it is step one if you are making a modern language.

A compatibility required by C.

To avoid any possibility of reintroducing the Most Vexing Parse?

https://en.wikipedia.org/wiki/Most_vexing_parse

It doesn't, but you can pretend it does:

  auto my_function(int, double) -> int;

They probably want to use the same arrow signature and need something in place of auto as omitting it completely would complicate parsing.

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).

I like it the most when there's no keyword. Just name() and return type.

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.

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?