Proposal: unions as a new type and arrays with number of elements

[marcov]

Perhaps it would be a compromise to keep unions part of records instead of making a complete new type. Instead of the proposed
 type TFoo = union

Already multiple times, new syntax has been ruled out.  (see e.g. https://forum.lazarus.freepascal.org/index.php/topic,63226.msg479007.html#msg479007 and earlier posts by me)

IF (and that is a big  IF) something changes with variant records, it is the appending fields after case ... of variant parts.

Also there are other parts needed for allowing somewhat 1:1 mapping for APIs:
- allowing the same nesting setup as C unions do, including fields after unions and anonymous usage.
- all packing and alignment considerations including bitwise and enums.

[kupferstecher]

It could, however, be fixed in this way (requiring an additional end;) by adding a modeswitch for Record Union or some such.

Yes, but I really don't like mode switches and only use them if there is no other way. Perhaps its only me, probably not.

This would allow backwards compatibility, and also allow a way forward.   
Then, in FPC 5.0, the old way could be deprecated. 

The way forward really seems to be blocked by backward compatibility. But sure, it is very important.

Already multiple times, new syntax has been ruled out.

I know. Still the 'case .. of' -syntax is one of the rare WTF-moments in the Pascal language. Alongside with the writable typed constants. So I still hope they will be fixed within the next 30 years

[PascalDragon]

It could, however, be fixed in this way (requiring an additional end;) by adding a modeswitch for Record Union or some such.

Yes, but I really don't like mode switches and only use them if there is no other way. Perhaps its only me, probably not.

Syntax extensions must be done using mode switches, because the parser needs to disallow them for certain modes by default (e.g. ISO, Delphi, TP).

Still the 'case .. of' -syntax is one of the rare WTF-moments in the Pascal language.

What do you mean?

Alongside with the writable typed constants.

These are required for TP and Delphi compatibility.

So I still hope they will be fixed within the next 30 years

Use {$J-} and the constants aren't writable. Done.

[kupferstecher]

Yes, but I really don't like mode switches and only use them if there is no other way. Perhaps its only me, probably not.

Syntax extensions must be done using mode switches, because the parser needs to disallow them for certain modes by default (e.g. ISO, Delphi, TP).

I didn't mean the dialects or how things are internally managed. But if there is a feature that I have to "release" by a modeswitch before usage, then I try to avoid it. I.e. I try to stick to the plain official syntax of the dialect (objpas).

Still the 'case .. of' -syntax is one of the rare WTF-moments in the Pascal language.

What do you mean?

A bit exaggerated perhaps. But I think that the "case .. of" syntax is counter intuitive. That a typed constant is a variable and not a constant is counter intuitive. And using writable typed constants as static variables for procedures is also counter intuitive. For a verbose self speaking language that Pascal is, it just doesn't fit. I'd rather expect such constructs in c 

Alongside with the writable typed constants.

These are required for TP and Delphi compatibility.

I think its a tragedy that the backward and Delphi compatibility prevents the language from getting cleaned up, rectified. That's what I meant, even in 30 years these unpleasant details won't be fixed. Not because nobody is willing to do the work, but because it would break compatibility. Yes, I understand, that old syntax couldn't be removed and having parallel syntax also brings trouble. Still a tragedy..

[ASBzone]

I didn't mean the dialects or how things are internally managed. But if there is a feature that I have to "release" by a modeswitch before usage, then I try to avoid it. I.e. I try to stick to the plain official syntax of the dialect (objpas).

That statement seems amazingly inconsistent with this entire thread.

You desire or support a feature (syntax change) proposal that would break backwards compatibility, and it is not the official syntax of any Pascal dialect.

But you would prefer that it not come via a mode switch, even though that is shown to be essential so that the feature doesn't violate other official dialects which don't/won't support it, and because this would maintain backwards compatibility for everyone else who already has code in place leveraging the existing syntax for variant records.

I don't know what to tell you my friend.  It surely seems like your requirements are mutually exclusive.

[kupferstecher]

Not sure if you understood me correctly.

Normally I use objpas, so yes, this is activated. If there were a new dialect century21pascal or whatever, that combines the discussed cleanups, that would be nice for me. But if I have to activate a single feature like {$modeswitch advancedrecords}, then I most probably won't use it. For me this has to do with clean code.

You desire or support a feature (syntax change) proposal that would break backwards compatibility,

No, thats why I said its not possible to change the 'case .. of' syntax without changing the keyword. Just adding an explicit 'end;' after 'case .. of' would break compatibility. And keeping the current syntax as standard and just adding a mode switch {$modeswitch UseEndInVariantRecord} for the situations an other field after the variant part is needed... that's the thing that I oppose.
Having a new dialect would then be the moment to drop the old syntax. But yeah, its not coming 

and it is not the official syntax of any Pascal dialect.

That is true and is a valid point. But I only see freepascal and Delphi as institutions that could improve the syntax and define something like a future syntax.

[Warfley]

I haven't followed all of the discussion, but here are my two cents anyway.

Variant records are more powerful than C unions, you can do everything with variant records that you can do with C unions and more, because variant record fields are on the same level as the non variant fields:

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

1. TTest = record
2.   A: Integer;
3. case boolean of
4.   True: (BA: Integer);
5.   False: (BB: Double);
6. End;
7.  
8. Rec.A := 42;
9. Rec.BB:= 3.14;

In C unions you need an intermediary:

Code: C  [Select][+][-]

1. struct {
2.   int A;
3.   union {
4.     int A;
5.     double B;
6.   } B;
7. } Test;
8.  
9. Test.A =42;
10. Test.B.B = 3.14

Which you can also do with variant records:

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

1. type
2.   TTest = record
3.     A: Integer;
4.     B: record
5.       case Boolean of
6.       True: (A: Integer);
7.       False: (B: Integer);
8.     end;
9.     C: Integer;
10.   end;

So variant records are strictly more powerful than C unions, as they can do everything C unions can and more

And C developers regularly use hacks to try to emulate the pascal behavior, e.g. this is the real current production code used in GLibC

Code: C  [Select][+][-]

1. struct in6_addr
2.   {
3.     union
4.       {
5.         uint8_t __u6_addr8[16];
6.         uint16_t __u6_addr16[8];
7.         uint32_t __u6_addr32[4];
8.       } __in6_u;
9. #define s6_addr                 __in6_u.__u6_addr8
10. #ifdef __USE_MISC
11. # define s6_addr16              __in6_u.__u6_addr16
12. # define s6_addr32              __in6_u.__u6_addr32
13. #endif
14.   };

They are using defines for hiding the indirection over the union and to allow to directly use addr.s6_addr, which will be replaced by the preprocessor for addr.__in6_u.__u6_addr8, because they don't have what pascal provides by default.

Why would anyone want a downgrade?

There are a few "problems" I have with variant records. First when using a field for the case, e.g. a boolean value to switch over, there is no way to ensure that you can only access the field when the switch is actually set to the correct value for that field, this would be incredibly useful if there was a way to enable both static analysis checks, as well as runtime checks to ensure this.
Second there are currently no ways to use managed types inside them, when there was a way to ensure that a switch is used correctly, this switch could be used to call the correct initializers and finalizes. This would make variant records so much more useful.
Then the fact that you can only have common fields before the case, and only one case per record is a bit annoying as you have to resort to C style indirection as shown above.
Lastly a shorter syntax, so you don't have to count all your options through would be great, right now when having 5 options you need to prefix them with 1:, 2:, etc. Also the bracketing is kinda weird (but allows for multiple values per field which C style unions don't).

