Unexpected behavior of TStrings.AddStrings

[simone]

As known TStringList.AddStrings accepts an Array of String or a TStrings and adds their contents to the TStringList instance that invokes it.

Given the above, consider the following code:

Code: Pascal  [Select][+][-]

1. program project1;
2. uses
3.   Classes;
4. type
5.   MyClass=class
6.     private
7.       fData : string;
8.     public
9.       property Data : string read fData write fData;
10.   end;
11. var
12.   List : TStringList;
13.   aClass : MyClass;
14.  
15. begin
16.   List:=TStringList.Create;
17.   aClass:=MyClass.Create;
18.   List.Add('one');
19.   aClass.fData:='two';
20.   List.AddStrings(aClass.Data);
21.   writeln(List.Text);
22.   readln;
23.   List.Free;
24.   aClass.Free;
25. end.  

In this case, using AddStrings, the content of a string property of an object is added. Nonetheless, the program works well. But is this behavior correct? I wasn't expecting that and it created a hard-to-find bug for me.

[Bart]

It adds an array of strings with length = 1?
Bart

[simone]

I did not know that when a procedure / function expects an open array parameter, it is possible to invoke it with a scalar value of the same type as the array. In other words, this is possible:

Code: Pascal  [Select][+][-]

1. program project1;
2. var
3.   S : string;
4.  
5.   procedure Proc(L : array of string);
6.   begin
7.     writeln(Length(L));
8.     readln;
9.   end;
10.  
11. begin
12.   Proc(S);
13. end.

Just for the sake of knowledge: is this behavior explicitly contemplated in the language specification?

[Thaddy]

Bart means List.AddStrings([aClass.Data]); Note the brackets. The parameter is an array...

[simone]

I don't use square brackets in my code.  Why does it work?

[howardpc]

Just for the sake of knowledge: is this behavior explicitly contemplated in the language specification?

I would think that this behaviour (interpreting a string parameter as an open array of string) is a bug.
But perhaps it is an (undocumented) feature.
If the argument to the procedure is instead declared as TStringArray (i .e. a dynamic array of string) the compiler correctly points out that an ansistring is not what what was expected if that is what you feed it.

[SymbolicFrank]

Shouldn't that be:

Code: Pascal  [Select][+][-]

1.   aClass.Data:='two';

?

[simone]

Private members are visible in the same module where the class is declared. It is not strict private.

[Zoran]

See this:
https://stackoverflow.com/questions/13490338/why-can-i-pass-a-var-of-type-x-to-a-open-array-parameter-of-that-type

There in one comment, this is quoted (but the link from there does not work for me):

    Open array arguments must be supplied with an actual array variable, a constructed array or a single variable of the argument's element type.

As far as I understand, there they say that it is not in documentation, but they found it in some bug report. There is a link to this, but it seems dead.
And google does not find this quote.

[MarkMLl]

See this:
https://stackoverflow.com/questions/13490338/why-can-i-pass-a-var-of-type-x-to-a-open-array-parameter-of-that-type

There in one comment, this is quoted (but the link from there does not work for me):

    Open array arguments must be supplied with an actual array variable, a constructed array or a single variable of the argument's element type.

As far as I understand, there they say that it is not in documentation, but they found it in some bug report. There is a link to this, but it seems dead.
And google does not find this quote.

In any event, that's specific to Delphi. Archive.org doesn't have the page but Google currently has it cached at https://webcache.googleusercontent.com/search?q=cache:cRVV4RIWvF8J:https://docwiki.embarcadero.com/RADStudio/Sydney/en/E2192_Constants_cannot_be_used_as_open_array_arguments_(Delphi)+&cd=2&hl=en&ct=clnk&gl=uk&client=firefox-b-e

E2192 Constants cannot be used as open array arguments (Delphi)

Open array arguments must be supplied with an actual array variable, a constructed array or a single variable of the argument's element type.

Code: Pascal  [Select][+][-]

1. program Produce;
2.  
3.   procedure TakesArray(s : array of String);
4.   begin
5.   end;
6.  
7.  
8. begin TakesArray('Hello Error');
9. end.
10.  

The error is caused in this example because a string literal is being supplied when an array is expected. It is not possible to implicitly construct an array from a constant.

Code: Pascal  [Select][+][-]

1. program Solve;
2.  
3.   procedure TakesArray(s : array of String);
4.   begin
5.   end;
6.  
7.  
8. begin TakesArray(['Hello Error']);
9. end.
10.  

The solution avoids the error because the array is explicitly constructed.

If FPC doesn't document this either way the question is one for the core team. Otherwise it should IMO be treated as implementation-specific and not relied on.

MarkMLl

[simone]

The problem arises in general, not only with strings:

Code: Pascal  [Select][+][-]

1. program project1;
2. var
3.   S : integer;
4.  
5.   procedure Proc(L : array of integer);
6.   begin
7.  
8.   end;
9.  
10. begin
11.   Proc(S);
12. end.  

This means that when a procedure / function expects an open array parameter, it is possible to invoke it with a scalar value of the same type as the array.

Since Object Pascal is a strongly typed language, in my opinion this behavior is incorrect and can lead to errors that are very difficult to find.

[MarkMLl]

Since Object Pascal is a strongly typed language, in my opinion this behavior is incorrect and can lead to errors that are very difficult to find.

First, you haven't said what mode you're using. Second, if Delphi does it that way then tell them they're wrong. Third, wait until one of the core team comments: either they will say that they consider it useful if not correct behaviour or that their hands are tied by Delphi's behaviour.

MarkMLl

[jcmontherock]

It seems to me that is the same behavior of the following code:

Code: Pascal  [Select][+][-]

1. CharArray:  Array[0..100] of Char;
2. ....
3. CharArray := 'abcdefghijkl';
4.  

which works well.

[simone]

Since Object Pascal is a strongly typed language, in my opinion this behavior is incorrect and can lead to errors that are very difficult to find.

First, you haven't said what mode you're using. Second, if Delphi does it that way then tell them they're wrong. Third, wait until one of the core team comments: either they will say that they consider it useful if not correct behaviour or that their hands are tied by Delphi's behaviour.

MarkMLl

The behavior occurs in both {$mode ObjFpc} and {$mode Delphi}.

[MarkMLl]

It seems to me that is the same behavior of the following code:

Code: Pascal  [Select][+][-]

1. CharArray:  Array[0..100] of Char;
2. ....
3. CharArray := 'abcdefghijkl';
4.  

which works well.

No, it's not. Because in the case of your CharArray the base type is a char, while you're assigning a string.

I'm not saying that these clandestine conversions aren't convenient, but I'm beginning to feel that there are too many of them in the core language. But as been made clear in the past, it's not my decision and at least in part FPC has to toe Delphi's line.

MarkMLl