Optional param modifier

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Optional param modifier

Ryan Joseph
I had another idea yesterday while working with Swift and I was curious to hear what anyone thought. In Pascal we have “const”, “constref" “var”, “out” params for functions but no way to document or enforce optional params (which are pointers/classes).

It’s a very common pattern that a function takes a pointer as a parameter and we don’t know if we’re allowed to pass null unless we ready the comment or documentation. I thought there could be an “optional” or “opt” modifier that serves to 1) document the usage of the function and enforce nil checks on the pointer when dereferencing. It’s kind of like “const” for read-only parameters but it says “must-check” instead.

Basically, if a param (or result even?) was marked optional then you would get a compiler error if you tried to dereference the pointer, unless you were in an assigned block (or some other intrinsic since “assigned” is just a function).

What do you think of that? Sounds like an easy way to get some support for nil pointers deref’s and provides self documenting code.

====================

program test;

procedure FreeThis(optional var obj: TObject);
begin
  // must check assigned or we get a compiler error
  if assigned(obj) then
    begin
      obj.Free;
      obj := nil;
    end;
end;

procedure DoThis(optional obj: TObject);
begin
  //  must check assigned or we get a compiler error
  if assigned(obj) then
    obj.DoIt;
end;

// can return nil so return value must be checked
function MakeObject: TObject; optional;
begin
  result := TObject.Create;
end;

var
  obj: TObject;
begin

  // MakeObject result is optional so we need to check for assigned
  obj := MakeObject;

  // must check assigned or we get a compiler error when we read the class name
  if assigned(obj) then
    begin
      writeln(‘new object:’, obj.ClassName);
      DoThis(obj);
      FreeThis(obj);
      // "obj" is "optional var" so we get a compiler error unless we check for assigned
      writeln(obj.ClassName);
    end;
end.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Marco van de Voort-2

Op 2019-04-12 om 17:23 schreef Ryan Joseph:
>  
> What do you think of that? Sounds like an easy way to get some support for nil pointers deref’s and provides self documenting code.

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

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.

It all is too much topdown, assuming that you can oversee all extensions
and problems into the far future when definining a procedure.

I think the time can be better spent in making better debug tools and/or
static analyser tools for what there is than bother the language with
syntax that fixes only hypothetical corner cases.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 12, 2019, at 2:55 PM, Marco van de Voort <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Jonas Maebe-3
On 12/04/2019 21:11, Ryan Joseph wrote:
> What do you do about the problem of not knowing when a parameter of a 3rd party function can accept null?

Normally, if it can't accept nil it should be var-parameter, and if it
can then it should be a pointer.

This becomes less clear if a parameter type is already an implicit
pointer type (like a class or interface), but there are fewer case of
that kind.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 12, 2019, at 3:52 PM, Jonas Maebe <[hidden email]> wrote:
>
> Normally, if it can't accept nil it should be var-parameter, and if it can then it should be a pointer.
>
> This becomes less clear if a parameter type is already an implicit pointer type (like a class or interface), but there are fewer case of that kind.

I actually suggest this solely for the use of pointer types in order to:

1) prevent nil pointer dereferencing (do I need to check for nil on this parameter/return value or is it safe to access?)
2) self documenting code (can this parameter accept nil?)

Using var and pointers to pointers are possible workarounds but they’re not really expressing what we mean so it seemed logical to add this to the list of parameter modifiers already existing.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Free Pascal - General mailing list
In reply to this post by Marco van de Voort-2
Marco van de Voort <[hidden email]> schrieb am Fr., 12. Apr. 2019, 20:56:

Op 2019-04-12 om 17:23 schreef Ryan Joseph:
>   
> What do you think of that? Sounds like an easy way to get some support for nil pointers deref’s and provides self documenting code.

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

Im definitely for new syntaxes (or the attribute one) than a directive. A directive can be anywhere and I'd need to go looking for it if I want to know whether it is set or not. Some syntax extension would be right at the declaration. 

So, yeah, we'll probably compromise towards the attribute syntax... 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Anthony Walter-3
In reply to this post by Ryan Joseph
What's wrong with ...

procedure FreeThis; overload;
begin
end;

procedure FreeThis(var obj: TObject); overload;
begin
end;

There, now you have an optional argument with a var reference.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph

> On Apr 13, 2019, at 11:37 AM, Anthony Walter <[hidden email]> wrote:
>
> What's wrong with ...
>
> procedure FreeThis; overload;
> begin
> end;
>
> procedure FreeThis(var obj: TObject); overload;
> begin
> end;
>
> There, now you have an optional argument with a var reference.
>

Maybe my example wasn’t very clear. Here’s a very common example. We have a function that takes params and has a return value all of which can be null. As the programmer we have to read function comments or check for nil just in case because the documents weren’t clear. Doing "if assigned(p) then” out of fear is not very fun and makes for messy code.

{
  creates a new dude
  @param name: name of the dude
  @param items: list of items (optional)
  @param attrs: list of attributes or nil for default attributes
  @return reference to new dude (may be nil)
}
function CreateNewDude(name: string; items: PItemsList; attrs: PAttrList): PDude;

