multiple variable initialisation

[speter]

At present you can write something like:

Code: Pascal  [Select][+][-]

1. procedure foo;
2. var
3.   a : integer = 5;
4.   b : integer = 5;
5. begin
6.   //...
7. end;

Would it be possible to extend this to allow?

Code: Pascal  [Select][+][-]

1. procedure foo;
2. var
3.   a,b : integer = 5; // initialise 2 or more variables to some value
4. begin
5.   //...
6. end;

Or is this a really bad idea for some reason!?

cheers
S.

[dseligo]

I think this was suggested multiple times already, e.g.: https://forum.lazarus.freepascal.org/index.php/topic,49505.0.html

[speter]

I think this was suggested multiple times already, e.g.: https://forum.lazarus.freepascal.org/index.php/topic,49505.0.html

Thanks for that. I guess what goes around, comes back every year. Or something.

No worries.

cheers
S.

[Kays]

[…] Would it be possible to extend this to allow? […]

In Extended Pascal, which the FPC plans to support in a hundred years, it is legal to write:

Code: Pascal  [Select][+][-]

1. var
2.         a, b: integer value 5;

The GPC already compiles that and it works as expected.

[Leledumbo]

The rule with regard to extension has stood for long: https://www.freepascal.org/faq.var#extensionselect

The extension must have real value. Anything that is only a shorter notation does not apply, unless it is out of compatibility with an existing Pascal/Delphi codebase. Practically it means it must make something possible that cannot be done otherwise or be a compatibility item

[440bx]

That extension has real value. 

It explicitly shows that two or more variables should start with the same initial state (initial value.)  That is something that single variable initialization does _not_ accomplish.

[Leledumbo]

That extension has real value. 

It explicitly shows that two or more variables should start with the same initial state (initial value.)  That is something that single variable initialization does _not_ accomplish.

Read again:

Practically it means it must make something possible that cannot be done otherwise

The OP already contains the code how it can be done otherwise, that is NOT a real value mandated by the rule. The quoted sentence above clarifies the meaning of real value because as you've tried, interpretation may vary otherwise.

[440bx]

Read again:

Practically it means it must make something possible that cannot be done otherwise

The OP already contains the code how it can be done otherwise, that is NOT a real value mandated by the rule. The quoted sentence above clarifies the meaning of real value because as you've tried, interpretation may vary otherwise.

I can read that many times BUT, if that were a practical and rational measure then neither "for" (much less "for .. in"), "while", "repeat", not to mention classes and objects would be justified.  All loops can be created with "if" and "goto" and all objects and classes can be created with tables of function pointers (which is what they are anyway.)

If that were a valid reason, we wouldn't even have compilers, we can do everything a compiler can do (and then some) in assembler. 

[MarkMLl]

That extension has real value. 

It explicitly shows that two or more variables should start with the same initial state (initial value.)  That is something that single variable initialization does _not_ accomplish.

Read again:

Practically it means it must make something possible that cannot be done otherwise

The OP already contains the code how it can be done otherwise, that is NOT a real value mandated by the rule. The quoted sentence above clarifies the meaning of real value because as you've tried, interpretation may vary otherwise.

By that argument, we might as well all go back to writing in assembler since anything that can be done with a compiler can be done using an assembler.

Leaving aside for a moment that the Core Developers have repeatedly stated that they won't be doing this, I think that it's necessary to distinguish between this form of multiple initialisation (at the point of definition, with all variables being explicitly the same type) and multiple assignment (where there is a risk that automatic type conversions will be applied).

Multiple assignment is a minefield in any language with automatic conversion, multiple initialisation is arguably useful.

MarkMLl

[marcov]

It was exactly for this reason. Avoiding endless decisions for endless suggestions of micro syntax "improvements".

[440bx]

It was exactly for this reason. Avoiding endless decisions for endless suggestions of micro syntax "improvements".

It is not a simple syntax improvement. 

The reason for allowing multiple variables in a declaration is to make it clear that those variables should be of the same data type.  That way, if someone decides to change the type (or name of the type), all the variables in the declaration are automatically changed (less room to make a mistake.)

It's exactly the same thing with the value.  If a group of variables (obviously of the same type) should have the same initial value then that fact would be automatically ensured if the value could be stated in the declaration.   Currently, Pascal does not have a mechanism to ensure that two or more variables have the same initial state.

That feature is NOT about syntax or micro-anything.  It's not occult science... not even micro-occult.

