www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Send empty assoc array to function

reply JN <666total wp.pl> writes:
void foo(int[int] bar)
{
     // ...
}



Is it possible to send an empty array literal?

foo( [ 0 : 2 ] ) works
foo( [] ) doesn't

int[int] empty;
foo(empty);
works but it's two lines
Jul 09 2020
next sibling parent reply JN <666total wp.pl> writes:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:

 void foo(int[int] bar)
 {
     // ...
 }



 Is it possible to send an empty array literal?

 foo( [ 0 : 2 ] ) works
 foo( [] ) doesn't

 int[int] empty;
 foo(empty);
 works but it's two lines


Hmm, foo(null) seems to work, but is it correct way to do it?
Jul 09 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/9/20 4:04 PM, JN wrote:

 On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:

 void foo(int[int] bar)
 {
     // ...
 }



 Is it possible to send an empty array literal?

 foo( [ 0 : 2 ] ) works
 foo( [] ) doesn't

 int[int] empty;
 foo(empty);
 works but it's two lines


 
 Hmm, foo(null) seems to work, but is it correct way to do it?
 


Yes, that is correct.

-Steve
Jul 09 2020
next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer 
wrote:


 Yes, that is correct.

 -Steve


Why isn't [] accepted as an empty AA literal?
Jul 09 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/9/20 4:31 PM, Max Samukha wrote:

 On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote:
 

 Yes, that is correct.


 
 Why isn't [] accepted as an empty AA literal?


Because it's an empty dynamic array literal.

If D were to accept an empty AA literal, I'd expect it to be [:].

-Steve
Jul 09 2020
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 9 July 2020 at 21:04:57 UTC, Steven Schveighoffer 
wrote:


 
 Why isn't [] accepted as an empty AA literal?


 Because it's an empty dynamic array literal.

 If D were to accept an empty AA literal, I'd expect it to be 
 [:].

 -Steve


Just as typeof(null) is a subtype of all nullable types, you 
could make typeof([]) a subtype of both AAs and dynamic arrays. 
[:] could still be made a specifically AA literal.

BTW, writeln((int[int]).init) prints "[]" (to!string((V[K]).init) 
== "[]"), but pragma(msg, (int[int]).init) - the more general 
'null' ((V[K]).init.stringof == "null"), which is a unfortunate 
inconsistency.
Jul 10 2020
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 10 July 2020 at 08:15:24 UTC, Max Samukha wrote:


 a unfortunate


an unfortunate
Jul 10 2020
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/10/20 4:15 AM, Max Samukha wrote:

 On Thursday, 9 July 2020 at 21:04:57 UTC, Steven Schveighoffer wrote:
 

 Why isn't [] accepted as an empty AA literal?


 Because it's an empty dynamic array literal.

 If D were to accept an empty AA literal, I'd expect it to be [:].


 
 Just as typeof(null) is a subtype of all nullable types, you could make 
 typeof([]) a subtype of both AAs and dynamic arrays. [:] could still be 
 made a specifically AA literal.


Sure it's possible. But I don't see it happening.


 
 BTW, writeln((int[int]).init) prints "[]" (to!string((V[K]).init) == 
 "[]"), but pragma(msg, (int[int]).init) - the more general 'null' 
 ((V[K]).init.stringof == "null"), which is a unfortunate inconsistency.


to!string is from the library, pragma(msg) is the compiler. The latter 
is authoratative where the compiler is concerned.

to!string probably should be changed. [] should be printed for 
initialized but empty AAs, null should be printed for .init.

-Steve
Jul 10 2020
prev sibling parent reply JN <666total wp.pl> writes:
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer 
wrote:

 On 7/9/20 4:04 PM, JN wrote:

 On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:

 void foo(int[int] bar)
 {
     // ...
 }



 Is it possible to send an empty array literal?

 foo( [ 0 : 2 ] ) works
 foo( [] ) doesn't

 int[int] empty;
 foo(empty);
 works but it's two lines


 
 Hmm, foo(null) seems to work, but is it correct way to do it?
 


 Yes, that is correct.

 -Steve


Interesting. Often in D discussion, an argument pops up that the 
language should be protecting against hidden breakages from API 
changes. This would be an example of that happening.

