I'm trying to do things like this:

Pike v7.7 release 21 running Hilfe v3.5 (Incremental Pike Frontend)

mapping m = ([]); m[*]->foo;

Compiler Error: 1:[*] on non-array.

I would expect the result to be an array containing every value in m's index foo.

Doesn't solve the same problem, does it?

Let's say we have

m=([ 1:([ "foo": 1]), 2:([ "foo": 2]), ]);

m->foo will then return 0. I would expect m[*]->foo to return ({ 1, 2 }).

I beg to differ. map() works just fine on mappings:

mapping m=([ 1:2, 2:3, 3:4 ]); map(m, lambda(mixed x) { return x*x; });

(1) Result: ([ /* 3 elements */ 1: 4, 2: 9, 3: 16 ])

You can perhaps argue that automap should also return a mapping, but I think it makes more sense to return an array in the case of the automap.

Yes, that does exactly what I want, but doesn't it feel like a misfeature that automap doesn't work for mappings?

you don't like automap, do you? care to explain how map(m, lambda(mixed x) { return x->foo; }); is any more obvious than m[*]->foo; ?

i am not discussing pers solution but i am comparing map and automap on mappings.

please tell me why map(m, lambda(mixed x){ return x->foo; }); is acceptable, while m[*]->foo; is not?

to me both are equally obvious/nonobvious

pers solution is of course much more obvious, but that is besides the point because that also applies to map(values(m), lambda(mixed x){ return x->foo; });

i don't care if automap handles mappings or not, i care that automap handles everything map does.

greetings, martin.

...

map(m, lambda(mixed x){ return x->foo; }); m[*]->foo;

Both are poor, but for different reasons. Don't use either of them.

different reasons? what difference? i only see the same reason for both.

greetings, martin.

Automap is bad because

A) it isn't integraded into the language except in a handful of cases B) no developer cares for it enough to fully work it into the language C) A+B keeps discussions respawning periodically, never resulting in neither A nor B changing, and, by implication, not C either

It's not bad enough to merit dropping from the language but aparrently not good enough to make anybody break the loop at B either. This is not likely to change without persons entering the flow chart at C taking a shot changing A with their own bare hands.

This overview is actually only satirical at the surface.

Like values(m)->foo?