> On Apr 12, 2019, at 2:55 PM, Marco van de Voort <f...@pascalprogramming.org>
> wrote:
>
> I think the same as when I read the suggestion for an inout variant of VAR.
> Move this out of the language syntax, and make it directives or attribute
> like syntax (like we will need to get anyway for const ref).
Example please? I didn’t know there were alternatives to parameter modifiers.
>
> As to the functionality itself, IMHO it is a solution in search of a problem.
> Yes, it theoretically nails down the contract a bit more, but I rarely expect
> that this makes programming in pascal any easier.
What do you do about the problem of not knowing when a parameter of a 3rd party
function can accept null? That alone is an annoying little detail that arises
often and requires looking at the code comments or manuals. Same situation with
functions results, I often don’t know if the result could be nil and I perform
a check just to make sure. Having the function itself document this would be
helpful and a compiler error would be even more helpful.
Having said that I admit to not using “const” and almost regret its
introduction because now programers use it everywhere, even when not needed.
Constref on the other hand was a great addition and “out” and “var” are
obviously needed.
Btw a little off topic, the reason I don’t use const is because it doesn’t do
the one thing I want it to, i.e. ensure members are not modified in a function.
In the example below why doesn’t const give me an error when I try to assign to
the “x” member variable? That’s the one reason I want const and it doesn’t even
do that one thing! Grrr. Maybe we need another modifier, “realconst". :)
type
TMyRecord = record
x: integer;
end;
PMyRecord = ^TMyRecord;
procedure DoThis(const p: PMyRecord);
begin
p.x := 10;
end;
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
