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

> On 6/11/2020 6:51 PM, Manu wrote:
> > I'm fairly sure C++ uses the link flag that LLVM calls "choose one". It's in the C++ spec that all inlines collapse to the same one. We
> should be
> > using the same flag.
>
> D totally relies on that behavior.
>

 So emit the function to the CU where it's called and we're done here!

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 show you how you can do that with existing D, along with an existing, working solution.

Then you say you're not talking about 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.

> The existing implementation is inline is a COMPLETELY useless thing.

I use it, and it's not useless.

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

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.

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.

On Sat, Jun 13, 2020 at 11:31 AM Walter Bright via Digitalmars-d < digitalmars-d@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.

On Sat, Jun 13, 2020 at 11:58 AM Manu <turkeyman@gmail.com> wrote:

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

Let's get this right first: https://issues.dlang.org/show_bug.cgi?id=20925

My cases #2 and #3 are secondary to that initial critical requirement, and they both depend on that as a baseline requirement.

On 6/12/20 8:52 PM, Manu wrote:
> On Fri, Jun 12, 2020 at 11:25 PM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
> 
>     On 6/8/20 2:14 AM, Manu wrote:
>      > In C/C++, inline says that a function will be emit to the binary
>     only
>      > when it is called, and the function is marked with internal
>     linkage (it
>      > is not visible to the linker from the symbol table)
> 
>     By my recollection this is not the case for C++, at all.
> 
>     * "inline" does NOT change a function's linkage in C++. You may have
>     inline functions with internal linkage (static inline) or (default)
>     external linkage. This is important because e.g. defining a static
>     variable in an extern inline function will have the same address in all
>     calls to the function.
> 
> 
> It absolutely changes the linkage.

No.

> I believe it uses what LLVM calls 'ChooseOne' in its code generator, I don't know about 'standard' linker terminology, if such a thing exists.

It does: http://eel.is/c++draft/basic.link

> It's clearly in the spec too:
> """
> 
>  1. There may be more than one definition
>     <https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule> of
>     an inline function or variable in the program as long as each
>     definition *appears in a different translation unit* and (for
>     non-static inline functions and variables) all definitions are
>     identical. For example, an inline function or an inline variable may
>     be defined in a header file that is #include'd in multiple source files.
> 
> """

The quote does not even contain the word "linkage".

I'm insisting on this because it happens so often. We need to use the terms with the same meaning, otherwise we get bogged down in silly side quests "it doesn't change linkage" - "oh but it does" and there is no progress.

On 6/12/20 8:52 PM, Manu wrote:
> Except in the case I described as case #3, in which it would be useful to have SOME WAY, to 'force inline' and receive an error if it failed.

I recall a couple of compilers (TopSpeed, does anyone remember?) had such a feature. The warnings listing the arbitrary functions that failed whatever heuristics was utterly useless. No C++ compiler implements it today, and I don't think any should.

On 6/12/20 8:54 PM, Walter Bright wrote:
> On 6/12/2020 5:17 PM, Andrei Alexandrescu wrote:
>> Not sure about that part - if linkage was static by means of using the "static" keyword, multiple definitions may not be merged. (I may be wrong, please correct me.) Consider:
>>
>> static inline int fun() {
>>      static int x;
>>      return ++x;
>> }
>>
>> In C++, each translation unit containing a definition of fun() will have a distinct address for x. I don't see how the bodies of those functions can be merged.
> 
> They are not merged in D, for the simple reason that ModuleA.fun() and ModuleB.fun() will have different (mangled) names presented to the linker.

For D the question is if they are merged if the function is defined in a .di file and imported in two other modules.

