Skip to content

if - assignment operator #820

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
vsevolod19860507 opened this issue Feb 6, 2020 · 7 comments
Open

if - assignment operator #820

vsevolod19860507 opened this issue Feb 6, 2020 · 7 comments
Labels
feature Proposed language feature that solves one or more problems

Comments

@vsevolod19860507
Copy link

vsevolod19860507 commented Feb 6, 2020

At the moment Dart has ternary operator that requires "else" part.
In the cases when I need something like this

var s1 = 3;
s1 = s1 > 3 ? 100500 : s1

": s1" is redunant.

Or I should use "if"

var s1 = 3;
if(s1 > 3){
   s1 =  100500;
}

I think It will be useful to have another one aproach to do this, something like this:

var s1 = 3;
s1 ?= s1 > 3 : 100500;
var s2 = 3;
s2 ?= s2 > 3 : 100500 + 56 * 78;

If the condition is false than all expression ignors. And the old value will not change.

This is something like collection "if" but witout collection.

@vsevolod19860507 vsevolod19860507 added the feature Proposed language feature that solves one or more problems label Feb 6, 2020
@kennethnym
Copy link

kennethnym commented Feb 7, 2020

var s1 = 3;
if (s1 > 3) s1 = 10050;

is more readable imo.

@vsevolod19860507
Copy link
Author

vsevolod19860507 commented Feb 8, 2020

Ok, but these

var s1 = 3;
if (s1 == null) s1 = 10050;
var s1 = 3;
var s2 = 5;
if (s1 == null) s1 = s2;
var s1 = 3;
var s2 = 5;
if (s1 > 3) {
  s1 = 100500;
} else {
  s1 = s2;
}

are more readable than these

var s1 = 3;
s1 ??= 10050;
var s1 = 3;
var s2 = 5;
s1 = s1 ?? s2;
var s1 = 3;
var s2 = 5;
s1 = s1 > 3 ? 100500 : s2;

But for some reasons they exist ...

@kennethnym
Copy link

kennethnym commented Feb 8, 2020

Which is why I think dart should support if expressions (I think there's another issue for it). These operators, though short, severely affect readibility.

@vsevolod19860507
Copy link
Author

Sounds logical, I like the idea about "ignore"

@lrhn
Copy link
Member

lrhn commented Jun 24, 2023

I'm not seeing the big advantage (or readability improvement) of x ?= test : value; over if (test) x = value;.

It's not an impossible idea, we have x ??= value which does pretty much the same thing, just for a single specific test.
The syntax, in particular yet another use of ? and :, is probably not going to work. Quickly, tell me what var x = { y ?= z : w : q }; does! (If anything.)
The reason x ??= value works is that it references x only once. If we were to use a general ... ?= ... : ... syntax for it, it would be x ?= x == null : value. That repeats x, which also means that there is no real link between the variable being assigned and the reason it's being assigned. There might be, but it's not inherent. You can do x ?= today.isTuseday : 42; too.
Without that link, being able to mention x only once, the significant advantage over if (x != null) x = 42; goes away.
It's just a different way, slightly shorter, but not really much better. Just different, which by itself is actually a drawback.

The conditional operator (the ?/: operator, called "ternary" because it takes three operands, but in Dart it's not the only ternary operator) is inherited from C. It's not great syntax by today's standards, but it's well known and very concise.
(And uses two of the characters that we really like to use for many other things.)
I use it where it makes sense, when a condition choosing between two values is really what I want. For everything else, use if.

@rrousselGit
Copy link

@lrhn I think folks really want a condition expression without an "else" clause.

For example there are many requests for:

Obj(
  param: if (condition) value
)

And we can already do it with collection litterals.

To me, this is just another take on the topic.

@lrhn
Copy link
Member

lrhn commented Jun 25, 2023

I want an else-free condition too, but it requires defining what it means. There are two options:

  • What "elements" (collection elements, map entries) do. If there is no else branch, the false value introduces no value/entry.
  • What an expression would have to do: If there is no else branch, the value is null. There has to be a value.

List elements can always be omitted, so it makes sense to use element semantics

Parameters are interesting, because optional parameters can be omitted, required cannot.
Optional positional parameters can be omitted, but currently only if omitting all later positional parameters too.

Looking at Obj(param: if (condition) value), I can't tell whether this omits an optional parameter, or passes null to a required one, if we allow both meanings.

So, allowing only one meaning is more likely: Allow a single-value element expression for optional parameters (and allow omitting non-trailing optional positional parameters).

And then it's not an expression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

4 participants