On Mon, 14 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
On Mon, 14 Oct 2019 07:37:38 +0200
Sven Barth via fpc-pascal <fpc-pascal@lists.freepascal.org> wrote:
[...]
Because the iterator returns a Pointer and not whatever you think it
might return. If you know it's something else, you cast that inside
the loop.
I agree with Sven.
What about the other way round?
For example this is allowed: TControl(aButton):=aControl;
That's a good way to shoot yourself in the foot.
If aControl is a TEdit, for example, this will also pass.
This works also when passing something to a "var" argument.
That's like giving someone 2 guns to shoot himself in the feet
simultaneously.
No, seriously:
That's a really bad kludge because for good reasons, you can't pass descendents
as a var argument, and unfortunately the typecast is sometimes used to work
around this.
This is also an excellent way to shoot yourself in the foot.
Consider the following:
Procedure DoSomething(var A : TControl);
Var
N : String;
begin
if Assigned(a) then
N:=A.Name;
A:=TEdit.Create(Nil);
A.Name:=N;
end;
var
B : TButton;
begin
DoSomething(TControl(B));
// And now B contains a TEdit, despite the declaration
end;
The typecast is something you should not do in this case.
/* Cultural note: this is the reason FreeAndNil has an untyped argument :( */
It would be consistent to allow it as the for-in-loop variable.
As far as I know, you're (rightly) a proponent of not allowing people op shoot
themselves in the foot ?
The typecast is something that should be discouraged, not encouraged.
So no, I don't think we should allow this.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
