decouple kwargs performance improvement from API changes

[vtjnash]

This undoes the breaking API change introduced by #24795 (fixing #25177), while keeping the performance / inference improvement. This lets us develop the kwargs API independent of Core.NT, for example, to provide proper deprecations for future changes, specific error messages, and work towards possible future development of NT (for example, implementing it as just another normal type in Julia, rather than requiring a special cases in the runtime).

[JeffBezanson]

Maybe we should move IndexValue to its own file?

[vtjnash]

We could, but seemed useful enough to be able to call pairs (required Zip) and generator Filter and we may want to use the Product iterator for Cartesian arrays, so I’ve wanted this file before anyways.

[JeffBezanson]

I think this is fine, for the sake of fixing #25177. That covers the most noticeable API change, but there are still other breaking API changes --- kwargs not being a vector --- but I think those are fine and should stay. I just want to be clear that the performance and API changes are not completely de-coupled.

[bramtayl]

I've updated https://github.com/bramtayl/Keys.jl master for 0.7 to take advantage of dot overloading and constant progogation (it also requires the master version of RecurUnroll). It provides a named tuple implementation that

• Is fully type-stable
• Requires no generated functions
• Requires no compiler modifications
• No macros
• Requires no Vals
• Allows for constant propagation (unlike the base implementation of named tuples). This seems essential making keyword arguments useful.

[vtjnash]

That seems interesting. What do you mean by "allows constant propagation"?

[bramtayl]

Hmm, wait, maybe I was confused about that.

I was looking at

test() = KeyedTuple(; a = 1, b = 2.0).a
@code_warntype test()
# return 1

But this seems to work with named tuples as well:

test() = (a = 1, b = 2.0).a
@code_warntype test()
# return 1

I thought I had read somewhere that constant propagation doesn't survive named tuples?

[bramtayl]

#25188 (comment)

[vtjnash]

I thought I had read somewhere that constant propagation doesn't survive named tuples?

Here's an example of that:

test() = (a = 1, b = 2.0).a + 1

[bramtayl]

Hmm, I see basically identical generated code to

test() = KeyedTuple(; a = 1, b = 2.0).a + 1

It seems like it propagates up to

SSAValue(67) = (Base.add_int)(1, 1)::Int64
return SSAValue(67)

[JeffBezanson]

Will constant prop work here? I thought it was only enabled for getproperty currently.