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.