void foo(int[int] bar), someone calls it with a null, suddenly 
the signature changes to void foo(int* bar) and you will be 
sending a null pointer and possibly breaking the app.
Jul 09 2020
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/9/20 5:13 PM, JN wrote:

 On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote:

 On 7/9/20 4:04 PM, JN wrote:

 Hmm, foo(null) seems to work, but is it correct way to do it?


 Yes, that is correct.


 
 Interesting. Often in D discussion, an argument pops up that the 
 language should be protecting against hidden breakages from API changes. 
 This would be an example of that happening.
 
 void foo(int[int] bar), someone calls it with a null, suddenly the 
 signature changes to void foo(int* bar) and you will be sending a null 
 pointer and possibly breaking the app.


This is a stretch.

This means you NEVER call it with an actual associative array (Which 
would fail to compile), and that foo never expects to get a null 
pointer. Even if it does break, it breaks by segfaulting and not 
corrupting your program.

All this, plus the author of foo cares nothing for his users, who now 
suddenly have non-compiling code.

-Steve
Jul 09 2020
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:


 Interesting. Often in D discussion, an argument pops up that 
 the language should be protecting against hidden breakages from 
 API changes. This would be an example of that happening.

 void foo(int[int] bar), someone calls it with a null, suddenly 
 the signature changes to void foo(int* bar) and you will be 
 sending a null pointer and possibly breaking the app.


Meh. You could say the same about foo(int[]), or foo(SomeClass). 
AAs are reference types. Reference type instances can be null.
Jul 09 2020
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 10 July 2020 at 03:59:37 UTC, Mike Parker wrote:

 On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:


 Interesting. Often in D discussion, an argument pops up that 
 the language should be protecting against hidden breakages 
 from API changes. This would be an example of that happening.

 void foo(int[int] bar), someone calls it with a null, suddenly 
 the signature changes to void foo(int* bar) and you will be 
 sending a null pointer and possibly breaking the app.


 Meh. You could say the same about foo(int[]), or 
 foo(SomeClass). AAs are reference types. Reference type 
 instances can be null.


Besides, when it comes to breakage, the discussions I've seen are 
about breaking changes in the language/compiler. There are 
opportunities in most (if not all) programming languages to 
introduce silent breakage when a library maintainer changes a 
public-facing API. And when it happens, that's not the fault of 
the language, but the library maintainer.
Jul 09 2020
prev sibling parent JN <666total wp.pl> writes:
On Friday, 10 July 2020 at 03:59:37 UTC, Mike Parker wrote:

 Meh. You could say the same about foo(int[]), or 
 foo(SomeClass). AAs are reference types. Reference type 
 instances can be null.


Oh, that actually makes sense. I always thought assoc arrays are 
value types.

Anyway, even if they are reference type, I still would consider 
[] and null different types of values. [] conveys to me that the 
object exists, but is empty. null conveys to me that the object 
exists and cannot be used.

int[int] a = null;
a[5] = 6;

This kind of code just looks weird... yes, I know the " = null " 
part is excessive, but still.
Jul 10 2020
prev sibling next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:


 foo( [] ) doesn't


Should work in principle, but you can foo(null) to work around.
Jul 09 2020
prev sibling parent reply Anonymouse <zorael gmail.com> writes:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:

 void foo(int[int] bar)
 {
     // ...
 }



 Is it possible to send an empty array literal?

 foo( [ 0 : 2 ] ) works
 foo( [] ) doesn't

 int[int] empty;
 foo(empty);
 works but it's two lines


I always did foo((int[int]).init);
Jul 09 2020
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 9 July 2020 at 20:08:47 UTC, Anonymouse wrote:

 On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:

 void foo(int[int] bar)
 {
     // ...
 }



 Is it possible to send an empty array literal?

 foo( [ 0 : 2 ] ) works
 foo( [] ) doesn't

 int[int] empty;
 foo(empty);
 works but it's two lines


 I always did foo((int[int]).init);


Isn't that just 'null'.

I want to make note that you cannot pass null, modify the aa, and 
expect the parent stack to see those changes. Since you aren't 
using a variable that is null you are fine.
Jul 09 2020