Wishlist - (language evolution)

[AlanTheBeast]

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

1. 1. Endcase;          // I resort to     end; {case}

2. VAR init lists:

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

1. VAR
2.      i,j,k: billionbitword = 0;

3. Non 0 based re-dimension of arrays. 

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

1.       G: array of array of grapefruit;
2. ...
3.      SetLength (G, [1..12],[1..6]);

4. Non-declared local ordinals. Ideally in register.  Only within loop blocks.

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

1. j := BobIQ;                    // j in scope, i does not exist
2. for i := 1 to Q do
3.     begin
4.          SnapSUM (i, j);     // i is an ordinal of the same type as the for statement range.  If Q=Word, i:word;
5.          PorkBelly(i*x);
6.     end;                          // i ceases to exist ...
7.  
8. Repeat
9.      i := 23+j;
10. Until i>400000;            // ceases to exist.  Type has to support the range of j to 400000 ...
11.  
12. While j>10 do               //j exists, i doesn't
13.        begin
14.           i := j mod 3;      // i....
15.           littlepiggy(j,i);
16.        end;
17.  
18.  

5. Ada like value strings;

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

1.               RunwayLength : Float := 2_500.0;
2.  

[Martin_fr]

At least 2 (init list) and 4 (non declared local) have been discussed to the full extend before..... IIRC more than once.

[AlanTheBeast]

At least 2 (init list) and 4 (non declared local) have been discussed to the full extend before..... IIRC more than once.

I brought up the non-declared local many years ago and got royally tarred and feathered for it.  Not sure if anyone beat me to it.

init list I saw someone bring up a year or so ago.  Wasn't fresh then IIRC.

[PascalDragon]

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

1. 1. Endcase;          // I resort to     end; {case}

No.

2. VAR init lists:

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

1. VAR
2.      i,j,k: billionbitword = 0;

Was discussed many times already.

3. Non 0 based re-dimension of arrays. 

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

1.       G: array of array of grapefruit;
2. ...
3.      SetLength (G, [1..12],[1..6]);

No.

4. Non-declared local ordinals. Ideally in register.  Only within loop blocks.

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

1. j := BobIQ;                    // j in scope, i does not exist
2. for i := 1 to Q do
3.     begin
4.          SnapSUM (i, j);     // i is an ordinal of the same type as the for statement range.  If Q=Word, i:word;
5.          PorkBelly(i*x);
6.     end;                          // i ceases to exist ...
7.  
8. Repeat
9.      i := 23+j;
10. Until i>400000;            // ceases to exist.  Type has to support the range of j to 400000 ...
11.  
12. While j>10 do               //j exists, i doesn't
13.        begin
14.           i := j mod 3;      // i....
15.           littlepiggy(j,i);
16.        end;
17.  
18.  

No.

5. Ada like value strings;

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

1.               RunwayLength : Float := 2_500.0;
2.  

Already supported in main.

[AlanTheBeast]

5. Ada like value strings;

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

1.               RunwayLength : Float := 2_500.0;
2.  

Already supported in main.

I'll update from 3.2.0 then ... is this Delphi dependent?

[440bx]

2. VAR init lists:

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

1. VAR
2.      i,j,k: billionbitword = 0;

Was discussed many times already.

Just a thought, it would probably no longer be discussed if that feature were included in the compiler.  That would really help prevent future discussions   Plus, I believe I read a while back that a compiler developer had already done about half the work for it.

Actually, a feature I'd really like to see is, some sort of optional directive, a la, "inline" that would tell the compiler to zero out the entire space reserved for local variables, something like "Initlocals" after the procedure/function declaration.

That would save a number of "ZeroMemory(@structure, sizeof(structure))" and would ensure that none are overlooked.  That would be very useful.

[Martin_fr]

Was discussed many times already.

Just a thought, it would probably no longer be discussed if that feature were included in the compiler.  That would really help prevent future discussions

Or the discussion would then be: Just an idea, can this feature be removed...?

That would save a number of "ZeroMemory(@structure, sizeof(structure))" and would ensure that none are overlooked.  That would be very useful.

Well, isn't that what "structure := Default(TStructure);" is for?

Or should I insinuate that you crafted the code with certain intention to portrait the image of complexity in such a way that the lack of necessity for its overly extended syntax may be overlooked by the audience and the subtle hidden implication of a greater need than actually exists will be instilled into the readers mind? SCNR

[440bx]

Was discussed many times already.

Just a thought, it would probably no longer be discussed if that feature were included in the compiler.  That would really help prevent future discussions

Or the discussion would then be: Just an idea, can this feature be removed...?

<chuckle>

