[fpc-pascal] Optional param modifier

[Martin Frb]

On 13/04/2019 21:07, Ryan Joseph wrote:
>
>> Already today the author could add a comment (even pasdoc) to the declaration. And it serves the same effect.
> Sure, if it’s not used then it’s not very helpful. :) Comments are the same effect? Then why not prefer comments for “const” params or even public/private sections. Surely this isn’t a good idea:
You misread me. I am sure inadvertently, but still. You advertised that 
this feature you desire was to fulfil two purposes. One of which you 
named to be documentation. Or as you described, the elimination of the 
need to look through copious amounts of implementation, or in other 
cases pages of documentation.

As for this part of your request, I made it known that it is my belief 
that comments can have the same effect.

As for the  second purpose that you had brought to our attention, I gave 
answer to it further down in my mail.

>> Also the is a difference between:
>> - the parameter is nil-able (better term that optional, optional has a different meaning)
>> - the compiler needs to enforce an check for "<> nil"
>>
>> If the parameter is only stored, for later usage, then the nil can be stored too. There is no check needed for that.
>> It will be needed later in some other function, but the compiler can not know where that may be.
>>
>> You can even call methods on an object that is nil. So long as they are:
>> - not virtual, nor call virtual methods themself
>> - do not access "self" without prior check that it is not nil
> All true. I only propose this for cases where nil could be passed/returned and the programmer can be given more information and forced to check since this is the pattern they were supposed to do anyways. It’s not a magic catch-all, just a minor markup thing like “const” is.

Well, as far as the "optional" part goes, the benefits of it will be 
fairly limited. Object variables occur in many places, and all of them 
can have the nil value, and the compiler has no idea if you did the check.

You pick a tiny subset of those cases, and attempt to add protection to 
it. Given the gain (or rather absence of it, according to the 
microscopic size of that subset) the effort (and chance of false 
positives) is not worth it.
I have already in todays code encountered the compiler telling me 
variables were not initialized, were clearly they were. But the compiler 
was not smart enough to follow the code through various conditional blocks.
If the compiler were to force that check, when at the same time it is 
not smart enough to see, that I actually already have it, then clearly 
that would be a problem.

Besides there is a "loop"hole (pun intended / follows) in this feature. 
The feature creates a circular (loop) dependency.
If I want the compiler to force me to add the check, I need to add the 
keyword. But if I remember to add the keyword, well I may as well add 
the check instead. After all I am already aware of its need, or I would 
not add the keyword.

So if I am not aware of the need for the check, I am likely not to add 
the keyword, and I will never know (until my app crashes)