Op 2019-04-13 om 09:47 schreef Sven Barth via fpc-pascal:
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 defin
Op 2019-04-12 om 21:11 schreef Ryan Joseph:
What do you do about the problem of not knowing when a parameter of a 3rd party function can accept null?
If it is native Pascal it is probably VAR, as Jonas said. If it is an
header for an external package/API, consult their documentation.
___
Am 14.04.2019 um 23:48 schrieb Martin Frb:
As for "documentation". I disagree with the way it is done in oxygen.
But I am not sure I have any good alternative.
For me a class contract (require/ensure) is part of the interface.
So it would have to be like (and similar for plain procedures, no
c
Am 15.04.2019 um 01:19 schrieb Ryan Joseph:
On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
Almost. assert takes the condition itself
assert(condition_that_must_be_true, 'error message')
so it would be
assert(name<>'', 'requires "name <> " failed for CreateHero');
You can already ins
On 15/04/2019 01:19, Ryan Joseph wrote:
On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
Almost. assert takes the condition itself
assert(condition_that_must_be_true, 'error message')
so it would be
assert(name<>'', 'requires "name <> " failed for CreateHero');
You can already insert
> On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
>
> Almost. assert takes the condition itself
>
> assert(condition_that_must_be_true, 'error message')
>
> so it would be
> assert(name<>'', 'requires "name <> " failed for CreateHero');
>
> You can already insert such asserts yourself.
On 15/04/2019 00:53, Ryan Joseph wrote:
Here’s what I imagine that would look like:
procedure CreateHero (name: string; hp: integer);
requires
name <> '';
(hp > 0) and (hp < 100);
begin
// compilers parses the conditions and inserts as if statements:
// if name <> ‘’ then
// as
> On Apr 14, 2019, at 6:30 PM, Martin Frb wrote:
>
> I would actually argue that it is infinitely more important to check for nil
> after MakeThing. (Unless I know for sure it is not needed: proof, docs)
>
> Assuming (taking the danger of doing so) both do what there name indicates,
> then:
On 14/04/2019 22:08, Ryan Joseph wrote:
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
On 14/04/2019 23:48, Martin Frb wrote:
I admit the contract/assert stuff may have made it seem different. But
that is because this approach does not hold up (IMHO). And therefore
the closest alternative was presented.
In the very end it is to avoid crashing on nil de-ref. And the
contract/a
On 14/04/2019 22:08, Ryan Joseph wrote:
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
> On Apr 14, 2019, at 3:38 PM, Martin Frb 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*
On 14/04/2019 19:53, Ryan Joseph wrote:
On Apr 14, 2019, at 1:38 PM, Sven Barth via fpc-pascal
wrote:
As already said by Martin: the compiler *can not* determine all cases whether
the parameter is Nil or not, so it *must* be done at runtime to ensure this.
Otherwise the feature is just as
> On Apr 14, 2019, at 1:38 PM, Sven Barth via fpc-pascal
> wrote:
>
> As already said by Martin: the compiler *can not* determine all cases whether
> the parameter is Nil or not, so it *must* be done at runtime to ensure this.
> Otherwise the feature is just as useful as this:
I’ve read ove
Am 14.04.2019 um 16:05 schrieb Ryan Joseph:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable checking
whether valid entries are passed in at compile time except for simple, constant
cases, so runtime checks are n
On 14/04/2019 18:04, Martin Frb wrote:
On 14/04/2019 16:05, Ryan Joseph wrote:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable
checking whether valid entries are passed in at compile time except
for simple, con
On 14/04/2019 16:05, Ryan Joseph wrote:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable checking
whether valid entries are passed in at compile time except for simple, constant
cases, so runtime checks are neede
> On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
> wrote:
>
> Your idea requires exceptions as well. The compiler is not capable checking
> whether valid entries are passed in at compile time except for simple,
> constant cases, so runtime checks are needed and the only way to abort
Ryan Joseph schrieb am So., 14. Apr. 2019,
00:17:
>
>
> > On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Well, there is Oxygene's concept of Class Contracts (see
> > https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
> >
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
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 imple
> 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 playe
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/De
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
> 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 co
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
f
> 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
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 pu
> 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
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 th
> 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 w
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 t
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
> 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 ve
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://
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
> On Apr 12, 2019, at 3:52 PM, Jonas Maebe 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 few
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 ty
> On Apr 12, 2019, at 2:55 PM, Marco van de Voort
> 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 pleas
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, a
40 matches
Mail list logo
