the best language I have ever met(?)

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, November 25, 2016 18:20:11 Artur Skawina via Digitalmars-d-learn 
wrote:
> On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Friday, November 25, 2016 17:03:32 Artur Skawina via
> >>    enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
> >>    auto arr = staticArray!(ubyte, [1, 2, 3, 4]);
> >
> > That won't work with variables. e.g.
> >
> > ubyte a;
> > auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);
> >
> > would fail to compile. It only works when all of the values are known at
> > compile time, whereas
> >
> > ubyte a;
> > ubyte[5] arr = [1, 2, 3, 4, a];
> >
> > would compile just fine.
>
> Now you're trying to change the scope. Of course this is a hack,
> that's only useful in certain contexts, such as initializing static
> arrays with known values, which this subthread is about.

How is it changing the scope? What has been asked for on several occasions -
and what int[$] was supposed to fix - was the ability to intialize a static
array while inferring its size.

ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];

is a perfectly legitimate example of initializing a static array, and
there's no reason why it shouldn't be a goal to have it work with a function
that infers the size of the static array.

> It actually makes the source code (look) worse; having to use lots of
> such module- or project-local hacks doesn't scale, and is a symptom
> of language problems.
>
> The point, however, was that that is the only way to get VRP - the
> values must be available at CT for VRP to work effectively.
> Your suggestion to "fix" VRP would break CTFE (different implicit
> conversions would be allowed at CT and RT) and could result in
> code compiling or not depending on the function arguments used,
> possibly in a very unintuitive way (eg depending on if the function
> args values happened to be CTFE-able).

We'd actually have it right now with

T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
    return arr;
}

except that VRP only works right now if no inferrence is done when
instantiating the template.

auto sa = staticArray!(ubyte, 4)([1, 2, 3, 4]);

compiles just fine, but that obviously defeats the purpose of the template.
If the compiler is improved so that

auto sa = staticArray!ubyte([1, 2, 3, 4]);

also works with VRP, then everything works just like it would with

ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];

except that with the function, the size would be inferred.

ubyte a;
auto arr = staticArray!ubyte([1, 2, 3, 4, a]);

And until

https://issues.dlang.org/show_bug.cgi?id=16779

is fixed, the above definition of staticArray works perfectly fine except
for the fact that you lose out on VRP. And once 16779 is fixed, we have a
complete solution, whereas any solution that would currently work with VRP
permanently loses out on being able to have any variables used in
initializing the array.

- Jonathan M Davis