Revisit function_expression_space_after_function_keyword

[dsherret]

See my upcoming comment in dprint/dprint#190.

Right now this option is not consistent because there is not a space before the generator star so some other solution should be found here or perhaps a rename.

[resolritter]

I definitely interpert the star as being part of the whole keyword, just like a "pointer type" sort of thing, but nevermind that.

Regarding your replies in the other issue, I think they are fair. One of them, though, is relevant for the big idea behind my arguments, so I'd like to bring it up

Point 2: The same could be said about function calls, which goes against point 3.

functionInvocation(... or new MyClass( being glued to the parens visually sets expressions apart from declarations. That argument was all about keywords being preceded by space, not identifiers, which come up arbitrarily in user code.

While I do realize those views and expectations of mine are probably very biased towards prettier's arbitrary "opinionated style", the driving notion behind those arguments is to have less variance. In the example of TypeScript, considering a function declaration, it follows

function (maybe name) (maybe type arguments) (parens)

which results in lots of ways of reading the same thing based on whitespace

function(
function<T>(
function<T> (
function <T>(
function <T> (
function (
function name(
function name (
function name<T>(
function name <T>(
function name<T> (
function name <T> (

However, notice how the only thing for certain is: if the declaration is named anyhow, function has a whitespace after it, at some point. It leads to the most recurring pattern being:

reserved tokens->space->identifier

which is an argument towards following this general structure in the defaults. How people generally deviate from that in their own configuration is not really taken into account here: if they want it to be "just like prettier", they have the power to do so.

My plea is not catering to individual preferences, but for generally having as less variance as possible for reading the language's constructs. How that actually ends up looking like is of no concern to this argument, as long as it leads to less variance from a reading standpoint.

At the same time, if this intuition is very uncommon among developers, I think it's fine to generally follow other tools' styles, so that people don't have to override the same configurations everywhere.

Thanks for your time and consideration. Loving how fast dprint is, it gives me rustfmt vibes. :-D

[ksmithut]

One point of data for what other tool's preferences are, standardjs has an eslint rule for putting the generator * with a space between the function keyword and the *.

It's interesting though because with my setup, it seems somewhat inconsistent? Using the default options:

function* foo() {
  yield true;
}

const bar = {
  *foo() {
    return true;
  },
};

The * is after the function keyword and leaves a space before the name, but when the function is a property on an object, the star is right next to the name.