1

In C, you can assign two variables in one line with

b = a = sqrt(10);

In Delphi

b := a := Sqrt(10);

is not allowed.

With IfThen, there is an "alternative" for the ternary operator ?: as discussed in Delphi - Equivalent to C#'s ternary operator? In summary, IfThen doesn't seem absolutely necessary.

So maybe there is also something like this:

function AssignAndReturn(var LHS: Integer; RHS: Integer): Integer;
begin
  LHS := RHS;
  Result := RHS;
end;

(...)

var
  a, b: Integer;
begin
  b := AssignAndReturn(a, Round(Sqrt(10)));

I'm not trying to "make everything look like C". I just noticed, that sometimes it would be nice to "reuse" the right hand side of an assignment in the same line again. (See Lazarus/Free Pascal: How to improve coding style (to avoid using endless loop) of a while loop whose boolean expression is reassigned every pass for example.)

finefoot
  • 9,914
  • 7
  • 59
  • 102
  • Did you look at the source to see how IfThen is implemented? (I'm not the close voter, BTW) – Ken White Jun 20 '16 at 22:27
  • 1
    @muschL: What *exactly* are you asking for ? This example shows a function which assigns to some variable and also returns the result, but this does not explain why you could not simply assign to the variable that you pass to the function and use that variable where you would have used the function return value. For more helpful responses, instead of showing a solution and asking a question which makes little sense on its own, explain what problem your solution is trying to solve, why you consider it inadequate and what you are trying to achieve that your solution currently does not. – Deltics Jun 20 '16 at 23:18
  • 2
    Delphi's IfThen is not equivalent to the C ternary operator. Try it with functions that have side effects on both sides and you'll see the difference. Your edit clarifies what you're asking, but I fail to see the point. Your mess with AssignAndReturn in your final example is horrific, and two separate lines of code to accomplish the same thing would be much more readable and maintainable. I fail to understand why people want to obfuscate or deface code by converting everything to *look like C*. – Ken White Jun 20 '16 at 23:54
  • 1
    In Pascal `:=` isn't an operator and doesn't return a *l-value*. This is by design. Your current solution is only possible way to do as you want. – Free Consulting Jun 21 '16 at 00:38
  • 3
    Regarding the edit, `IfThen` is not equivalent to an `if then else` statement. Only one branch of the `if then else` is executed. All arguments to the `IfThen` function are evaluated. Secondly, you already have an answer to your question. It is a simple "no". Thirdly, the reason people are criticising your proposed function is that it is a very bad idea to implement and use such a function. Do expect people to give you advice. Then it's up to you to decide how to react to that advice. – David Heffernan Jun 21 '16 at 08:39

2 Answers2

9

An assignment statement is not an expression. It does not, and will never, yield a value. The only way to assign to multiple variables in one statement is via a function.

Based on this question and your previous question I would say that you are mistaken in trying to fight against the language. Code into the language you are using. In C you might write 

b = a = sqrt(10);

But in Pascal the language wants you to write it like this

a := sqrt(10);
b := a;

Do it this way. Don't create obscure functions just so that you can cram it all onto a single line. The two lines above could not be clearer to read. Stop trying to force other languages into Pascal. They don't fit.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
2

The short answer is:
No. What you want is not possible. And arguably would be of little if any benefit in Delphi.

First, let's discuss a more practical example. To be frank, a = b = f(x); is a rather poor example.

  • It's rare that you arbitrarily want the same value assigned to 2 variables.
  • Order of operation above has to break the left to right convention otherwise it would first resolve a = b then ? = f(x).
  • So there's little justification to favour that over b = f(x); a = b;.
  • Basically it's good for byte count (code golf) not readability.

So instead, let's consider the following, more practical scenario:

//Option 1
if ((b = f(x)) > 42)
  //use b

There's no Delphi equivalent to the above, but it's at least as readable/maintainable to write:

//Option 2
b := f(x);
if (b > 42) then
  //use b

There is another option to consider; especially if Option 1 is sitting in the middle of a larger function. Remember small functions are more maintainable and easier for a compiler to optimise. So consider:

//Option 3
...
ProcessRule42(f(x));
...
//Where Rule42 is is implemented as:
procedure ProcessRule42(b: Integer);
begin
  if (b > 42) then
    //use b
end;

Delphi doesn't really seem to be suffering due to not being able to write: if (b := f(x)) > 42 then //use b.

Is there any real benefit to Option 1?

If the Option 2 is at least as good, why would one ever bother with Option 1. The benefit is seen when you consider scoping rules.

//b does not exist
if ((var b = f(x)) > 42) {
  //use b
}
//b does not exist 

// Using the Delphi approach, this becomes:
//b does not exist
var b = f(x);
if (b > 42) {
  //use b
}
//b still exists

Delphi simply does not have the same scoping concerns. Delphi variables are all declared at the beginning of the method, and available for the whole method.

Conclusion

This brings us back to what others have been trying to explain. Delphi is a different language with slightly different approaches to some problems. While I applaud you for examining other options and considering what concepts can be borrowed from other languages: be careful of trying to force-fit some concepts where they don't belong.

If you break too many Delphi paradigms, your code may become unnecessarily difficult for Delphi programmers to maintain.

Community
  • 1
  • 1
Disillusioned
  • 14,635
  • 3
  • 43
  • 77
  • 1
    Also, `b = a = fx()` as well as `if (b = a)` are vulnerable to trivial typing errors resulting in substantive behavioural differences. i.e. what if you had really intended to write `b = a == fx()` or `if (b ==a)` ? The syntax of Pascal explicitly is intended to avoid such problems and clearly distinguishing between statements and expressions is part of that, and A Good Thing, imho. The "Pascal Way" to do this would be to allow a comma list of variables on the LHS of an assignment, thereby retaining the statement/expression distinction while allowing multiple simultaneous assignment. – Deltics Jun 21 '16 at 21:00