Steven G. Johnson

I think this proposal saves so little typing, add adds little or no clarity, compared to explicit `x -> ...` that it doesn't seem worth it. The *only* point of...

> And that's exactly what the proposal is capable of. `->mapreduce(_,+,_,init=0)` imo is VERY clear The other PR (#24990) already supports `mapreduce(_,+,_,init=0)` with no `->` at all, which is even...

In that example the syntax of this PR saves you at most one character over `df |> filter(x-> x.age > 50, _)` ...

If you compare `df |> filter(-> ①.age > 50, ①)` to `df |> filter(x-> x.age > 50, _)` (tight underscore currying) you are saving 1 character. > I have absolutely...

Put another way, I don't see much point in discussing a new *completely general* anonymous-function syntax, which is what this `-> ①...` syntax is on the verge of becoming (it...

To me, there is no point in debating anything *other* than an implicit option, because explicit "fenced" options (like in this PR) will inevitably overlap too much with the current...

> Also, please stop focusing your "calculations" on single argument lambdas because these are handled in the other proposal Multi-argument lambdas are handled in the other proposal (or rather, in...

Put another way, "saving typing" is a proxy for the observation that for *very short* expressions, `x ->` and `->` add visual noise that impedes clarity. Compare `all(_ > 2,...

Regarding zero-ing everything, it wouldn't be too hard to change our `malloc_a16` function (in `gc.c`, which is used to allocate arrays) to a `calloc_a16` function, which called `calloc`, shifts the...

(@tknopp, you can always call `pointer_to_array(convert(Ptr{T}, c_malloc(sizeof(T) * n)), n, true)` or similar to get a `malloced` array, so I don't think we necessarily need a flag. Assuming the overhead...