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.

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.

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.

On Friday, 10 July 2020 at 08:15:24 UTC, Max Samukha wrote:

> a unfortunate
an unfortunate

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.

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