The attribute in the same way const says the value can’t be changed, says “may be optional so you must check”. If you forget to check for nil the compiler gives you an error.

function CreateNewDude(name: string; optional items: PItemsList; optional attrs: PAttrList): PDude; optional;

It’s a minor detail in the same way const is but it adds a little extra information and gives a little extra safety (I don’t like testing for nil out of fear, I want to know forthright). Swift did a massive overblown implementation of this idea which is a nightmare but the basic concept is as sound as “const" is.

Am I wrong about this not being common? Marco seemed to think so but I encounter this daily in the real world. In fact just yesterday I parsed the IOKit framework (Mac) to Pascal and saw Apple went through great lengths to add null-defined macros that mark params as “nullable” or not. I.e.

typedef void (*IOHIDCallback)(
                                    void * _Nullable        context,
                                    IOReturn                result,
                                    void * _Nullable        sender);

So how is this not a common occurrence that deserves a solution?


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Benito van der Zander
In reply to this post by Free Pascal - General mailing list
Hi,

the parameter is already optional without any modifier, since you can always pass nil for it.

Perhaps there could be the opposite modifier, so the function cannot be called with nil. Like
procedure DoThis(nonnil var obj: TObject); 

and then you need to check if it is nil, before calling DoThis .


Or you put it in the type. type TSomeObject = nonnil class(TObject)... and then it would never be allowed to be nil.
Or for pointers type PDude = nonnil ^TDude;  
If you would want to use such a nonnil class as field in another class, you would need to initialize it in the constructor.



Bye,
Benito 

Am 13.04.19 um 09:47 schrieb Sven Barth via fpc-pascal:
Marco van de Voort <[hidden email]> schrieb am Fr., 12. Apr. 2019, 20:56:

Op 2019-04-12 om 17:23 schreef Ryan Joseph:
>   
> What do you think of that? Sounds like an easy way to get some support for nil pointers deref’s and provides self documenting code.

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

Im definitely for new syntaxes (or the attribute one) than a directive. A directive can be anywhere and I'd need to go looking for it if I want to know whether it is set or not. Some syntax extension would be right at the declaration. 

So, yeah, we'll probably compromise towards the attribute syntax... 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Martin Frb
On 13/04/2019 18:40, Benito van der Zander wrote:
Hi,

the parameter is already optional without any modifier, since you can always pass nil for it.

Perhaps there could be the opposite modifier, so the function cannot be called with nil. Like
procedure DoThis(nonnil var obj: TObject); 

and then you need to check if it is nil, before calling DoThis .


Or you put it in the type. type TSomeObject = nonnil class(TObject)... and then it would never be allowed to be nil.
Or for pointers type PDude = nonnil ^TDude;  
If you would want to use such a nonnil class as field in another class, you would need to initialize it in the constructor.


Well nil is only with objects. For strings you could expect that there are not empty.
For integers you can have sub-ranges. But for float, you may have a condition that says > 0.

I think this goes towards https://en.wikipedia.org/wiki/Design_by_contract
pre/post conditions.

Those can then be applied for anything. And the compiler can add compile/runtime checks, the same way it does range checking.

As stated on wikipaedia this also plays towards docs. If a function has a postcondition that either forbids nil, or explicitly allows it, then you do not need to look at its code. You know what to expect.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph
In reply to this post by Benito van der Zander


> On Apr 13, 2019, at 12:40 PM, Benito van der Zander <[hidden email]> wrote:
>
> Hi,
>
> the parameter is already optional without any modifier, since you can always pass nil for it.

Sorry I must be doing a bad job explaining this and the naming of “optional” seems to be confusing since it conflicts with existing terms. The param/return is indeed optional but there’s no way to know that as the programmer.

Ok, here’s a historic real work example which is all too common:

  int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);

Can you pass null for attr? Well you need to read the man page and read through multiple paragraphs to find out "If attr is NULL, then the thread is created with default attributes.” See: http://man7.org/linux/man-pages/man3/pthread_create.3.html

Clearing up this situation with a tiny little syntax is all I propose. Make that fact known in code and force pthread_create to check if attr is nil before dereferencing it.

>
> Perhaps there could be the opposite modifier, so the function cannot be called with nil. Like

Interesting idea but I’d have to think about it more to know if this is a real problem I’ve ever experienced.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Martin Frb
On 13/04/2019 19:04, Ryan Joseph wrote:
>
> Ok, here’s a historic real work example which is all too common:
>
>    int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);
>
> Can you pass null for attr? Well you need to read the man page and read through multiple paragraphs to find out "If attr is NULL, then the thread is created with default attributes.” See: http://man7.org/linux/man-pages/man3/pthread_create.3.html
>
> Clearing up this situation with a tiny little syntax is all I propose. Make that fact known in code and force pthread_create to check if attr is nil before dereferencing it.
>

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.

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




_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 13, 2019, at 2:45 PM, Martin Frb <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 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)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 13, 2019, at 3:58 PM, Martin Frb <[hidden email]> wrote:
>
> 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.

