Why empty dynamic arrays = NIL?

[Attila Kovacs 629]

This is the yellow brick road to unpredictable behaviors depending on the uses list.

Use "TMyStringList", don't try to rewrite the RTL.

[David Heffernan 2345]

6 hours ago, Dalija Prasnikar said:

 But you can have your own implementation

Can't use the operators that we have in other languages 

[Leif Uneus 43]

7 hours ago, Dalija Prasnikar said:

If I had a dime for every time I though "this string cannot be nil here, so I don't need to check" and then I had exceptions at runtime, I would be on my tropical island right now, drinking pina colada.

Why would you need an excuse to do that. Go for it anyway!

[Dalija Prasnikar 1396]

50 minutes ago, David Heffernan said:

Can't use the operators that we have in other languages 

True. But that is not the argument for nil string and arrays, on the contrary.

 

I am all for having nullable types built in, together with full language support, but that does not mean I am for changing how strings and arrays work. Nullable types should be wrapper on around those and value types.

[Dalija Prasnikar 1396]

24 minutes ago, Leif Uneus said:

Why would you need an excuse to do that. Go for it anyway!

I am few dimes short...

[David Heffernan 2345]

2 minutes ago, Dalija Prasnikar said:

True. But that is not the argument for nil string and arrays, on the contrary.

 

I am all for having nullable types built in, together with full language support, but that does not mean I am for changing how strings and arrays work. Nullable types should be wrapper on around those and value types.

All I said, and you can go check, is that it is sometimes desirable to distinguish null from empty. 

[Fr0sT.Brutal 900]

On 9/24/2021 at 7:17 PM, Uwe Raabe said:

At least it is documented here: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Structured_Types_(Delphi)#Dynamic_Arrays

Yes, just like TDateTime = Double... and just like SizeOf(Char) = 1 until a thunder stroke at 2009 🙂 For me, not relying on implementation details is just an additional layer of stability. In 2009 those who weren't assuming Char is almost the same as Byte, could adopt Unicode with almost no changes. Others were suffering. If sometimes TDateTime becomes a record with two numbers (f.ex., days from 1 Jan 0001 and msecs of day), those who write "secsBetween := (dt1 - dt2)*86400" will suffer. Me, using "secsBetween := SecondsBetween(dt1, dt2)" won't.

 

On 9/24/2021 at 8:12 PM, Mike Torrettinni said:

Hm, I use it a lot. I prefer array <> nil over Length(array) > 0.

I personally consider it bad style.

This relies on impl details, and any new coder will have to keep in mind these nuances. "What, var is null here? Okay, I know that from my Java/SQL/JS background. Let's assign it with 0 length for now, to be expanded later. What could go wrong?"

Moreover, sometimes you want to refactor. F.ex., array becomes insufficient and you change type to TList.

Option #1, if using `Length(arr)`: change type, try to build, change all `Length(arr)` to `arr.Count` that compiler will complain on

Option #2, if using `arr = nil`: SUFFER.

 

P.S. Honestly I don't see why array literals took so long to add. Clause "if arr = []" would be pretty obvious and consistent to string type

Edited September 27, 2021 by Fr0sT.Brutal

[Lars Fosdal 1792]

On 9/25/2021 at 11:57 PM, David Heffernan said:

All I said, and you can go check, is that it is sometimes desirable to distinguish null from empty. 

I agree.  
NULL = There is no list.

Empty = There is a list, but it is empty.

 

[Mike Torrettinni 198]

1 hour ago, Fr0sT.Brutal said:

those who write "secsBetween := (dt1 - dt2)*86400" will suffer.

I don't have such example, but I searched in some third party source and there are plenty same and similar examples. I see this is 'never use Magic numbers' more than a 'it's implementation detail that can change'.

 

34 minutes ago, Lars Fosdal said:

NULL = There is no list.

Empty = There is a list, but it is empty.

I would totally understand if arrays follow same logic. And if they ever change that, I will gladly use Length and not nil.

 

I was thinking about this and probably is specific to just me, but I actually find it easier to distinguish between = and <> when using nil vs Length:

if DataArray = nil then ...
if DataArray <> nil then ...
vs
if Length(DataArray) = 0 then ...
if Length(DataArray) <> 0 then ...

Especially if condition is part of longer condition, is just easier to quickly identify what is going on.

Edited September 27, 2021 by Mike Torrettinni

[Stefan Glienke 2002]

1 hour ago, Fr0sT.Brutal said:

Clause "if arr = []" would be pretty obvious and consistent to string type

Fixed it for you:

const
  EmptyArray = nil;

var
  numbers: TArray<Integer>;
begin
  if numbers <> EmptyArray then
    Writeln('not empty');
end.

 

[Fr0sT.Brutal 900]

8 minutes ago, Stefan Glienke said:

Fixed it for you:

Are you using "if StringVar = EmptyStr" as well?

[Stefan Glienke 2002]

2 minutes ago, Fr0sT.Brutal said:

Are you using "if StringVar = EmptyStr" as well?

Nope, depending on the target version I am writing "if StringVar.IsEmpty" 😉

Edited September 27, 2021 by Stefan Glienke