[PascalDragon]

Yes, but I really don't like mode switches and only use them if there is no other way. Perhaps its only me, probably not.

Syntax extensions must be done using mode switches, because the parser needs to disallow them for certain modes by default (e.g. ISO, Delphi, TP).

I didn't mean the dialects or how things are internally managed. But if there is a feature that I have to "release" by a modeswitch before usage, then I try to avoid it. I.e. I try to stick to the plain official syntax of the dialect (objpas).

Then you won't benefit from many newer language features cause they are all backed by modeswitches so that they can be optionally be used in modes that normally don't support them.

Still the 'case .. of' -syntax is one of the rare WTF-moments in the Pascal language.

What do you mean?

A bit exaggerated perhaps. But I think that the "case .. of" syntax is counter intuitive. That a typed constant is a variable and not a constant is counter intuitive. And using writable typed constants as static variables for procedures is also counter intuitive. For a verbose self speaking language that Pascal is, it just doesn't fit. I'd rather expect such constructs in c 

Ah, you were still talking about the variant part in records. I thought it had something to do with case-statements. 😅

[runewalsh]

In C unions you need an intermediary:

Code: C  [Select][+][-]

1. struct {
2.   int A;
3.   union {
4.     int A;
5.     double B;
6.   } B;
7. } Test;
8.  
9. Test.A =42;
10. Test.B.B = 3.14

You don’t, there are official anonymous unions since C11 that were a GNU C extension long before that, in conjunction with anonymous structs they work just like Pascal record variant parts, but can also be non-final. I miss such a possibility at times.

[marcov]

I think its a tragedy that the backward and Delphi compatibility prevents the language from getting cleaned up,

IMHO it is the actual strength of Lazarus and Delphi. Just look at the Perl or Python major version transitions that took a decade for languages that have much more development power and sponsoring than Pascal.

Language beautification is horribly subjective, and doesn't serve any real purpose and thus rarely yields any results. Of course the tired old "new people will come in droves" argument will be uttered again, but will have the same results as the times before: none, while existing members get frustrated and go away.

[marcov]

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

1. type
2.   TTest = record
3.     A: Integer;
4.     B: record
5.       case Boolean of
6.       True: (A: Integer);
7.       False: (B: Integer);
8.     end;
9.     C: Integer;
10.   end;

The problem is that if you want "B" anonymous you have to fold C into one of the branches of false or true. That is the fold trick around Pascal's case of limitations.

However this makes automated or semi automated conversion somewhat difficult, and possibly also has alignment issues. (e.g. what if B.A is some vector type)

[Bad Sector]

IMHO it is the actual strength of Lazarus and Delphi. Just look at the Perl or Python major version transitions that took a decade for languages that have much more development power and sponsoring than Pascal.

Indeed, Free Pascal has a ton of warts (e.g. there are three compound types - record, object, class - and while all three have common features, none of them has all the features, like e.g. no management operators in object, no inheritance in record, no stack allocation or embedded use in class) but one of the main reasons i keep using it is that the code i wrote years ago still works (though another very important reason is Lazarus - there are other languages that are backwards compatible, like -say- C and C++, but none have something like Lazarus and LCL).

Also FWIW while Python was a disaster, Perl decided to roll back on that and make the incompatible "Perl 6" a different language (Raku) while adopting a Free Pascal-like approach to introducing new functionality without breaking backwards compatibility via something similar to modeswitches.