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

On Friday, 25 November 2016 at 14:27:39 UTC, Igor Shirkalin wrote:
> On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:
>>> We can define static array without counting the elements as following:
>>>
>>>
>>> enum array_ = [1u,2,3,4];
>>> uint[array_.length] static_array = array_;
>>
>> there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-)
>
> I think you may write it (I mean actual D) with using some template like this:

yeah. but i'm not Andrei, i don't believe that the only compiler task is to resolve templated code. ;-) i.e. Andrei believes that everything (and more) should be moved out of compiler core and done with library templates. Andrei is genius, for sure, but he is living somewhere in future, where our PCs are not bound by memory, CPU, and other silly restrictions. ;-)

tl;dr: using template for this sux.

On 11/25/16 18:33, Jonathan M Davis via Digitalmars-d-learn wrote:
> 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.

It's a known language limitation, which can be worked around using hacks such as the one I showed, that help in the very common cases that appeared in this thread, add zero RT costs and work with VRP. I didn't realize you were suggesting to use the function helper route for the general case - no scope change, sorry.

> 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.

The problem with such a function is that, just like every other function, it's type can not depend on RT data, and that `typeof([1,a])` is `int[]`. The information is lost at the function boundary. So the possible improvements are a) changing the array literal semantics, and b) improving IFTI.

> 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]);

IOW you want to improve IFTI, so that `n` is inferred from the
length of the passed argument. That would indeed work for array
literals and CTFE-able expressions. Any improvement to IFTI is a
good thing, but the RT cost of this helper could be high if it ever
doesn't get inlined and completely optimized away.
If the cost isn't an issue and a different syntax is acceptable
then this should already work:

   template staticArray(T, E...) {
      T[E.length] staticArray() @property { return [E]; }
   }
   template staticArray(E...) {
      typeof([E][0])[E.length] staticArray() @property { return [E]; }
   }

   ubyte a;
   auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
   auto sb = staticArray!(1, 2, 3, 4, a);

artur

On Saturday, November 26, 2016 00:43:04 Artur Skawina via Digitalmars-d- learn wrote:
> IOW you want to improve IFTI, so that `n` is inferred from the length of the passed argument. That would indeed work for array literals and CTFE-able expressions. Any improvement to IFTI is a good thing, but the RT cost of this helper could be high if it ever doesn't get inlined and completely optimized away.

That's what pragma(inline, true) is for. And if someone wants a different solution that's completely compile-time and doesn't work with variables, then fine. I'm talking about adding something to the standard library, and for that, I think that a solution that is as close as possible to being identical to simply declaring the static array with the length is what would be appropriate.

> If the cost isn't an issue and a different syntax is acceptable then this should already work:
>
>    template staticArray(T, E...) {
>       T[E.length] staticArray() @property { return [E]; }
>    }
>    template staticArray(E...) {
>       typeof([E][0])[E.length] staticArray() @property { return [E]; }
>    }
>
>    ubyte a;
>    auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
>    auto sb = staticArray!(1, 2, 3, 4, a);

I'm not married to the syntax. I tried that syntax, but I couldn't figure out how to get it to work with runtime values. The closest that I could come up with was what I showed before, and the fact that IFTI wasn't smart enough with VRP was the only blocker. It looks like you've found a way to do it with all template arguments though, which is fine with me.

- Jonathan M Davis

On Monday, 28 November 2016 at 16:15:23 UTC, Jonathan M Davis wrote:
> That's what pragma(inline, true) is for. And if someone wants a different solution that's completely compile-time and doesn't work with variables, then fine. I'm talking about adding something to the standard library, and for that, I think that a solution that is as close as possible to being identical to simply declaring the static array with the length is what would be appropriate.
>
>>...
>
> I'm not married to the syntax. I tried that syntax, but I couldn't figure out how to get it to work with runtime values.
>
Can I insert my own opinion about static arrays with programmers' unknown size?
Being the practical developer I can't imagine the situation where it is really needed. I hope D is not for theoretical goals only but for practical ones first.
If we know the size of our future array we tell that to the compiler. If we don't know the size of our future static array we write an external generator to produce that. I really don't know places where I want static array to be unknown size inline (perhaps, except for debugging purposes). Concluding, the designer knows he's achived the perfection if there is nothing to remove, but not to add.

Igor Shirkalin

On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote:
> That was preface.
> Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used.
> I have the same text in russian, but who has bothered russian(s)?
> The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it.
>
> p.s. I'm excused for my primitive english.

how much money did you earn using D language?

On Saturday, 3 December 2016 at 15:02:35 UTC, eugene wrote:
> On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote:
>> That was preface.
>> Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used.
>> I have the same text in russian, but who has bothered russian(s)?
>> The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it.
>>
>> p.s. I'm excused for my primitive english.
>
> how much money did you earn using D language?
I didnt count, but its about ten thousend a year, i.e. nothing. You earn ten times more of me. Ask me enything more.

On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote:
> I didnt count, but its about ten thousend a year, i.e. nothing.

if you earned nothing using D language why do you recommend it?)))
People usually earn money using programming langs.

On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote:
> On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote:
>> I didnt count, but its about ten thousend a year, i.e. nothing.
>
> if you earned nothing using D language why do you recommend it?)))
> People usually earn money using programming langs.
some people have nothing about science. Some of them are god's addicted. I don't think D is here. We are out of here. We should go to facebook and keep here if you take it. that's it.

On Monday, 5 December 2016 at 17:27:21 UTC, Igor Shirkalin wrote:
> On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote:
>> On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote:
>>> I didnt count, but its about ten thousend a year, i.e. nothing.
>>
>> if you earned nothing using D language why do you recommend it?)))
>> People usually earn money using programming langs.
> some people have nothing about science. Some of them are god's addicted. I don't think D is here. We are out of here. We should go to facebook and keep here if you take it. that's it.

I think we have to stop.