Re: [fpc-pascal] mode switch madness

[Ben Grasset]

I dunno about setting them globally, but generally I do find modeswitches
rather annoying, as the combination of features is pretty arbitrary, and
they mostly just *disallow* things that couldn't break the code of people
who weren't using those features to begin with if they were allowed.

E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am
glad that {$mode ObjFPC} does not allowed advanced records. It would be
specifically bad if it did!" because it just doesn't matter if they weren't
using advanced records to start with. It's just a lot of minor rules that
nobody can really explain but that tend to add up in relatively annoying
ways.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Benito van der Zander]

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.


for example, I store some interfaces in a list, and just replaced the 
default list with a faster list that assumes all interfaces in the list 
are non-nil. (When you know the interface is non-nil, you can replace 
the automatic reference counting with a direct call to ._addref, which 
is faster. )


But then it crashed because somewhere it was used with a nil interface. 
There it would have been useful to mark the new function as only non-nil 
accepting, so that it is clear it cannot be used like the old function, 
and the compiler have made sure there is no call with nil





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. 


You would need to have optional or non-nil markers at every variable, 
before it becomes really useful.




Benito

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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 00:01, Sven Barth via fpc-pascal 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).

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


Well it needs to be in the ppu anyway, because even without source, an 
object can be inherited from.


And the inherited method must fulfil some of the conditions
- It can't accept less than its base (requirements can be looser, but 
not tighter)
- It must fulfil the "ensure"s, or be even stricter. (as that would 
still fulfil them)


Also being in the ppu, would allow compile time errors, when passing 
violating constants.


There are a few things about the oxygen syntax.

1) require is outside the begin..end, but ensure is inside.

2) As the nature of those conditions can be inherited, they are more to 
be thought of as declaration, than implementation.
That would call for them to be in the interface. Though of course that 
messes up the interface



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

Re: [fpc-pascal] Using TInterfaceList and casting interfaces

[Benito van der Zander]

Hi,


Or perhaps it is better to use gvector rather than TInterfaceList?


If you only store a specific interface type then using one of the 
generic containers specialized to that type would indeed be best.




 and on a closer look TInterfaceList does a lot of locking.

guess TInterfaceList should be avoided, unless you actually need 
something thread-safe. The classes unit is full of weird stuff


Best,
Benito

Am 07.04.19 um 20:24 schrieb Sven Barth via fpc-pascal:
Benito van der Zander mailto:ben...@benibela.de>> 
schrieb am So., 7. Apr. 2019, 15:34:


Writing (list.get(0) as ISomeInterface), is very slow and not
possible,
when the interface has no GUID.


This is indeed what is supposed to be used with TInterfaceList.

Or perhaps it is better to use gvector rather than TInterfaceList?


If you only store a specific interface type then using one of the 
generic containers specialized to that type would indeed be best.


Regards,
Sven

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

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal 
>  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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Sven Barth via fpc-pascal]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 5:11 PM, Martin Frb  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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 3:58 PM, Martin Frb  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 _Nullableallocator,
io_service_tservice)

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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


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

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

[Ralf Quint]

On 4/13/2019 12:30 PM, Alexey Tor. wrote:
E.g. i have a loop which test each s[i] char for several cases: 'a', 
'b', 'c'.


for i:= 1 to length(s) do

if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...

Can FPC optimize it so it only reads s[i] once (to register), not 3 
times?



How about writing it in Pascal, something like

if s[i] in ['a'..'c'] then

or in case of no-sequential characters/values

if s[i] in ['a', 'b', 'c'] then...


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

[Alexey Tor.]

E.g. i have a loop which test each s[i] char for several cases: 'a', 
'b', 'c'.


for i:= 1 to length(s) do

if (s[i]='a') or (s[i]='b') or (s[i]='c') then ...

Can FPC optimize it so it only reads s[i] once (to register), not 3 times?

--
Regards,
Alexey

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

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 2:45 PM, Martin Frb  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

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 12:40 PM, Benito van der Zander  
> 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Benito van der Zander]

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 > 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Ryan Joseph]

> On Apr 13, 2019, at 11:37 AM, Anthony Walter  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 * _Nullablecontext,
IOReturnresult, 
void * _Nullablesender);

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


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Optional param modifier

[Anthony Walter]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Sven Barth via fpc-pascal]

Marco van de Voort  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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal