[fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 14, 2019, at 3:38 PM, Martin Frb <lazarus at mfriebe.de> wrote:
> 
> 
> One thing is what checks can be done, to help the programmer not to accidentality  de-ref nil.
> The other thing is how.
> 
> 1) The "optional" is actually the default. If anything towards a deref-warn feature was done, then *every* parameter,  *every* return-value (and even every other var) of a nil-able type should be seen as optional.
> If a type is not optional, then it should be declared as "not nil-able" => function foo(notnil a: TObject): notnil TOBject;

I read through but I think we’re stuck on this first misunderstanding. This is not the default, I would never suggest this since as you mentioned it leads to massive overreach. Never would I want this added to *every” param and return. Just to get that out of the way. Swift has done this and it SUCKS that we’re forced to unwrap optionals all the time. It’s so much friction and I really hate it.

I’m also not suggesting this means “not nil” either. I mean simply *may* be nil so you need to check. I know that all pointer types COULD be nil.

Per my example, currently we know that GetThing() COULD return nil so unless we know what the function does by reading the documentation or looking at the implementation we need to test for nil. Right? I suggest the modifier simply to enforce that check and let it be known that’s the desired usage.

So, in other words:

	function FindThing: TThing; optional;

means you MUST check for nil. If the value is nil that’s not an error. “optional” is probably a bad name for this I know.

	function MakeThing: TThing;

this means maybe check for nil or maybe not check for nil. We don’t know what the programmer intended because no extra information was given (at least in the declaration). Because of the name we probably assume this is going to return a new object which is safe so checking for nil would be a waste. But we don’t know that except for what the name implies or if we read the code.

Is that more clear? If there’s a better way to express this then please let me know.

> 
> That is in the same way as range checks. There is on "type x=array[1..50] with range checks of integer;"
> 
> Using your "Optional" is just specifying what already applies. In other words: redundant.
> 
> Now specifying it for a result, is different than specifying it for a parameter.
> - For a parameter, the problem was:
>    that if I want the compiler to check that I test for "assigned",
>    => then I must remember that I want the compiler to do that,
>    => because if I do not remember, then I would not add the "optional"
>   But:
>   If I already remember that I want to have a check for "assigned", then I can do it right away.
>   I do not need the "optional", so that I get a warning for forgetting something that I actually just though of.
> 

For parameters I like what Sven suggested to have a “requires” section in functions to check this but wouldn’t it make sense if the function parameter gave some hint also? “can be nil” or “can’t be nil” would both be helpful in terms of documentation and compile time errors instead of runtime errors.


Regards,
	Ryan Joseph