[Feature Request] Add single if statement tearoff (syntactic sugar)

[noga-dev]

Would be great to be able to do something like:

Navigator.canPop(context) ?> Navigator.pop()

instead of:

if (Navigator.canPop(context)) {
  Navigator.pop();
}

Honestly not a must, nor a priority. Just a personal preference, and might benefit many others like me.

Per my comments below, this is to be an optional operator. As in, both of the above can be used interchangeably. The suggested new operator is not a replacement of the standard if statement, but rather like a ternary in its purpose.

[noga-dev]

Good idea, but Navigator.canPop(context) ?> Navigator.pop() looks like an expression, and if this is an expression, it has to return something. Maybe it can return Never though. Would be especially handy if we could also use continue, break, return after ?> Looks "mathy" - quite a good fit for dart IMO.

My choice of ?> is arbitrary, I simply combined ?? and =>. Anything else will do, really; as long as it's short and simple.

[Levi-Lesches]

Keep in mind, you can already do this in one line:

if (Navigator.canPop(context)) Navigator.pop();

I don't really think an expression form is needed, since this is inherently a statement with control flow.

[noga-dev]

Keep in mind, you can already do this in one line:

if (Navigator.canPop(context)) Navigator.pop();

I don't really think an expression form is needed, since this is inherently a statement with control flow.

1. Doesn't always work. Don't remember if it's a linter error or warning but either way, it also leads to the (2) below. But also linter is inconsistent, as some don't like the absence of curly braces, others don't care, and others seem to encourage it.
2. Auto formatter can randomly choose to move the second part into a new line. Methinks it mostly depends on the amount of characters (80) in line, but it's inconsistent, so I don't like it.
3. I prefer ?> over if(). Personal preference. Doesn't mean the other option should go away, much like one isn't forced to use ternaries.

[lrhn]

The language allows unbraced if branches. The official language style guide allows it if it stays on one line, and the formatter respects that when possible.

Indeed, the braceless form of "if" exists, but it's ugly. I don't like it, and I don't know anyone who does.

And I like it 😁.

Some project specific style guides goes further and disallows unbraced if statements, for whichever reason makes sense to them (want control flow to be more visible, want consistency without exceptions, something third I don't know of).

I'd wager that the same style guides would also disallow such a ?> operator for all the same reasons, which makes adding another way to have a one-line conditional statement not really seem valuable.

[noga-dev]

Might be the OCD, but I want to shave off those extra 4 or 6 characters, i, f, (, ), {, }.

And surrounding the conditional with brackets and including if is slightly more work then just skipping the them entirely and appending a ?> after the conditional.

Additionally, the brackets in themselves are redundant (optional for our purposes), and a relic of dino conventions. Keep them for onboarding new devs for familiarities' sake, but make them optional for special snowflakes like myself. Hence the introduction of ?>.

[munificent]

I'm going to close this because I don't think it adds any significant value over current syntax. If we want to give users multiple ways of accomplishing the same goal, the new ways should either be noticeably better, or should at least be clearly better in some specific circumstances that the previous syntax doesn't handle well. I don't think either of those apply here, so it's unlikely we'd do this. Having two equally appealing ways to do the same thing just makes them spend mental effort making a choice without giving them anything of value in return.