What does 'inline' mean?

[Manu]

On Sat, Jun 13, 2020 at 11:31 AM Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 6/11/2020 6:55 PM, Manu wrote:
> >     We're not talking about templates.
> >
> > This is another one of those cases is really bizarre resistance to what
> seems
> > like a blindingly obvious thing.
> > Can you please explain why you feel opposed to this, and why our
> existing
> > solution, which is 'weird' by all accounts, and satisfies ZERO of the
> goals
> > assigned to inline is preferable?
>
> Specifying solutions without explaining what the problem is means I will
> never
> understand what you want. For example, I had to keep saying why? why? why?
> to
> you over several posts before you finally said what you wanted was a
> header only
> library.
>

I felt like my OP was really clear. I identify 3 use cases for inline, and
then commented on their level of importance.
I've answered your "why"s so many times.

#1 why? - users don't want "undefine symbol" link errors (C++ calls this
'inline')
#2 why? - users want to add a hint to override the optimisers
judgement (C++ calls this `__forceinline` among various others, completely
non-standard, but useful)
#3 why? - we rarely absolutely MUST inline, and we want an error if we
can't (C++ doesn't have this at all. It's useful for preserving features of
the calling context)

I show you how you can do that with existing D, along with an existing,
> working
> solution.
>

Templates are not a solution, they're a weak workaround which I'm
completely aware of. This thread exists because we don't want that
workaround.
Templates are not functions, and inserting a template into any generic code
where a function is expected leads to a sea of edge cases.

Then you say you're not talking about templates.
>

Because we're not talking about templates. Functions are _functions_, they
have a lot of semantic differences from templates.

Hence I still don't know what problem(s) you are having, as I have no idea
> why
> templates are no good for you.


We don't satisfy any of the 3 key goals in my OP.
After reading the various responses in this thread, I could rewrite that
post to be clearer, but I really didn't feel it was that unclear in the
first place.


> > The existing implementation is inline is a COMPLETELY useless thing.
>
> I use it, and it's not useless.
>

I'm not aware that I've ever wanted inline for any reason other than those
3 points I described. I invited others to add their own use cases if I was
missing some.
You're welcome to add a use case showing how you'd like to use inline...
but it doesn't implement any of my use cases today.

I suggest coming up with a complete list of what problems you are trying to
> solve, not a list of proposed solutions.
>

I have, that's the OP.

BTW, the pragma(inline) came out of a conversation you & I had at a DConf
> some
> years ago, and we talked about inline and not inlining. I don't recall you
> ever
> mentioning issues with linkage, multiple instantiations, etc.
>

That's correct; our discussion was about what I describe in case #3.
Notably, that is a case that C/C++ has absolutely no way to express and it
was very interesting to me at the time to have a way to express it.

I think the mistake I made at the time was that I held an underlying
assumption about what inline does do, and presumed that to be a given.
We never discussed what inline does (emit to the calling CU), and I
certainly never said that was incorrect functionality and that we should
change that behaviour.
We didn't discuss it, I presumed it was a given, fundamental to the concept
of inline, and never gave it a second thought. It never occurred to me that
mechanic could come into question.

When I did realise that mechanic was broken though, I mentioned it at a
later time, and it's never been fixed.

Even assuming we were producing a solution for what I describe in case #3,
it still depends on #1 being effective. #1 is a baseline requirement that
any incarnation of inline must have to be useful.

I also have problems understanding what you want when things are
> distributed
> piecemeal over a large number of n.g. posts. I suggest again:
>
> 1. putting each problem into a bugzilla issue
> 2. keeping a text file of URLs to those issues
> 3. cut & paste that list as necessary and where necessary
>
> N.g. postings are utterly disorganized and ephemeral. Using targeted
> bugzilla
> issues is a far better way of organizing specific topics for change.
>

I agree, my bugzilla issues on inline are confused. I'll straighten them
out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200613/49c25ba9/attachment.htm>