[fpc-pascal] Feature announcement: Dynamic array extensions
pascaldragon at googlemail.com
Mon May 21 00:52:37 CEST 2018
Maciej Izak <hnb.code at gmail.com> schrieb am So., 20. Mai 2018, 23:32:
> 2018-05-20 22:50 GMT+02:00 Sven Barth via fpc-pascal <
> fpc-pascal at lists.freepascal.org>:
>> I prohibited it because Delphi does not support it correctly and I don't
>> know whether they'd use the usual "(...)"-syntax for the static arrays or
>> switch to the dynamic array one. To avoid potential backwards compatibility
>> problems I decided to simply disallow it.
> I do not buy this ;) no one knows what they will use (if ever), but still
> I see no real reason for blocking this. Following yours logic any of
> management operators should be also prohibited in Delphi mode because some
> similar feature for nullable types is planned for Delphi (but no one knows
> the final form of their Initialize/Finalize equivalent). Code in r39045 is
> IMO too strict.
The thing is that I can easily imagine the Delphi devs to be so stoned to
use the "[...]" for static arrays inside dynamic arrays as well which could
lead to constructs like the following because they forget that dynamic
arrays could be part of static arrays as well:
=== code begin ===
v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5,
6]], , [[7, 8, 9]]);
=== code end ===
Yes, I have absolutely no confidence in the Delphi developers.
>> I had not tested that one. In consequence that should indeed be
>> disallowed as well. Though here the syntax probably wouldn't provide
>> problems in the future.
> and the same sentence is true for the syntax for static array constants
> inside dynamic array constants, the more Delphied syntax for arrays
> probably wouldn't provide problems in the future too :)
> If you like very strict approach and you want to make our life simpler
> probably you should implement some "modeswitch" for allowing both examples
> (example with records and arrays).
I don't want to use a modeswitch for every tiny little bit of feature. What
we could do however would be a modeswitch for a strict Delphi mode that
prohibits extensions and code that does not work in Delphi (like global
operators and global generic functions). This could be used for code that
is shared with Delphi to avoid potentially breaking compilability with
Delphi if one is mainly using FPC for testing.
> btw. the problem for different syntax between Delphi and ObjFpc is still
> valid. I don't see any real gain for different syntax. It was consulted
> with community or this is just individual decision? (and here sorry if I
> overlooked something)
The gain is consistency with static array constants. You don't need to care
about whether it's a dynamic array or a static one, you simply use the same
Also what do you care about mode ObjFPC anyway? One purpose of the mode
*is* that it can go a different route than those modes that copy existing
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal