[feature] Mandatory end designator

[joaopsazevedo]

Summary

This RFC proposes to standardize and mandate the use of the designator name in the end statement for all block-like constructs.

Motivation

The primary motivation for this change is to improve language consistency and code readability in long or nested code blocks, by explicitly linking the end of a block to its beginning.

Caveats and alternatives

Backwards incompatible. Alternatively, only deprecate end record; in favor of an optional end <record_name>;.

[clairedross]

I think that, if we want to introduce a backward-incompatible change, we need a very good motivation for it. Here it looks a bit cosmetic to me...

[sttaft]

This would make for an excellent "Restriction" which projects could impose on themselves. E.g.:

pragma Restrictions (Mandatory_End_Designators);

As a language change, it seems very incompatible for what is essentially a style restriction. Remember there are more than a billion lines of Ada code that periodically will want to be recompiled with an up-to-date compiler.

Note that Ada 2022 includes the permission to add an end designator after "end record":

https://ada-rapporteur-group.github.io/ARM/Ada_202Y/AA-3-8.html#p3

We explicitly considered making the word "record" optional, with appropriate rationale provided in the AI that introduced this new syntax:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0213-1.txt?rev=Top1.7

We concluded that having that sort of option is not a feature, as then a project would just want to mandate a particular choice. End designators were already optional in most cases, so it made sense to follow that model here as well. Including the nature of the construct as part of the "end" matches the choice for "end loop ", and so there was precedent to include the kind of construct in the ending pattern, and it would mean existing Ada code with records would not suddenly appear inconsistent.

[ebotcazou]

I agree that this is the kind of gratuitous incompatibilities that should be avoided as much as possible.

[tonunaks]

I must admit that we have a hole in our process. Here, we were concentrating on the discussions at the meetings and the comments on the pull request. The ones on issue were overlooked. Claire, Tuck, I apologize for that! You were not ignored on purpose, and the question of backward compatibility was considered in the meetings. Going ahead, I'll make sure that those issues are assigned and remind the team to respond to the comments.

Regarding the change, it would apply only to Flare mode, which is accepted as non-backward-compatible. Does that resolve your concern?

[sttaft]

Regarding the change, it would apply only to Flare mode, which is accepted as non-backward-compatible. Does that resolve your concern?

Not really. It seems you expect folks to have a mixture of Flare and standard Ada. I can see Flare providing some additional capabilities, but having contradictory rules in the two sub-languages seems destined to confuse people, especially folks reviewing code or trying to understand it. This one could also be easily handled with a Restriction rather than a rule (except for the "end record" suggestion which will definitely cause confusion), which would allow it to apply to all code, not just Flare, which would make things more reasonable from a human reviewer point of view.

The more egregious incompatibility in my view is with the interpretation of "and" and "or" as being short circuit. Changing those to mean short-circuit doesn't really work with the equivalence of operator evaluation to function calls, and the inevitable surprises in terms of number of paths to test from an MC/DC point of view.

[ebotcazou]

Maybe more egregious, but certainly not more gratuitous than this one!

[QuentinOchem]

Some more insights on this one - indeed - we also had uncertainties about mandating the end designator on this proposal and decided against it - it has been updated in the RFC. The one backward incompatible change is the replacement of end record; to end []; which is only going to be enforced in some kind of pedantic mode.