On Tue, Nov 28, 2023, 17:25 Dmitry Gutov wrote: > On 28/11/2023 19:16, João Távora wrote: > > On Tue, Nov 28, 2023, 16:33 Dmitry Gutov > > wrote: > > > > Being able to rename, or change arguments, or split into several, or > > severely rework, are all benefits of using internal functions, which > > are > > thus taken away. > > > > > > No. And you can't come up with an actual scenario that reveals a problem > > you wouldn't have when compared to a function interface. > > I said that introducing a macro requires a public function anyway. > Just because you said it doesn't mean it's true. It's not, that's not required at all. Again, you can't come up with a real upgrade scenario where the technique I presented is in any way more problematic than a normal function interface. Look, I don't care about xref anymore, I'm really just defending this technique from your so far 100% unsubstantiated discredit because it's really a standard watertight technique for presenting macros to a library's user, and I'd like people here to be aware of it, so the usual problems of call site recompilation become things of the past. I've used it tens of times, and seen it used many more. It's also known as the "CALL-WITH" idiom. The only situation where it "fails" is when you're using macros for speed, which functions don't give you anyway, and the indirection negates that. And you rarely should be using macros for that reason anyway, certainly not in these types of interfaces.