Match new Base destructuring syntax (aka the fate of this package)

[marius311]

Property destructuring was just merged into master 🎉 JuliaLang/julia#39285

Would be nice if this package allowed you to match that syntax, i.e. if in addition to the current form, it also allowed:

@unpack (;x, y) = foo

such that in the future one can upgrade by just dropping the @unpack.

[mauro3]

You're not wasting any time!

Yes, it would be good to have a transition strategy. Apart from your point, there is also the currently supported unpacking of string-key dicts (not sure what to do about those) and the @pack!. The latter really being a decision on whether keep this package or ditch it.

[tpapp]

I only use @unpack a, b = c from this package, so allowing @unpack (; a, b) = c would provide a smooth exit strategy that would eventually allow me remove @unpack with a string replace in an entire codebase.

A different name, eg @unpack_ could even error about any other syntax.

I was very fond of this package as it provided immensely useful functionality in a clean way, but now what 1.6 is LTS I don't see the need to use it any more.

[mauro3]

Thanks! Yes, I need to get this done...
Do note though that the unpack syntax only got into Julia 1.7. Thus you still need this for LTS.

[tpapp]

Thanks, I forgot that. In that case retiring this package can wait until the next LTS version of Julia. I don't see the need to do anything at this point.

[pdeffebach]

I really prefer writing @unpack a, b = x rather than (; a, b) = x

1. @unpack reads better. Its more explicit about what's going on.
2. I don't like having to close the right parenthesis. Pressing shift-( is annoying.

I would hope @unpack lives on, unchanged! Even though (;a, b) = x exists.

[tpapp]

Although I haven't gotten round to it, I think #18 is worth implementing. Other useful extensions may exist.

Base syntax is nice, but it is not meant to cover every use case.

[devmotion]

Somewhat related to the discussion in this issue, I just put together a very simple package today with an @unpack macro that uses the Base syntax when it is available and otherwise falls back to a block of getproperty statements: https://github.com/devmotion/SimpleUnPack.jl

The main motivation was SciML/OrdinaryDiffEq.jl#1893 which also discusses the impact that the number of specializations introduced by UnPack.@unpack, or rather UnPack.unpack, have. The version in SimpleUnPack only uses getproperty, as the Base destructuring syntax, and hence is less flexible but avoids these issues.

The reason to put it in a separate package rather than UnPack was that I wanted to make it simple for me to switch to the new macro and reduce the number of changes that I have to apply in my packages: Since the macro has the same name, one does not have to update every @unpack expression. I only came across #23 later, which made me wonder if this was the right decision (or maybe one could add a getfield version to SimpleUnPack?).