The below compiles, and writes
1 2

Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param.

program Project1;
type

  { TFoo }

   TFoo = class
   private
     function GetFoo(var AIndex: Integer): Integer;
   public
     property Foo[var AIndex: Integer]: Integer read GetFoo;
   end;

{ TFoo }

function TFoo.GetFoo(var AIndex: Integer): Integer;
begin
   Result := AIndex;
   AIndex := AIndex+1;
end;
var a,i: integer;
   f: TFoo;
begin
   f := TFoo.Create;
   i := 1;
   a := f.Foo[i];
   writeln(a,' ',i);
   readln;
end.

That sounds like a bug or something that should be prevented. I just found out default properties allowed overloading by accidental means so this may be another similar matter. Those should maybe be prevented also but that could break existing code.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Do., 27. Juni 2019, 23:50:

If it's a bug (what I do indeed think of this and the other bug you mentioned) it's considered acceptable to break backwards compatibility. After all we wouldn't be able to fix essentially anything as some code out there might rely on the behavior.

Regards,
Sven

On Jun 27, 2019, at 5:57 PM, Sven Barth via fpc-devel wrote: If it's a bug (what I do indeed think of this and the other bug you mentioned) it's considered acceptable to break backwards compatibility. After all we wouldn't be able to fix essentially anything as some code out there might rely on the behavior.

Did you see the other users note in my bug report? Looks like this:

 tINIFile = object
  private
    procedure SetAsText( akey:PAnsiChar;val:PAnsiChar); overload;
    procedure SetAsText( asection,akey:PAnsiChar;val:PAnsiChar); overload;
    procedure SetAsText(ans,asection,akey:PAnsiChar;val:PAnsiChar); overload;
    function GetAsText( akey:PAnsiChar):PAnsiChar; overload;
    function GetAsText( asection,akey:PAnsiChar):PAnsiChar; overload;
    function GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar; overload;
  public
    property Value [ans:PAnsiChar; asection:PAnsiChar; akey:PAnsiChar]:PAnsiChar
             read GetAsText write SetAsText; default;
  end;

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

Try it and play around but it works to call value with variable number of parameters.

Does that mean 2 bugs with properties then? allowing var and out in properties seems wrong also.

Regards,
Ryan Joseph

PM Martin wrote

Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param.

"Var" and "Out" seem bad, although I've always though that "Constref" *should* be allowed.

Most property index are simple types. So you would not need it.

But *** hypothetically speaking ***  constref (and const too) could be given in the getter, but not in the property
TFoo = class
  private
    function GetFoo(constref AIndex: Integer): Integer;   public
    property Foo[AIndex: Integer]: Integer read GetFoo;   end;
The compiler woull simply (nothing is ever simple ;) ) need to know that the signature is still valid, even with the constref. Of course the compiler accepts any data type as valid for the index. So you could declare a big record for the index, and argue for constref. I don't really think it is needed.

Another one, that arises suspicion for its validity: open arrays. They can only be declared in parameter lists for procedures and functions. Oh and in properties:
TFoo = class
  private
    function GetFoo(AIndex: array of Integer): Integer;   public
    property Foo[AIndex: array of Integer]: Integer read GetFoo;   end;

That's what I meant with "the other bug you mentioned".

Regards,
Sven

I just tested with Delphi and it works there as well. So contrary to what we thought this does not seem to be a bug...

Regards,
Sven

What does Delphi do with

    property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read GetFoo;
Because FPC rejects this one. (And IMHO rightfully so)

URL for viewvc broken...

svn.freepascal.org/cgi-bin/viewvc.cgi/?sortby=date#dirlist

Yes temporarily, on purpose.

We were experiencing a DDOS attack using it.

Michael.

On Jun 28, 2019, at 1:39 AM, Sven Barth via fpc-devel wrote: I just tested with Delphi and it works there as well. So contrary to what we thought this does not seem to be a bug...

I think it’s still buggy. Why does this compile? I guess it would make sense if the property didn’t have any parameters and just mapped to any of the overloaded functions but with the parameters it doesn’t make any sense.

I submitted my patch for multiple default properties (https://bugs.freepascal.org/view.php?id=35772) which is a more sane solution than allowing this:

program test;
type
  tINIFile = object
  private
    function GetAsText( akey:integer):PAnsiChar; overload;
    function GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar; overload;
  public
    property Value [ans:PAnsiChar; asection:PAnsiChar; akey:PAnsiChar]:PAnsiChar
             read GetAsText; default;
  end;
function tINIFile.GetAsText( akey:integer):PAnsiChar;
begin
end;
function tINIFile.GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar;
begin
end;
var
  o: tINIFile;
  s: PAnsiChar;
begin
  s := o[1];
  s := o['a','b','c'];
end.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Fr., 28. Juni 2019, 20:12:

I was talking about the var/out stuff. The overload one doesn't work in Delphi either.

Regards,
Sven

Assuming that GetFoo is declared as "function GetFoo(AIndex: Integer): Integer" It fails with "E2250: There is no overloaded variant of 'GetFoo' that can be called with these arguments" (or however that error message is translated to English.

The following also fails:

=== code begin ===

function GetFoo(AIndex: Integer; BIndex: Integer): Integer;
property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read GetFoo;

=== code end ===

However this works:

=== code begin ===

function GetFoo(AIndex: Integer; BIndex: Integer = 0): Integer;
property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read GetFoo;

=== code end ===

As does this:

=== code begin ===

function GetFoo(AIndex: Integer; BIndex: Integer = 0): Integer;
property Foo[AIndex: Integer; BIndex: Integer]: Integer read GetFoo;

=== code end ===

Regards,
Sven

Hope this madness can be avoided in fpc....

Good

Ouch
What then about
  function GetFoo(AIndex: Integer = 0): Integer;
  property Foo[AIndex: Integer = 0]: Integer read GetFoo; And if it compiles, which of those can you call
  Obj.Foo
  Obj.Foo[]
And what if you make that default property....
  Obj[] // ????

This is ok.

GetFoo can be called directly.
So long, as the property will fail, if called with only one index.

Those all don't compile. Even using my example above "Foo[42]" does not compile either, so while a default parameter can be declared the compiler won't allow the default parameters to be left out in the index clause.

Maybe we should forbid default parameters in the index clause in non-Delphi modes so that it's clear that this won't work?

Yes, it indeed fails.

Regards,
Sven

It has no sense allowing them to be declared if they don't work, so yes. Either that or allow them to be omitted.

Michael.