FPC Feature request/suggestion

[ASBzone]

On the other hand

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

1. var
2.   a, b, c, d: integer = 0;

Still leaves it open, if that same value is coincident or not.
"0" could be an initial count, or a special marker, or a empty bitmask, or ..... And it could be a different one for each var.

I accept that you did not post the above to take sides in the argument/discussion, but I have to ask the following:

Is a proposed feature deemed undesirable (at least in part) because it almost definitely leads to sloppy or dangerous development?  Or simply because it *could* lead to such?

Because sometimes it seems like many of the arguments I see follow the same pattern.

It's not every feature that I see discussed here that I would personally use, but I have absolutely thought about this specific one in the past few weeks at least a half-dozen times.   I can see where such a feature might be problematic for parameters of a function or procedure, but in terms of general variable declarations in the main body or within functions/procedures, it seems to be a natural extension of what is currently allowed.

If I can say the following:

VarA, VarB, VarC: integer; 

...even if VarA, VarB and VarC are totally unrelated to each other within the application, it  adds no complexity or risk of error if I also say

VarA, VarB, VarC: integer = 0; 

...if they all need to start out as zero.   


Can errors be made in that way?  Sure.   But not any more than any other way.

I tend to group many variables together in the declaration, although sometimes (many times) I will tend to do the following:

SomeVarA, SomeVarB, SomeVarC: integer;
OtherVarA, OtherVarB, OtherVarC: integer;

... which is essentially a grouping of the integers into those that are more related to one another in the application.

So, if I could, I would more likely do:

SomeVarA, SomeVarB, SomeVarC: integer = 0;
OtherVarA, OtherVarB, OtherVarC: integer = 0;

...than:

SomeVarA, SomeVarB, SomeVarC,
OtherVarA, OtherVarB, OtherVarC: integer = 0;

...even if the language permitted it.  For my own sanity.


But I have been finding it increasingly beneficial to get that assignment into a collective place, and if we are going to argue error reduction, I find it much easier to add one more variable at a later point (SomeVarD) and have it automatically initialized, than remembering to both add it and its initial assignment in another place.

Are the errors I'm speaking of here catastrophic? By no means.    I'm dealing with hundreds or thousands of lines of code, and compile times are blisteringly fast, so that I get instant feedback on the errors.  I'm losing seconds a day of my life, at max (on days when I'm even programming).

But, my life rule has been, whenever a certain problem presents itself to my mind more than 3 or 4 times in a short period of time, it's time to automate it.   By that metric, being able to do the assignments in group (I won't say "bulk") would maintain a useful balance between wordiness and conciseness.

I cannot think of any definitive problem that is causes, that is worse than the situations it addresses, and it's not really a structural change for the language -- the underpinnings for the functionality are essentially there already.

I don't see this situation as one that would induce programmer error.  Like anything else, it can be abused, but that is a different problem, not likely solveable with technology.

[ASBzone]

The programmer is _entitled_ to expect the compiler to produce good code.  That one syntactic structure leads to better optimizations than another one is simply an acknowledgement of a deficiency in the compiler.

I see your point.

[Zoran]

So, PascalDragon, I think your argument is weak.
I do not think you should spend much of your time on this, when you have more important things to do, but if it is not hard to implement, please do. I just don't agree with the reason you gave.

You can think of my argument as weak as you want, I'll not implement this.

Okay.
I didn't mean my opinion counts much (and I really don't think that it should count much). I just wanted to say what I think about it nevertheless.
Plus it is not important to me. Unlike the intrinsic you implemented some time ago, which I would really use a lot, but it was finally rejected.

[440bx]

You can think of my argument as weak as you want, I'll not implement this.

The problem isn't that someone, justifiably, considers your argument weak, the real problem is that you _know_ it is weak and because of that you cannot offer a solid, logical and sensible reason for not implementing it. 

@ASBZone,

Just to add to the considerations you put forward. 

