Implement resize!(...; first=true)

[ameligrana]

Fixes #26326

[ameligrana]

Actually there is not a lot of consensus on the name in #26326. The options nonetheless could be maybe:

• resizefirst!(a, n)
• resize!(a, n, p) where p indicates where the resize! should start at, with 1 as resizefirst!, something similar to @StefanKarpinski comment

the second is also appealing, the first seems better to me because of simmetry with other functions e.g. pushfirst! and popfirst! as @oschulz pointed out. The options are actually also compatible in my opinion.

[LilithHafner]

IMO this is good functionality to publicize, tagging triage to discuss a new feature and to discuss naming.

[oscardssmith]

Triage thinks this should be spelled resize(... first=true) (to be consistent with the new sizehint! kwarg in 1.11), but we otherwise like it.

[ameligrana]

The failures seem unrelated, let me know if the implementation is okay now

[LilithHafner]

Looks pretty good, I left a few suggestions.

[LilithHafner]

IDK if an optimization that only applies when the resize amount is a multiple of 64 is actually worth implementing, especially if the resulting performance quirk is not documented.

[ameligrana]

IDK if an optimization that only applies when the resize amount is a multiple of 64 is actually worth implementing, especially if the resulting performance quirk is not documented.

to me it seems possibly good because someone interested in such a performance optimization (consider that the optimized version is orders of magnitudes faster than the other) would probably look at the implementation of resize! and try to adapt the code to exploit it

[ameligrana]

Also, it seems possible to me to apply this optimization for any n but it requires more global changes (which I'm not sure if they will slowdown other parts of the code though), so this could be the easiest step without perf overhead of that direction

[ameligrana]

If someone else has any opinion on the bitvector optimization I'd like to hear you, so that we decide to keep it or not, I think that it is a good idea but @LilithHafner disagrees (at least a bit)

[DilumAluthge]

This PR has had no activity for over six months.

@ameligrana Are you still interested in working on this PR?

If you're no longer interested in working on this PR, no worries! Just let me know, and I can close it.

[ameligrana]

I think this just need to reach some consensus on some of the changes i.e. if keeping the bitarray optimization is worth it or not. I'll just wait some more to know what someone else thinks of it, and I'll split the PR into two if none intervenes

[ameligrana]

I remove the multiple of 64 optimization (will create a new PR with that) and fixed conflicts, so I think it should be ready to be merged