What's genuinely surprising is that this extremely easy to implement feature is not yet part of the language (though, a bit less surprising when considering the "analysis" it gets from some people.)

[eny]

Code: Pascal  [Select][+][-]

1. const MAGIC_NUMBER_5 = 5; // 5 because it is one more than 4 and one less than 6
2. ...
3. procedure foo;
4. var
5.   a : integer = MAGIC_NUMBER_5;
6.   b : integer = MAGIC_NUMBER_5;
7. begin
8.   //...
9. end;

[440bx]

Code: Pascal  [Select][+][-]

1. const MAGIC_NUMBER_5 = 5; // 5 because it is one more than 4 and one less than 6
2. ...
3. procedure foo;
4. var
5.   a : integer = MAGIC_NUMBER_5;
6.   b : integer = MAGIC_NUMBER_5;
7. begin
8.   //...
9. end;

Not good because the constant name is not unique in the declaration.  IOW, you should not have to duplicate the constant's name because when modifying the program, the programmer has to ensure every instance of the constant is updated and must also ensure that if a new variable is declared, the constant's name is used to initialize its value.

The natural solution to those problems is to have a single declaration for all the variables that share a type and initial value.

[Seenkao]

Я так же хотел чтобы это было в паскале. Но, чем дальше я занимаюсь программирование, тем более понятно, что тут будет множество подводных камней. И код:

Code: Pascal  [Select][+][-]

1. var
2.   a: integer = 3;
3.   b: integer = 3;
4. ...

должен быть идентичен коду:

Code: Pascal  [Select][+][-]

1. var
2.   a, b: integer = 3;
3. ...

Но если взглянуть на это с другой стороны, то многие не будут понимать что происходит. И код:

Code: Pascal  [Select][+][-]

1. var
2.   a: integer;
3.   b: integer = 3;
4. ...

не будет идентичен коду

Code: Pascal  [Select][+][-]

1. var
2.   a, b: integer = 3;
3. ...

хотя пользователь во втором случае захочет выделить именно значение "b = 3", но не "a".
А таких ситуаций будет больше, чем при той ситуации, когда так объявлять переменные нельзя.

google translate:
I also wanted it to be in pascal. But, the further I do programming, the more it becomes clear that there will be many pitfalls. And the code:

Code: Pascal  [Select][+][-]

1.  var
2.   a: integer = 3;
3.   b: integer = 3;
4. ...

should be identical to the code:

Code: Pascal  [Select][+][-]

1.  var
2.   a, b: integer = 3;
3. ...

But if you look at it from the other side, then many will not understand what is happening. And the code:

Code: Pascal  [Select][+][-]

1.  var
2.   a: integer;
3.   b: integer = 3;
4. ...

will not be identical to the code

Code: Pascal  [Select][+][-]

1.  var
2.   a, b: integer = 3;
3. ...

although the user in the second case will want to highlight exactly the value "b = 3", but not "a".
And there will be more such situations than in the situation when it is impossible to declare variables in this way.

[damieiro]

Well, i have read this now.

I agree with 440bx view.  I think that group variables like this

Code: Pascal  [Select][+][-]

1.  
2. const
3.  INITIAL_VALUE=0
4. var
5.   a, b, c, d, e: integer = INITIAL_VALUE;

Or

Code: Pascal  [Select][+][-]

1. const
2.  INITIAL_VALUE=0
3. var
4.   a, b, c, d, e: integer;
5.  
6. begin
7.   a, b, c, d, e:=  INITIAL_VALUE;
8.  
9. end;
10.  

it's better for homogeneus treatment of these. There is One entry point to change. And if you like old ways, then use it. I like modern ones.
And compiler has a hint of serialization (do all the operations with less register operations, for example)
Really is more information in this code, because programmers does the group of similar variables.

And i do not view this as a C vs Pascal syntax. I view this like a old-ways modern-ways of doing things. C vs pascal is a=0 or a:=0 or braces vs begin end.
But the code is really more readable allowing multiple instantiation/initialisation. And technically is possible.

Other way (but this could be out of pascal way of thinking) if we were allowing initialising types

Example (for the sake of completness, but really with above it's fairly enough)

Code: Pascal  [Select][+][-]

1.  
2. const
3.  INITIAL_VALUE=0
4.  
5. type
6.  TIntegerInitialized=integer =INITIAL_VALUE;
7.  //example of type plus initialization, all of these types will be initialized.
8.  
9. var
10.   a, b, c, d, e: TintegerInitialized;