Not having variable group initialization does lead to more programming errors.  Specifically, it is quite common to have a bug due to an uninitialized variable.  If variable groups could be initialized then simply adding them to that group initializes the variable.  Having a separate declaration opens the door to forgetting initializing it in the declaration or later in code.

There is no downside to enabling variable group initialization except, possibly, that some _deficient_ code in current compiler may have to be reworked to be made the way it should have been all along.

[marcov]

The programmer is _entitled_ to expect the compiler to produce good code. 

ROTFL.

[440bx]

ROTFL.

I'm pleased that amused you but, does that mean you'd like the compiler to produce lousy code, code that is below expectations ?... is that really what you look for in a compiler ?

It's no wonder C, in spite of being a rather sorry language, is still the choice among programmers who want fine control over what they produce.

[Martin_fr]

I'll give you credit for one thing: you did provide an excellent example of a _very_ poor argument.  I'll add it to PascalDragon's which was in the same class.

Gets a bit complex here.

1) There may be a partial misunderstanding between what I read from your text, and what you may have tried to express.
Based on that, naturally the quality of my statement will be poor, if measured against your intended expressed content. After all my statement was not made to be compared with that.

2a) I should not have dismissed your text as argument (for how I read it, see below), but rather as "argument pro the initial feature request"
2b) When referring to my argument it should be clear that my argument is about the relation between your argument (as understood by me) and the initial feature.
  I stress out again, that I do not / did not argue against the original feature request (nor do I argue for it)

But, it isn't a simple matter of more typing.  I am not against lots of typing, I like COBOL for instance and, nothing beats COBOL when it comes to typing a lot.

Sorry, entirely misunderstood you on that part.

The problem with the construction above, is all the duplication.  Duplication is very undesirable because every duplicate has to be verified for consistency instead of having a single value to verify.

Absolutely +1

But that was not part of the conversation. This is an entirely new argument.

I replied to https://forum.lazarus.freepascal.org/index.php/topic,49505.msg359465.html#msg359465 (2nd paragraph, see end of this post)
And in that text of yours I can not find any reference to reducing duplication.

So again: Not part of the issue that I was talking about.  Not part of the text I replied too.

Off topic: I do however grant you: De-duplication is a good argument for the initial feature request.

There is nothing preventing initializing one of the variables with OTHER_INIT_VAL instead of NAMED_INIT_VAL, while it is very _unlikely_ that an entire group of variables is going to be initialized to the wrong value.

And if you have 2 groups of variables, both initialized with 0, nothing stops the programmer from putting ONE variable into the wrong group

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

1. var
2.   a, b, d: integer = 0; // c should be in here, but its easy to put it into the wrong line. Even more easy if code completion is used, and the " = 0" added later.
3.   m, c, n, o, p: integer = 0;

In terms of grouping mistakes, this has similar potential of errors.

About the argument to which you replied.
Which is my argument at https://forum.lazarus.freepascal.org/index.php/topic,49505.msg359472.html#msg359472

Which was in reply to:

Honestly, it is a bit silly to require the programmer to have individual declarations for every variable when each variable is supposed to have the same initial value.    As should be obvious, the separate declarations give no indication that the group of variables _should_ have the same initial value.

I underlined the part to which I responded.

You talk about variable belonging to a group, and more that the group intentionally has one initial value that applies to all its members.

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

1. var   a, b, c, m, n, o: integer = 0;

Does not convey this intention.

The variable could well be together in that line because some author actually wanted to save on typing.

Your intention could be reached by writing

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

1. const
2.   FOOVAL = 0;
3.   BARVAL = 0;
4. var  
5.   a, b, c: integer = FOOVAL;
6.   m,
7.   n,
8.   o: integer = BARVAL;

However, this is the point were my argument stands.

Within the current language (that does not have the above shorthand, and that does require the duplication) each variable needs to be initialized on its own.

Using a constant, it is possible to express the same intend of one shared initial value. (The example that I posted)

