About built-in macros, both old and new

I recently discussed about having some sort of shorthand to get the last member of a tuple, which requires needing to know the tuple's length and somehow pasting the last index. I eventually thought of a macro, but actually constructing it needs paste objects both at the token level and the expression level, which Swift macros can't do because they're hygienic. I'm going to experiment with the Mirror facility, but at the end of the day, the only efficient way to do this is with a new built-in macro.

After my experiments, I'll try writing a proposal.

Previous chapters:

1 Like

The sequence of words "built-in macro" raises a question... why macro? Maybe it could be just a built-in language feature. Especially if it can't be implemented with the macro system as of now.

Regardless of how it's implemented – I'd love to see an ability to have count and subscript by index implemented on tuples.

Would the changes in 0408 help? You have a concrete tuple… but a helper function that accepts a parameter pack could use the new support for iteration to return the last element? I see a "forward" iterator documented… but there might be a shortcut to iterate in reverse (and then just exit the iteration after the last element returns).

As you suggested, unless there's a reverse capability, this method would be O(n), which is exactly what I want to avoid.

The core problem is that the tuple index syntax works manually, but automation needs a expression on the left side of the period but a token on the right side, which neither macro nor non-macro techniques can handle; the components are from different stages of the compiling process. We have all the pieces, we know in our minds how to put them together, but the compiler isn't designed for that (unless your reverse-trick can actually work); the combing procedure is only doable with compiler magic, since it can cheat to combine entities from different levels.