Allow creation of static arrays with new

[Biotronic]

Related to https://issues.dlang.org/show_bug.cgi?id=10879 and thus dlang/phobos#4204.

This PR simply allows the following code, which was previously illegal:

    alias T = int[10];
    auto a = new T;
    static assert(is(typeof(a) == int[10]*));

This code used to give the error "new can only create structs, dynamic arrays or class objects, not int[10]'s".

[yebblies]

This seems like a bad idea as long as we don't support new int[N].

[mathias-lang-sociomantic]

The problem is that different things will happen for auto foo = new int[10]; and auto foo = new T;.
This is down to the fact that new int[10] is rewritten as new int[](10).

[Biotronic]

@yebblies I am not unaware of the problem. For generic code though, it's ridiculous to have to special-case static arrays.

[mathias-lang-sociomantic]

@Biotronic : The correct approach IMO would be to correctly deprecate new[X] for newing dynamic arrays (deprecation, warning, error), then introduce the new syntax for newing static array.

[WalterBright]

Perhaps a DIP explaining the pros and cons? I agree with others that having an alias behave differently from a non-alias is surprising behavior and is the addition of another special case corner in the language. This should not be done lightly.

[AndrejMitrovic]

I'd be in favour of deprecating new[X] for dynamic arrays too. The question is how much code this could break (but dfix could easily handle this, no?).

I second the motion for a DIP and marking this as blocked until a decision is made.

[wilzbach]

WB: Perhaps a DIP explaining the pros and cons?
AM: I second the motion for a DIP and marking this as blocked until a decision is made.

@Biotronic in case you missed it. Since a couple of weeks there is a new DIP process in place - see also this blog post about it. How about going through it, working out a DIP and making a change? :)

[JinShil]

It doesn't look like this PR has a future. Alternatives seem to be preferred, and those alternatives will need a DIP and a different PR. I suggest this be closed; any objections?

[wilzbach]

Alternatives seem to be preferred, and those alternatives will need a DIP and a different PR. I suggest this be closed;

Agreed.