De-duplication (albeit a very good point) was not in your original text. It was not part of me responding to your text.


De-duplication <> expressed shared initial value
Those two are separate issues.

You may say (and I would believe you that it may apply to you) that once "expressed shared initial value" is reached (e.g. by using a constant) adding de-duplication on top makes it easier to see the "expressed shared initial value".
I would answer to that, that the added readability may (at least to a big part) derive from the source formatting that changed with the syntax. And read-able source formatting can be reached with existing syntax to.
There may remain a real tiny amount of higher recognition of "expressed shared initial value" due to readability changes caused by de-duplicaten.

Note the last sentence does not downplay the effect of readability offered by de-duplication. It merely makes a statement to which part this read-ability affects the "expressed shared initial value" compared to other form of source formatting that could underline the "expressed shared initial value".
I already expressed that I share your view on de-duplication being a good thing.

[marcov]

ROTFL.

I'm pleased that amused you but, does that mean you'd like the compiler to produce lousy code, code that is below expectations ?... is that really what you look for in a compiler ?

No, the amusing part is about the sense of entitlement, and the assumption the average user has any idea at all about what is important in a compiler.

It's no wonder C, in spite of being a rather sorry language, is still the choice among programmers who want fine control over what they produce.

No doubt about it. But it comes at a horrible efficiency price that is usually not worth it.

[Martin_fr]

I accept that you did not post the above to take sides in the argument/discussion, but I have to ask the following:

Is a proposed feature deemed undesirable (at least in part) because it almost definitely leads to sloppy or dangerous development?  Or simply because it *could* lead to such?

I am not on the board of those who take the decision.

I personally do not have any problems with it. But (until before the mention of de-duplication) did not see much reason for it. (Search the "syntactical sugar" statements, made by various other peoples in other threads on this board).

I do not even use this for single local vars, like "var local_foo =1;". Not because it is a problem, but because I am not used to it.
If I ever were to start using the existing syntax, and if ever this became a feature for multi-var, I could even see myself use it.
But then: That is no argument for either side. Just a subjective statement.

Because sometimes it seems like many of the arguments I see follow the same pattern.

As I said, this is not part of my jurisdiction.

I am part of the Lazarus Team, not the FPC team.

While pro and cons are important, they are not the only part of the decision. At the end, additions to the compiler must be maintained over time.
While someone else may volunteer to write the code, members of the team often do not know that person well enough to trust/assume that this person will be around over the years to come, to deal with the added maintenance. Therefore the team has to see enough value in the feature to be willing to take the added maintenance. This part is a subjective decision by the team.
We can make guesses about how much that maintenance may accumulate too. But still in the end it is the subjective guess of the team.

And there is the standing on "syntactic sugar" that was expressed by members of the team in the past. (No argument of mine, just an observation)
So you either have to show it is not syntactic sugar, or hope to get an exception from the rule....
I do not know how strict that rule is applied, nor if this feature is currently seen to fall under it.

Above is my understanding of previous / other discussions on similar topics. No idea if I got all of them right.


Now for those who want the feature, the next question after this

You can think of my argument as weak as you want, I'll not implement this.

should be, if he would object to it being added to the compiler, if any other member of the fpc core team would implement it (or apply a well written patch).

Every person in the project can
- decide what they are willing to add themself (as long as not objected by the team)
- ask the team to consider objection / or let things happen

[440bx]

Sorry, entirely misunderstood you on that part.

No problem.  These things happen.

But that was not part of the conversation. This is an entirely new argument.

< out of sequence but relevant to the response >

De-duplication (albeit a very good point) was not in your original text. It was not part of me responding to your text.

There is one thing I have to admit here.  I consider this suggestion a no-brainer and, because of that, I didn't think it would be necessary to go into all the details that make it a good construction.  I'm guilty of not providing, upfront, details of the ways the feature is desirable.

And if you have 2 groups of variables, both initialized with 0, nothing stops the programmer from putting ONE variable into the wrong group

