[broken] Support TypeQual(TypeSeq)

[ntrel]

First commit for immutable(TypeSeq) seems to work.
Second commit for const(TypeSeq) gets a bizarre result when indexed (see test).
Any ideas why/alternative suggestions?

[dlang-bot]

Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	22189	critical	type qualifier not applied to type tuple

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16439"

[ntrel]

this line actually fails too:

compilable/type_seq_qual.d(12): Error: static assert:  `is(const(int) == const(int))` is false

[atilaneves]

What is the point of an immutable AliasSeq?

[ntrel]

@atilaneves AFAIK a type sequence is a type. So without an implementation of this, do you think it's better to have a special case in the type system, that only type sequences can't have a type qualifier?

[atilaneves]

@atilaneves AFAIK a type sequence is a type. So without an implementation of this, do you think it's better to have a special case in the type system, that only type sequences can't have a type qualifier?

Compile-time programming is all immutable anyway. What am I missing?

[jmdavis]

@atilaneves AFAIK a type sequence is a type. So without an implementation of this, do you think it's better to have a special case in the type system, that only type sequences can't have a type qualifier?

Compile-time programming is all immutable anyway. What am I missing?

You can use the result of an AliasSeq to do stuff like declare variables, e.g. this fails right now, because the const is lost:

    import std.meta;
    alias Seq = AliasSeq!(int, float, string);
    alias CSeq = const Seq;

    CSeq[0] a;
    static assert(is(typeof(a) == const int));

    CSeq[1] b;
    static assert(is(typeof(b) == const float));

    CSeq[2] c;
    static assert(is(typeof(c) == const string));

So, if it doesn't work to use type qualifiers on an AliasSeq, that can cause problems, particularly with code generating types by doing type introspection and manipulating the results.

This may also relate (I'm not sure) to https://issues.dlang.org/show_bug.cgi?id=24516, which shows that type qualifiers get lost when aliasing the result of tupleof, which causes problems with stuff like templated traits, since they have to use alias for their result when operating on symbols or types.