In C, there is an operator known as the conditional operator ( ?: ). The conditional operator is pretty much a faster way to use a basic if/else. Since conditional operators are not that hard to learn and are really useful, I think Scratch 3.0 should have conditional operators.

The suggestion:

There are three conditional operators– the reporter type, the stack type, and the boolean type. All of them are in the control section. Each type is explained below.

Reporter type

(If <>, then [], else []::control)

The reporter type reports the value of the second input if the first is true or the value of the third input if the first is false.
Example:

when green flag clicked
set [applesEaten v] to [1]
say (join [I ate ] (join (applesEaten)(join [ apple] (If <[applesEaten] > [1]>, then [s.], else [.]::control)))
wait (2) secs
set [applesEaten v] to [2]
say (join [I ate ] (join (applesEaten)(join [ apple] (If <[applesEaten] > [1]>, then [s.], else [.]::control)))

Output of the example:
“I ate 1 apple.”
2 seconds later…
“I ate 2 apples.”

Stack type

If <>, then ([]::stack), else ([]::stack)::control

Note: the string inputs are placeholders for a new type of input called stack inputs.
The stack type executes the second input if the first is true or the third input if the first is false.
Example:

when green flag clicked
ask [Do you know Python? Y/N] and wait
If <(answer) = [Y]>, then (say [I know Python, too!] ::stack), else (say [I shall teach you Python!] ::stack)::control

Example output of the example:
“Do you know Python? Y/N”
>>> Y
“I know Python, too!”

Boolean type

<If <>, then <>, else <>::control>

The boolean type reports the value of the second input if the first is true or the value of the third input if the first is false.

Example:

when green flag clicked
say [Press either 1 or 2.]
set [key v] to [1]
wait until <If <(key) = [1]>, then <key [1 v] pressed?>, else <key [2 v] pressed?>::control>
say [You pressed the right key!]

Example output of the example:
“Press either 1 or 2”
*key 1 pressed*
“You pressed the right key!”

Notes:

1. At the moment this section is unused.
   

I think that might allow new possibilities, isn't it?

I like this idea.

No support.
What is wrong with

if <> then 

  

else

end

?

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

red_king_cyclops wrote:

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

Still, I really see no reason to add the requested block; it doesn't do a whole lot of different things then the current block does.

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

Still, I really see no reason to add the requested block; it doesn't do a whole lot of different things then the current block does.

True, but the conditional operator can be more convenient in some places.

red_king_cyclops wrote:

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

Still, I really see no reason to add the requested block; it doesn't do a whole lot of different things then the current block does.

True, but the conditional operator can be more convenient in some places.

Still, no support. I can't think of any situations that the suggested block would be more conveniont.

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

Still, I really see no reason to add the requested block; it doesn't do a whole lot of different things then the current block does.

True, but the conditional operator can be more convenient in some places.

Still, no support. I can't think of any situations that the suggested block would be more conveniont.

True, there isn't much reason to add a feature that nobody can think of a clever way to use. But what about the first example I used in the original post?

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

The ternary operator exists in a lot of other programming languages; it also can make your code more concise and easier to read, which is very important in programming.

Just so much duplicate.

bump #1

red_king_cyclops wrote:

< if <>, then [] else [] :: control>

A better way to do that would just be to add custom reporters (Sratch Team, please)
If they dont come, Support

red_king_cyclops wrote:

If <>, then ((::stack control) :: grey ring), else ((::stack control) :: grey ring)::control

WHAT?? No Support, thats litterly just

if <> then 
else
end

red_king_cyclops wrote:

<if <>, then <> else<> :: control>

too easy of a workaround without much usefulness, No Support
(Also, its kinda redundant with the reporter thingy)

<<<if> and <Input then>> or <<not <if>> and <Input else>>>

I support the if <> then , else. I think there should also be a if <> then block, for when you don't need the else statement. It actually makes the code cleaner. The other blocks are just kind of redundant.

I only support the suggestion for the reporter.

The boolean can be easily worked around:

<<<condition :: grey> and <first input :: grey>> or <<not <condition :: grey>> and <second input :: grey>>

badatprogrammingibe wrote:

The boolean can be easily worked around:

<<<condition :: grey> and <first input :: grey>> or <<not <condition :: grey>> and <second input :: grey>>

Problem is, you need to specify the condition twice there. That always looks bad (duplicated code is not a good thing here!), and if your condition is really, really long, it's very inconvenient too.

Support. This could be so useful for 1LCs.

M4- wrote:

Support. This could be so useful for 1LCs.

As Sheep_Maker has pointed out, this is a duplicate. Please continue the discussion there.

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

red_king_cyclops wrote:

PrincessFlowerTV wrote:

No support.
What is wrong with

if <> then 

  

else

end

?

There's nothing wrong with the normal if/else, but the conditional operator can save time, go where a normal if/else can't, and can do basic if/elses faster, and isn't very confusing. The normal if/else has the advantages of being a little more readable and being able to do more complex tasks, so its not like the normal if/else is getting replaced.

Still, I really see no reason to add the requested block; it doesn't do a whole lot of different things then the current block does.

True, but the conditional operator can be more convenient in some places.

Still, no support. I can't think of any situations that the suggested block would be more conveniont.

I can think of many, for example a 1LC. Or what if we have a project that requires lots of if then else loops? Why not compact it down with this block?

Queer_Royalty wrote:

M4- wrote:

Support. This could be so useful for 1LCs.

As Sheep_Maker has pointed out, this is a duplicate. Please continue the discussion there.

It's not there, unfortunately.