Well, isn't that what "structure := Default(TStructure);" is for?

Or should I insinuate that you crafted the code with certain intention to portrait the image of complexity in such a way that the lack of necessity for its overly extended syntax may be overlooked by the audience and the subtle hidden implication of a greater need than actually exists will be instilled into the readers mind? SCNR

You're really inspired today.   

The "structure := default(TStructure);" has a number of problems, among them, the programmer has to remember (and type) that structure is of type TStructure and, are the "default" values always binary zeroes ? or are they different depending on the field type ? and, lastly, it still requires ensuring that every structure has been "defaulted". 

A simple "Initlocals" or "zerolocals" (I'm liking "zerolocals" better now) initializes everything, regardless of type and without requiring the programmer to ensure every structure has been individually initialized.  This is the kind of minutiae compilers should take care of. (simpler than the -gt stuff that is already in FPC)

Something along the lines of "zerolocals" would be great to have.  One directive and done!  I would even like to see it as as default behavior for all functions/procedures based on some "modeswitch" or something similar.

[Martin_fr]

The "structure := default(TStructure);" has a number of problems, among them, the programmer has to remember (and type) that structure is of type TStructure

We are talking about local vars. And only local vars. And about code that initializes them, code that is at the very top of the routine. Code that is immediately below the declaration of the variables.
If the amount of local vars is so big, that you can't see their declaration, then maybe - just maybe - there is a different issue.....
Otherwise, the type-name you need, is right there.

and, are the "default" values always binary zeroes ?

Is all zero always the correct behaviour?

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

1. type
2.   TFoo = (foo1 = 11, foo2 = 21);
3.   TBar = 100..110;
4. var
5.   aFoo: TFoo;
6.   aBar: TBar;

Initializing aFoo/aBar with zero creates an invalid value. And invalid values can lead to unpredictable behaviour. Upgrade your compiler, or change some settings and the behaviour of your app may change unexpectedly.

And if - hypothetically - an option as you advertise should ever come to be, then it should never set invalid values. So it could never be "zero all locals", but if it were to be it could only be "set all locals to default".

and, lastly, it still requires ensuring that every structure has been "defaulted". 

As I said "a greater need than exists". This leaves the possibility of an existing need (Clearly you have this need, and others do not). But there are needs for many a thing. Not all of them are significant enough to warrant a new feature. [1]

Also, the compiler does already provide the tools to "ensure all have been defaulted" (or rather initialized).
If you miss one, you get a compiler hint.


---
[1] This is a general statement. This does not place you request into either group of features. However, my personal opinion (which is of no matter towards any decision that may be made on the topic) is that if there were some feature (related to local initialization) that would bring forward such a warrant, it should not be a compiler directive, or any form were *all* locals would be affected by a single command.

[440bx]

The thing is, if there is some method of telling the compiler to automatically set all the locals to binary zeroes then, when debugging, it becomes trivial to see what variables have been initialized _by the code_ or left uninitialized. 

Anything else, may be inadvertently confused with a valid value but, it was just junk on the stack.

Initializing variables is a good habit and, even if the initialization to zeroes produces invalid values, as your enumeration example showed, at least that's a _predictable_ invalid value instead of whatever junk may have been in the stack which may result in an invalid value or worse, a value that is in the range but not appropriate for the occasion.

[Martin_fr]

The thing is, if there is some method of telling the compiler to automatically set all the locals to binary zeroes then, when debugging, it becomes trivial to see what variables have been initialized _by the code_ or left uninitialized. 

Are you arguing for or against your idea? I mean "when debugging" the existing -gt does a marvellous job. Seeing $AAAAAAAA or $55555555 or IIRC $DEADBEEF => those make it more than trivial to spot if something hasn't been initialized.
Yet the compiler setting values to zero, does not help spotting this in the compiler, since code could very easily initialize to 0. And that would be indistinguishable from the compiler set value.

Initializing variables is a good habit

Agreed. But we do have "Default(...)". And we do have the compiler hint.

[440bx]

Are you arguing for or against your idea? I mean "when debugging" the existing -gt does a marvellous job. Seeing $AAAAAAAA or $55555555 or IIRC $DEADBEEF => those make it more than trivial to spot if something hasn't been initialized.
Yet the compiler setting values to zero, does not help spotting this in the compiler, since code could very easily initialize to 0. And that would be indistinguishable from the compiler set value.

I am arguing for my idea.  I _do not_ want any $AAA..or $555... or any other junk.  In the majority of cases, binary zeroes is the natural initial value and if a variable requires a different value then it can be initialized with that value.

For instance,

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

1. var
2.   MyVariable : integer = 5;

the compiler would initialize it to 5 _after_ the code that initializes to zeroes has executed.

This way, things keep working just the way they work now but, all "un-initialized" variables have the value zero instead of whatever junk was on the stack.

[Martin_fr]

All of the below is only about your "when debugging...." case. Nothing else.

I am arguing for my idea.  I _do not_ want any $AAA..or $555... or any other junk.

....

I have the feeling you are switching between 2 points here.

That very last post of yours reads as if you argue for the zero-ing a general tool. I.e. something that makes it into production code. (i.e. not specially for testing, but part of the actual functionality of that code).
If so => That is not what I had replied to in my post

In my post before, I was explicitly answering to you saying:

when debugging, it becomes trivial to see what variables have been initialized _by the code_ or left uninitialized

And really when debugging the -gt AAAA/5555/DEADBEAF are easier to spot, because they are distinguishable from a zero that was set by user-code.
Those values may not be good for production code. But they are for debugging.

So let me ask: Do you believe finding an uninitialized (i.e. not initialized by code) value by watching values in the debugger is easier if that value is 0?

As "for trash on the stack": zero is as likely as every other value.
In fact it may be likelier... Zero could be on the stack from a previous value on that location. (as could many other values). But compared to zero, how often does data in your apps take the value of "DEADBEAF" ?


Please explain to me, when debugging this code

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

1. procedure foo; zero_all_locals;
2. var a: integer;
3. begin
4.   a := 0;
5.   bar(a);
6.  

On line 5: How do you know, if a=0 means the value was or was not initialized by user code?

And yes, same problem with -gttt, if your code goes "a := $DEADBEAF;". Only what happens more often in code? "a := 0;" or "a:=$DEADBEAF;" ?

[440bx]

I have the feeling you are switching between 2 points here.

No, I'm just stating that there is more than 1 reason why this would be a nice feature to have.

That very last post of yours reads as if you argue for the zero-ing a general tool. I.e. something that makes it into production code. (i.e. not specially for testing, but part of the actual functionality of that code).

Production code often has to be debugged too.

And really when debugging the -gt AAAA/5555/DEADBEAF are easier to spot, because they are distinguishable from a zero that was set by user-code.

That stuff is noise.  As I stated before, zeroes is the _natural_ initial value and it is the "clean" value.  I don't want any $AAA or whatever other junk.

As "for trash on the stack": zero is as likely as every other value.

I've looked at values on the stack often enough to know that zero is not nearly as common as other junk such as old return addresses, old stack pointers and, stale values from other functions/procedures.

In fact it may be likelier... Zero could be on the stack from a previous value on that location. (as could many other values). But compared to zero, how often does data in your apps take the value of "DEADBEAF" ?

The problem is that often the value is displayed in decimal instead of hex and, -gt doesn't put DEADBEEF and, no value is as commonly useful as zero.  Zero is the natural initialization value.  That's why it would be very useful to have the option of telling the compiler to set all locals to zeroes.

On line 5: How do you know, if a=0 means the value was or was not initialized by user code?

There cannot be certainty but, the probability is high that it was set by user code and, the probability is also reasonably high that it should eventually be set to a different value.

And yes, same problem with -gttt, if your code goes "a := $DEADBEAF;". Only what happens more often in code? "a := 0;" or "a:=$DEADBEAF;" ?

You got something against binary zeroes ?  They are much more often useful than $DEADBEEF.

[Martin_fr]

I'm just stating that there is more than 1 reason

I did at no point challenge that. (i.e. that you have more than one reason)

But I though I made it very clear, that I had responded to ONE (and just that one) reason, that you had given at one point.
And any response to (or looking at) my response that ignorers this context, will of course not find any sense in my response.

So kindly in response to this post of mine => stick to that one reason (which after all was one that you gave)

Now I am looking at your latest response. And I try to read it as being in the context (and only in the context) that I had clearly identified as being the one in which my statements have to be read.

If I prefix any of your sentences with "When I debug my app, and I want to see if my code initialized the value, then ...."

And the only sentences in your reply that indeed makes sense are
1)

The problem is that often the value is displayed in decimal instead of hex

Maybe the debugger should detect those values, and default to show them in hex....

2)

On line 5: How do you know, if a=0 means the value was or was not initialized by user code?

There cannot be certainty but, the probability is high that it was set by user code and, the probability is also reasonably high that it should eventually be set to a different value.

On topic, but while being on topic, it argues against your point.

If (for the value zero): "the probability is high that it was set by user code" => then how can the value zero (also set by the compiler) be helpful to find cases where it was not set by user code. You just said, that probability of the opposite was high.