Add __traits isDynamicArray

[nordlow]

Partially resolves #23784.

I can split the PR up into two if requested.

Changelog will be updated if this gets approved.

Looking into failing tests.

[github-actions]

DMD perf check

Metric	Base	PR	Δ
dmd binary size (stripped)	6.86 MB	6.88 MB	+0.28%

All measurements

Metric	Base	PR	Δ
compile hello.d (instr)	215.1 M	215.1 M	-0.001%
compile hello.d -O -release (instr)	233.4 M	233.4 M	+0.002%
compile Phobos (instr)	5,120.6 M	5,120.5 M	-0.002%
compile Phobos codegen (instr)	1,472.4 M	1,472.4 M	-0.004%
compile vibe.d (instr)	15,112.9 M	15,112.0 M	-0.006%
dmd binary size (stripped)	6.86 MB	6.88 MB	+0.28%
hello binary size (stripped)	0.72 MB	0.72 MB	0.00%
peak RSS (compile hello.d)	43.50 MB	43.57 MB	+0.17%
peak RSS (compile Phobos)	620.5 MB	620.2 MB	-0.05%
peak RSS (compile vibe.d)	1918 MB	1917 MB	-0.03%
compile dmd itself (wall)	9.4 s	9.4 s	-0.02%
compile hello.d (wall)	50.8 ms	50.4 ms	-0.73%
compile Phobos (wall)	1,116 ms	1,115 ms	-0.04%

_{601e313 vs merge-base 86b74e2 · about these metrics}

[ntrel]

runnable/traits.d TEST_OUTPUT needs updating.

[dkorpel]

What's the rationale for isArray and why is an Associative Array not one?

[dkorpel]

From the issue

Please do not allow this trait to accept enums!

This PR's implementation accepts enums

[nordlow]

What's the rationale for isArray and why is an Associative Array not one?

Good point. I agree that isArray should be true for AAs.

Update: I removed isArray from this PR.

[nordlow]

From the issue

Please do not allow this trait to accept enums!

This PR's implementation accepts enums

Shouldn't we mimic the behavior __traits(isStaticArray, ...) in this case? Despite it accepting enums is a bad design.

And then later disallow all traits of this kind to not accept enums?

For the sake of consistency.

I'm ok with both alternatives.

[dkorpel]

Good point. I agree that isArray should be true for AAs.

That's not what I meant, I don't see why it needs to exist in the first place. What's the real world use case?

[nordlow]

Good point. I agree that isArray should be true for AAs.

That's not what I meant, I don't see why it needs to exist in the first place. What's the real world use case?

I don't know.

[nordlow]

compiler/test/run.d runnable/traits.d now passes locally for me.

[nordlow]

What's the rationale for isArray and why is an Associative Array not one?

Removed isArray changes from this PR.

[thewilsonator]

newline at end of file missing

[nordlow]

Done.

[Geod24]

Can't we do this with an is expression ?

[nordlow]

Can't we do this with an is expression ?

Yes, as seen in

template isDynamicArray(T)
{
    static if (is(T == U[], U))
        enum bool isDynamicArray = true;
    else static if (is(T U == enum))
        // BUG: isDynamicArray / isStaticArray considers enums
        // with appropriate base types as dynamic/static arrays
        // Retain old behaviour for now, see
        // https://github.com/dlang/phobos/pull/7574
        enum bool isDynamicArray = isDynamicArray!U;
    else
        enum bool isDynamicArray = false;
}

So this addition is for conformity with the existing builtin traits isStaticArray and isAssociativeArray.

The behavior of supporting enums for all the builtin traits is...Array might not be the preferred default. But we copy the behavior of the builtin isStaticArray for, again, conformity.

Note, that long-term I would like increase convenience of builtin traits by somehow making them referreable to as identifiers and passable as alias parameters.