[fpc-pascal] Illogical automatic dereferencing

[Florian Klaempfl]

Jürgen Hestermann schrieb:
>>>>> No, it happens with static arrays,  if you set pia := @ia, ia[x] and
>>>>> pia[x] will give you the same result (in delphi mode, at least).
>>>> It's simply more readable and a shortcut.
>>> It's definitely the opposite: It is *less* readable 
>> This is your opinion :) To my experience faking arrays with dyn. size by
>> using array declarations with infinite size (else you get in trouble
>> with range checking) are much more error prone and unreadable than using
>> pointers with an implicit dereference operator as arrays. As soon as you
>> start using them like normal arrays (new, high, sizeof, passing them to
>> open array parameters, no range checking) you get burned as well, even
>> not taking care the extra declarations you need.
> 
> What has the one thing to do with the other? 

I'am not talking not about object pascal dyn. arrays (OP dyn. arrays are
much more, see below) but the array<->pointer equivalence as it has C as
well. As far as I can see, you suggest to declare

PChar = ^array[0..maxint] of Char;

? But be careful,
move(p1,p2,sizeof(PChar));
doesn't work as expect either.

If you don't agree, how would you like to declare pchar?

> It would have been easy to
> introduce dynamic arrays without hiding away its nature from the user.

What's there use then if the user has to do everything by hand? Dyn.
arrays are more than just an automatic dereference, they involve ref.
counting, automatic destruction if needed, dynamic range checking etc.

> 
>> E.g. ansi- and widestrings or classes use implicit dereferencing as well
>> and they proved to work very well. If someone uses low level operations
>> like Move he should know what he does.
> 
> That's just the point: Most users are left unclear about the nature of

... and this is good. The alternatives are that the user builds his
processor and assembler himself or he uses something like brainfuck.

> data structures and they start doing an trial and error approach
> (changing syntax as long as it is compiled). Then hope it will do what
> they intented. That's exactly C-style! Of course, there are some that
> look under the hood and know about the details and only these people are
> able to avoid such things as memory leaks or pointers pointing to freed
> memory and so on. The others stumble through it praying that it runs and
> as long as 80% procent works they are already satisfied. That's not the
> spirit of Pascal. The language should be clear and predictable from the
> start.

Then we would have to remove things like typecasts, move or fillchar.
They are the problem because they allow the user to mess with basic
structures.