fast/short array creation syntax

[determin1st]

any ideas of making fast array creation/fill syntax?
here is the target javascript code:

Array(n).fill(x)

where n is the number of elements, and x is the fill value. maybe:

[n of x]

[ceremcem]

Possible complications of introducing a new syntax might be upheld by "you may ignore it if you find it unhandy" claim, but eventually it will concern every one of us because we eventually will have to read someone else's code.

The richest "language" regarding to the "shorthand" is possibly the RegEx. It's considered as a "write-only language".

So, I prefer not to have it at all. That's of course only my idea.

[vendethiel]

Isn’t that just [x] * n?

[determin1st]

@vendethiel

works well when n is given straight and small, but:

repeatArray$([x], n);
function repeatArray$(arr, n){
  for (var r = []; n > 0; (n >>= 1) && (arr = arr.concat(arr)))
    if (n & 1) r.push.apply(r, arr);
  return r;
}

Isn't it way too arcane? :]
Actually my "use-case" is zero-fill array with a small, but unknown length..

@ceremcem

how do you create and fill/initialize array?

PS: oh, it's actually in the docs, operators -> List section.. didn't know

[rhendric]

In a version of LiveScript that assumed (or was instructed to have) an ES6 target, I think it could make sense to optimize specifically [x] * n to Array(n).fill(x). I wouldn't want there to be another syntax that overlaps with the existing one in functionality.

Absent such a version of LiveScript, this doesn't seem that important to do; writing Array n .fill x yourself isn't bad, if you care enough about the efficiency of your code to want that. It has the advantage of being crystal clear both about what it's doing and about what it requires from the runtime; the only cost is eight more characters.

[determin1st]

@rhendric

So you mean that LiveScript should be upgraded to have some compile option that enables higher JS/ES runtime versions first?

[rhendric]

I'm not saying such a compile option would necessarily be a good idea. (A while back there was some talk about integrating LiveScript with Babel (#821), which I think would be a better approach for targeting more modern runtimes.)

But to take a compilation that targets ES5 (or is this even ES3?) and change it to only run on ES6 is more breaking than I want to do without some sort of a bigger plan for ES6+ support in general. If such a plan ever comes into play, I think I'd be happy for this optimization to be a part of it.