I really don’t disagree with you that much since my proposal is minor it has a minor benefit also. The system frameworks on Mac have used empty macros to the same effect so clearly comments work also. i.e.

IOHIDDeviceRef _Nullable IOHIDDeviceCreate(
                                CFAllocatorRef _Nullable        allocator,
                                io_service_t                    service)

I appreciate Apple added those but we could do the same in Pascal with macros.  The engineers at Apple clearly thought the problem was big enough to add it into their new language (Swift) and at least for pointers I agree it’s nice.

>
> 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’m not sure it’s possible to implement without having side effects. Just floating out the idea.

I can find many hundreds of examples like the one above in the Cocoa frameworks since Apple retroactively added them in. I don’t understand why you think this is a minor subset of cases. Btw, they added the macros into the Objective-C headers so the Swift parser could correctly interpret them as optional types (denoted with the ? symbol if you’re familiar with Swift).

Anyways, not a single person thought this was a good idea so I’ll leave it be. :)

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Martin Frb
On 13/04/2019 22:34, Ryan Joseph wrote:
>
> I can find many hundreds of examples like the one above in the Cocoa frameworks since Apple retroactively added them in. I don’t understand why you think this is a minor subset of cases.
That "minor set" referred to compiler warnings you get, inside a
function that has an optional argument, if you do not check that
argument for nil:
Objects that are nil happen everywhere in the code.  The amount of
object accesses with potential nil issues that will be in the scope of
such an optional parameter is minor compared to the amount of overall
such accesses.

The amount of method declaration that could benefit from additional
clarity towards what values they can take in there arguments (and
hopefully deductible from that their purpose) may indeed be noticeable.
But for that there should be better solutions. Not at least because
nil-ability is only one such concern.
Were it only the documentation of nil-ability then comments would do the
job.
When it is about a more generic approach then see the wikipage about
contracts. (I did mail a link)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 13, 2019, at 5:11 PM, Martin Frb <[hidden email]> wrote:
>
> Were it only the documentation of nil-ability then comments would do the job.
> When it is about a more generic approach then see the wikipage about contracts. (I did mail a link)

If there was any other way the compiler could make this contract more concrete and reliable then comments I’d be happy to hear it.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Martin Frb
On 13/04/2019 23:17, Ryan Joseph wrote:
> If there was any other way the compiler could make this contract more
> concrete and reliable then comments I’d be happy to hear it.

I don't know what others think of it, but
https://en.wikipedia.org/wiki/Design_by_contract
look at pre/post-conditions.

It basically is like assertions. But it is a bit more, because there are
rules for inheritance. So it should be part of the declaration, not the
implementation.

Once such conditions exists, the compiler could be enhanced in different
ways:
- insert the correct assertions
- check at compile time, if possible (may give errors, warnings, hints,
depending how certain the compiler is)

Of course it does a bit of the opposite of what you did. It allows to
say, when a param is not allowed nil.

By implication any param that has no pre-condition is allowed nil, and
the compiler should assume it may be nil.

----------
Back to your original issue.

To express that a param could be nil, to indicate it is omitted. If you
can put it to the end of the list
   procedure Foo(Bar: TBar; Opt: TOpt = nil);
makes it perfectly clear, that nil is an intended accepted value
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Free Pascal - General mailing list
On 4/13/19 11:39 PM, Martin Frb wrote:

> On 13/04/2019 23:17, Ryan Joseph wrote:
>> If there was any other way the compiler could make this contract more
>> concrete and reliable then comments I’d be happy to hear it.
>
> I don't know what others think of it, but
> https://en.wikipedia.org/wiki/Design_by_contract
> look at pre/post-conditions.
>
> It basically is like assertions. But it is a bit more, because there are
> rules for inheritance. So it should be part of the declaration, not the
> implementation.
>
> Once such conditions exists, the compiler could be enhanced in different
> ways:
> - insert the correct assertions
> - check at compile time, if possible (may give errors, warnings, hints,
> depending how certain the compiler is)
>
> Of course it does a bit of the opposite of what you did. It allows to
> say, when a param is not allowed nil.
>
> By implication any param that has no pre-condition is allowed nil, and
> the compiler should assume it may be nil.

Well, there is Oxygene's concept of Class Contracts (see
https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
anything in that direction would be done I'd be inclined towards their
syntax (and I've played with the idea to implement this in FPC for quite
some time already).

Though of course it wouldn't necessarily solve the point of knowing
whether one may pass Nil or not, cause especially in compiled code you
can't look at the source. So the compiler would need to store the
conditions in the PPU as well, so that the IDE could present them as
part of the tooltip even if no source is available...

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Optional param modifier

Ryan Joseph


> On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Well, there is Oxygene's concept of Class Contracts (see
> https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
> anything in that direction would be done I'd be inclined towards their
> syntax (and I've played with the idea to implement this in FPC for quite
> some time already).

That’s an interesting idea. It’s certainly common that you test for these conditions at the top of the function and have bail out conditions so it makes sense to pull it out into syntax. But it has to rely on exceptions and all that overhead? That’s not so great if so.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123