What does 'inline' mean?

[Andrei Alexandrescu]

On 6/12/20 4:13 PM, Avrina wrote:
> On Friday, 12 June 2020 at 15:37:16 UTC, Andrei Alexandrescu wrote:
>> On 6/11/20 11:01 PM, Avrina wrote:
>>> On Friday, 12 June 2020 at 01:55:26 UTC, Manu wrote:
>>>> 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?
>>>
>>> You won't get a direct answer to this. You can't have a debate if he 
>>> never presents an argument. Or rather in business, you don't have to 
>>> deal with a problem if you don't acknowledge there is a problem, 
>>> management 101.
>>
>> It seems to me the problem lies with the way the problem is formulated.
> 
> You managed to figure it out :), at least better than Walter. When 
> talking about inline, it seems even you and Walter seem to be focused on 
> the "inline" part.
> 
> Yes an empty template does what Manu wants, the problem is that 
> templates have their own nasty side effects.
> 
>     int  foo(int)  { return 1; }
>     bool foo(bool) { return true; }
> 
>     int  bar()(int)  { return 1; }
>     bool bar()(bool) { return true; }
> 
>     pragma(msg, __traits(getOverloads, __traits(parent, foo), "foo")); 
> // tuple of (foo, foo)
>     pragma(msg, __traits(getOverloads, __traits(parent, bar), "bar")); 
> // empty tuple ()
> 
> 
> It's relevant enough to be a feature that has already existed for quite 
> some time. All Manu wants is to have that same functionality without the 
> template.

Thanks, that's edifying. That makes sense - have pragma(inline, true) do 
what a template would, without actually using template instantiation.

> Maybe a bit different of an implementation but it does almost 
> the same thing.

This is important. Again it's been a repeating pattern that a valid 
request comes with a barrage of red herring details and suggestions for 
implementation that are often incomplete, unnecessarily complex, 
difficult to implement, or just plain wrong.

> There were also a few other examples of problems 
> provided that were meant with unhelpful "workarounds" such as this: 
> https://forum.dlang.org/post/rbua3s$1s5m$1@digitalmars.com Yes, just 
> don't ever use enums and/or waste your time trying to figure out what is 
> causing the link error and try to figure out a way to just remove it. So 
> helpful.

I confess I don't understand why the example doesn't work. It should. 
And the "doctor, it hurts when I do that - then don't do that" 
back-and-forth is not helping.