Except that any variation of these doesn't produce the same thing as a declaration, since function declarations hoist and function expression assignments do not.

Most people don't like hoisting -- and I agree that variable hoisting is crazy. I'd never advocate this:

    a = 2;
    var a;

But function hoisting I find super useful. I always prefer to write my files like this:

    foo();
    bar();
    
    // ....
    
    function foo() { .. }
    
    function bar() { .. }

...because when I open a file, I don't want to go hunting for any executable code, I just want to look at the very top. Function declaration hoisting lets me put those definitions at the bottom and the code that uses them at the top.

I've found this to be much more useful in code maintenance.

I agree on function declarations even though I avoid hoisting in other situations. I don't see any serious downsides to using function declarations (unless within a function, perhaps), and I find it easier to read, especially in ES6: `export function diameter` vs. `export const diameter = ...`.

If you just write everything in order of usage, the executable code still winds up in a very easy-to-find place -- the very bottom, rather than the top.

That's how I write my JS as well. It's like speaking

Actually, I believe arrow functions keep the name of the binding.

    const diameter = () => {};
    export const radius = () => {};

Could be wrong.

What you're thinking about in ES6 is called "function name inference" and only refers to certain forms, like this one, where the name -- PURELY FOR DEBUGGING -- can be inferred. Actually, it goes for all assignments, `var`, `let`, and `const`.

Otherwise, the arrow itself is anonymous and thus you don't have a name to make an inner self-reference with.