I don't claim the feature will make some errors impossible.  I claim that it makes some errors less likely.  Particularly, that a variable may be inadvertently left UN-initialized. 

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

1. var   a, b, c, m, n, o: integer = 0;

Does not convey this intention.

The variable could well be together in that line because some author actually wanted to save on typing.

No feature can force a programmer to write good code but, a feature can help a programmer who wants to write good code accomplish that goal.     If a programmer doesn't care about conveying his intentions clearly then, the problem is not in the compiler and its features or lack thereof.

Honestly, I see the suggestion as just polish for the compiler.  The compiler allows initializing one variable. It really doesn't follow that it doesn't allow initializing more than one variable.  It would be like the compiler forcing a separate declaration for variables of the same type.  Same data type, same initial value... they just belong together.

No, the amusing part is about the sense of entitlement, and the assumption the average user has any idea at all about what is important in a compiler.

Honestly, I completely believe that a programmer is _entitled_ to expect a compiler that produces reasonably decent code just like, if someone buys a brand new car, I believe they are entitled to a car that transports them from A to B at a reasonable speed (and doesn't require pushing the car to get to B.)  On second, third and nth thought, I believe that entitlement is fully justified.

But it comes at a horrible efficiency price that is usually not worth it.

I have to agree.  C puts programmer productivity in the toilet.

[MarkMLl]

On the other hand

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

1. var
2.   a, b, c, d: integer = 0;

Still leaves it open, if that same value is coincident or not.
"0" could be an initial count, or a special marker, or a empty bitmask, or ..... And it could be a different one for each var.

In which case they should be different types, hence- of course- initialised separately as a result.

/Honestly/, Martin: a (signed) integer as a count? or as a bitmask?

MarkMLl

[Martin_fr]

I consider this suggestion a no-brainer and, because of that, I didn't think it would be necessary to go into all the details that make it a good construction.  I'm guilty of not providing, upfront, details of the ways the feature is desirable.

Well, as I said I am not part of the decision makers.

But if my guesses in my above post are halfway right, maybe time to find out were the discussion stands.
- Are there team members who object the feature as such / i.e., object to any other team member adapting the feature.

If so, then you have to argue for the feature.

If otherwise, you have to find a team member willing to "sponsor" the feature.
That is, someone to either implement it or apply a patch; someone who will henceforth take responsibility for the added code.

[440bx]

If so, then you have to argue for the feature.

I'm more than willing to analyze and dissect a feature - this one or another one - with any one of the team members but, it has to be a constructive process.  I hate to say this but, I will say it, the one reason I've read so far from one of the team members, simply leaves a bad impression reflected in an unwillingness to see (or even acknowledge) any of the ways the feature is desirable.   When I see things like that, I simply remove myself from the topic because, it is clear that any effort I put in, is a waste.

If otherwise, you have to find a team member willing to "sponsor" the feature.

I offered it as much as a suggestion as something I'd like to have in the compiler.  The suggestion wasn't liked... no problem.  I'll initialize variables one by one, just like I've been doing.

All that said, thank you, I appreciate your suggesting ways it might end up implemented.  I'm choosing to leave it alone.

[flowCRANE]

If otherwise, you have to find a team member willing to "sponsor" the feature.
That is, someone to either implement it or apply a patch; someone who will henceforth take responsibility for the added code.

So, in short, find a traitor in the team who will defy the other members and implement the feature, for which he will be condemned for the rest of his life. Forget about it but, good luck. The team should be unanimous so that there are no unnecessary misunderstandings and cooperate with users, because software is created for them.

Stupid ideas should be rejected, but if you get a good idea that a large group of users agree with, that's another matter. And if you don't want to, you don't have to use the new feature. It's so simple.

[Martin_fr]

If otherwise, you have to find a team member willing to "sponsor" the feature.

So, in short, find a traitor in the team who will defy the other members and implement the feature

Did you read my post? Apparently not.