Adding an attribute for something that specific (I doubt anyone but PE players would use it) really sounds like unneeded bloat. Especially when you can use a sub that hides your hated || 0 or, as jettero said, when you can already use a tied array.

Adding an attribute for something that specific (I doubt anyone but PE players would use it) really sounds like unneeded bloat.

That is not the point. Perl's realm lies in pragmatics and certainly not only PE players could be interested in such a thing as you can judge from the feedback from other people who replied to my root node. The feature would be useful in some situations like the one I described, e.g. with mathematical usages: of course Perl is not the most typical language in that case but again it's practical and there's no reason why it shouldn't be used in that area too.

Indeed the feature I long for has not been there for ages and people could happily live without it so it's not strictly necessary. Still I fail to see how could it be "bloat": you would only use it if needed and otherwise happily ignore it or even ignore its existence altogether.

Especially when you can use a sub that hides your hated || 0 or, as jettero said, when you can already use a tied array.

Except that hinding the thing in a sub would not make the syntax terribly more elegant and sub call in Perl is terribly slow anyway: for mathematical usages (and not only) this may matter. Granted, if one is terribly concerned about speed then she should go with another language altogether, but Perl is still useful for fast prototyping, and making the beast unnecessarily slow is what I see as "bloat". Thus you can:

go fast with tricks and inelegant, clumsy syntax;

go slower with a trick like the sub and a cleaner, more intuitive syntax;

The same can be said of jettero's tied arrays, the suggestion of which I reckon to be more a proof of concept than a "use this instead", thus anyway you look at this there's no reason not to desire a beast that would give you the best of both points above in one shot. This is not to say that my suggestion will be readily implemented just because I said that... I was and I still am talking in line of principle.

Attributes are a recent addition to Perl and their support is largely incomplete, but they are a powerful means. The point is I stumbled into a situation in which any solution with current syntax and semantics left you with a slight flavour of dissatisfaction in your mouth. Admittedly, in my experience that is not a common situation and I do not expect it to be, but it can happen. Making what's practical even more practical and what's good even better is certainly worth.

Still I fail to see how could it be "bloat": you would only use it if needed and otherwise happily ignore it or even ignore its existence altogether.

The point of TIMTOWTDI is to offer different sensible ways to achieve the same goal. I fail to see how your proposition offers something that can be generally used. If we were to add every little feature X or Y dream of, Perl would be called PHP.

Except that hinding the thing in a sub would not make the syntax terribly more elegant...

That's just personal taste, but I yet again fail to see how could it not be clearer, since you trade $a[$_] || 0 for a($_).
And if you like to think in "mathematical" terms, a sub is much closer to a sequence than an array.

Perl is still useful for fast prototyping, and making the beast unnecessarily slow is what I see as "bloat"

If you're so concerned about speed, you shouldn't use Perl arrays to begin with, since they are very wasteful on space. Either make your own "sequence" data structure in XS or use a module that already exists (maybe PDL ?).

But that's definitely not something everyone would need shipped with his perl.

The point of TIMTOWTDI is to offer different sensible ways to achieve the same goal. I fail to see how your proposition offers something that can be generally used. If we were to add every little feature X or Y dream of, Perl would be called PHP.

Curiously enough you may think that I am one of those who would like to "add every little feature X or Y dream of", but evidence is that I am not. An example that springs to mind is a recent clpmisc discussion in which someone contended that a trim() function to trim whitespace in front and at the end of a string "should be added in core". For me

It is not in contrast with either TMTOWTDI nor with Perl philosophy altogether to add sensible new features especially where current ones are still somewhat lacking and force you to something clumsy and awkward as a workaround.

Comparing my "proposal" with PHP is somewhat of bending the truth, for there's a relevant difference between adding a little bit of unobtrusive semantics and bloating the main namespace with just so many little functions that could be built out of a tiny number of smaller pieces, which is what happens with that language, if I understand correctly.

But that's definitely not something everyone would need shipped with his perl.

Definitely! And I never intended to claim the contrary. It's also definitely something no one should be bothered seeing shipped with her perl. It's something that at least five out of eight partecipants to this thread seemed to receive very positively, while other two didn't express any disliking, simply providing examples of how to get something similar with existing perls. Also, I'm not intending to boast the node reputation, but it indicates that quite a lot of people who didn't followup did like it too.

Anyway, I'm not trying to conVince you. We simply have different views on this particular issue. And anyway we're discussing about something that is most probably not going to be implemented in any case, so we can end it up here.