Feature request: `@get` for Short-circuiting version of `get`

[Beforerr]

Maybe we could have a short-circuiting version of get? If it is desirable, I would be glad to make a PR

MWE

"""
    @get(collection, key, default)

Short-circuiting version of [`get`](@ref). See also [`@something`](@ref).
"""
macro get(collection, key, default)
    val = gensym()
    quote
        $val = get($(esc(collection)), $(esc(key)), nothing)
        !isnothing($val) ? $val : $(esc(default))
    end
end

Benchmark

d = Dict(1=>"1")

f1(d) = get(()->rand(1), d, 1)
f2(d) = get(d, 1, rand(1))
f3(d) = @get(d, 1, rand(1))

julia> @b d f1, f2, f3
(4.145 ns, 16.143 ns (2 allocs: 64 bytes), 3.653 ns)

[CameronBieganek]

I think the get(f, collection, key) method already covers the lazy case. The something function, on the other hand, does not have a method accepting a function (and it wouldn't really make sense to have one), so it makes sense to introduce @something.

But we could probably improve the docstring to make the intended usage more clear. Some time ago, I added the get_squares! example to the get!(f, collection, key) docstring in order to indicate what you can do with that method, though even that example could probably be improved a bit...

---

Side Note:

get(f, collection, key) should actually be called getwith, in analogy to mergewith. The reason is because get currently has two very different behaviors that depend on the types of the arguments. In order to facilitate generic programming, there should only be one behavior per arity of a function.

To elaborate, the behavior of get(a, b, c) depends on whether a is a Union{Function, Type}. This also prevents using the get(f::Union{Function, Type}, collection, key) method when the first argument is a callable object (i.e. not a Function or Type).

[Beforerr]

Hi @CameronBieganek ! Thanks for the response! Just to clarify, the macro serves two purposes: (1) it maintains the same interface as get(a, key, default) for readability, and (2) it still performs faster than get(f, collection, key) in benchmarks (as shown above). So it’s not just about laziness, but also a small win in clarity and performance.

[KristofferC]

it still performs faster than get(f, collection, key) in benchmarks (as shown above). So it’s not just about laziness, but also a small win in clarity and performance.

Why is it a win in clarity? And what causes it to be faster? It should do the same thing in the end?

[Beforerr]

Clarity may be a personal taste. I feel like @get(d, 1, rand(1)) is more similar to get(d, 1, rand(1)) compared to get(()->rand(1), d, 1). Forget about the benchmark (not right), performance is a little worse. Then this is just a syntax thing...