On 6/12/20 9:13 PM, Manu wrote:
> On Sat, Jun 13, 2020 at 10:20 AM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
> 
>     On 6/12/20 2:08 PM, Johan wrote:
>      > On Friday, 12 June 2020 at 13:22:35 UTC, Andrei Alexandrescu wrote:
>      >> On 6/8/20 2:14 AM, Manu wrote:
>      >>> In C/C++, inline says that a function will be emit to the
>     binary only
>      >>> when it is called, and the function is marked with internal
>     linkage
>      >>> (it is not visible to the linker from the symbol table)
>      >>
>      >> By my recollection this is not the case for C++, at all.
>      >>
>      >> * "inline" does NOT change a function's linkage in C++. You may
>     have
>      >> inline functions with internal linkage (static inline) or (default)
>      >> external linkage. This is important because e.g. defining a static
>      >> variable in an extern inline function will have the same address in
>      >> all calls to the function.
>      >
>      > I believe Manu tried to explain that `inline` in C++ really only
>     affects
>      > how the linker must treat the symbol, and it is best to remember
>     that it
>      > does nothing at all concerning "inlining" (putting function body
>     inside
>      > another).
> 
>     Thank you. That's not at all what he wrote. AT ALL. It's what I wrote.
> 
>     I'm emphasizing this because it has been a recurring problem: a
>     legitimate problem with an explanation lost in translation.
> 
> 
> You're joking right?

Well, again I tried to get communication going and again I failed. So... again I will bow out, with apologies.

On Sat, Jun 13, 2020 at 1:30 PM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 6/12/20 8:54 PM, Walter Bright wrote:
> > On 6/12/2020 5:17 PM, Andrei Alexandrescu wrote:
> >> Not sure about that part - if linkage was static by means of using the "static" keyword, multiple definitions may not be merged. (I may be wrong, please correct me.) Consider:
> >>
> >> static inline int fun() {
> >>      static int x;
> >>      return ++x;
> >> }
> >>
> >> In C++, each translation unit containing a definition of fun() will have a distinct address for x. I don't see how the bodies of those functions can be merged.
> >
> > They are not merged in D, for the simple reason that ModuleA.fun() and
> > ModuleB.fun() will have different (mangled) names presented to the
> linker.
>
> For D the question is if they are merged if the function is defined in a .di file and imported in two other modules.
>

They are not 'merged', they just don't exist.
The problem I've repeated many times for D is that it doesn't emit the
function ANYWHERE, and as such, you get a "undefined symbol" error. This is
different than C++ where you would have gotten a "multiply defined symbol"
error, but it's exactly the same problem for the exact same reason. It just
manifests differently because C++ has .h files which naturally duplicates
the code into each CU and D doesn't.

On Sat, Jun 13, 2020 at 1:35 PM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 6/12/20 9:13 PM, Manu wrote:
> > On Sat, Jun 13, 2020 at 10:20 AM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>>
> wrote:
> >
> >     On 6/12/20 2:08 PM, Johan wrote:
> >      > On Friday, 12 June 2020 at 13:22:35 UTC, Andrei Alexandrescu
> wrote:
> >      >> On 6/8/20 2:14 AM, Manu wrote:
> >      >>> In C/C++, inline says that a function will be emit to the
> >     binary only
> >      >>> when it is called, and the function is marked with internal
> >     linkage
> >      >>> (it is not visible to the linker from the symbol table)
> >      >>
> >      >> By my recollection this is not the case for C++, at all.
> >      >>
> >      >> * "inline" does NOT change a function's linkage in C++. You may
> >     have
> >      >> inline functions with internal linkage (static inline) or
> (default)
> >      >> external linkage. This is important because e.g. defining a
> static
> >      >> variable in an extern inline function will have the same address
> in
> >      >> all calls to the function.
> >      >
> >      > I believe Manu tried to explain that `inline` in C++ really only
> >     affects
> >      > how the linker must treat the symbol, and it is best to remember
> >     that it
> >      > does nothing at all concerning "inlining" (putting function body
> >     inside
> >      > another).
> >
> >     Thank you. That's not at all what he wrote. AT ALL. It's what I
> wrote.
> >
> >     I'm emphasizing this because it has been a recurring problem: a
> >     legitimate problem with an explanation lost in translation.
> >
> >
> > You're joking right?
>
> Well, again I tried to get communication going and again I failed. So... again I will bow out, with apologies.
>

No, I appreciate your effort to improve the conversation.
What I don't appreciate is suggesting that "That's not at all what [he]
wrote. AT ALL." when I really feel like it is exactly what I wrote.
And if it was confused, I apologise, but there are plenty of people who
were able to read it and understand precisely what I was saying.
Anyway...