Re: Adding support for xref jumping to headers/interfaces

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Tue, Nov 28, 2023, 17:25 Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 28/11/2023 19:16, João Távora wrote:
> > On Tue, Nov 28, 2023, 16:33 Dmitry Gutov <dmitry@gutov.dev
> > <mailto:dmitry@gutov.dev>> 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.

[-- Attachment #2: Type: text/html, Size: 2472 bytes --]