Endow operators '?' ':' '??' code branching functionality

[aplib]

Endow operators '?' ':' '??' code branching functionality, if they are combined with code blocks delimited with curly braces '{' '}'
in the general case or one unary code unit where the code parser allows;

As an example, in your code, try replacing the 'if' 'then' 'else' conditional operators and the null check in accordance with the operating logic of '?' ':' '??' .

I think we are already getting close to this.
Addition: In general logic, the '!??' operator may appear as the inverse of '??'.

[HaloFour]

Could you provide example code of what you're describing, before and after applying these operators? I don't really understand what it is that you're asking.

[KennethHoff]

This is basically just block expressions, right? Which is being worked on

[aplib]

As far as I understand, block expressions will have a number of restrictions that do not allow them to be used in the general case specifically for ode branching functionality. And I also didn’t see ‘!??’ anywhere proposed. Maybe I'm wrong.

[CyrusNajmabadi]

@aplib What restrictions do they have that don't alow them to be used specifically for code branching functionality?

[aplib]

@CyrusNajmabadi Is there a final proposal for block expressions somewhere? Since I don’t find what we finally came to today, and what the final proposed syntax is to answer your question.

[HaloFour]

I really don't like this as an alternative syntax to if statements. I personally find it significantly less readable and with a trivial amount of fewer keystrokes. Some of this might naturally fall out with existing proposals, like block/sequence expressions and ternary statements.

Addition: In general logic, the '!??' operator may appear as the inverse of '??'.

This would be ambiguous as ! as a post-fix operator already exists in the language, and it would be impossible to differentiate between cond !?? expr; and cond! ?? expr;.

[iam3yal]

It may be useful to add real life example where this feature might be used but the alternative or workaround is cumbersome to a point this feature is justified because throwing some arbitrary syntax without explaining the semantics and say "I want this" doesn't help much.

Personally I can't see the benefit.

[aplib]

@iam3yal This is not a matter of personal preference, it is a matter of generalization of syntax. This is the general trend.

[HaloFour]

It still has to be justified. The language isn't going to generalize all forms of syntax for the sake of doing so. Sometimes cases like this might fall out, but even in those cases if it leads to a form that is found to not be something that the team wants to generally encourage it could be actively prevented, even if that requires more work.