> On Apr 13, 2019, at 2:45 PM, Martin Frb <laza...@mfriebe.de> wrote:
> 
> Well that doesn't work. Unless you wrote pthread_create (or whatever other 
> function).
> Because the "opitonal" parameter (which really only serves as documentation 
> hint) is itself optional.
> So if the author of the code that you intend to use did not put "optional" in 
> there, you are still where you are now. And you cant force the author to put 
> it there. Same as you cant force the author to put it on top of the 
> documentation.
> 
> 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:

type
  TClassName = class (TObject)
    {private}
    m_var: integer;
    {public}
    procedure DoThis({const} p: TPoint);
  end;

They’re just simple hints that provide some compile time errors.

> 
> 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.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to