On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
> It[Accepting Booleans]'s far more flexible in generic code.

It's the other way round. pragma(inline) has currently *three* behaviors:

pragma(inline);
pragma(inline, true);
pragma(inline, false);

There is no way to represent those as a single boolean.

 — David

On 7/28/15 5:24 PM, David Nadlinger wrote:
> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>> It[Accepting Booleans]'s far more flexible in generic code.
>
> It's the other way round. pragma(inline) has currently *three* behaviors:
>
> pragma(inline);
> pragma(inline, true);
> pragma(inline, false);
>
> There is no way to represent those as a single boolean.

Ugh. And pragma(inline) doesn't mean what you would think it means. This is not a very good API for it, it's going to confuse everyone.

-Steve

On 7/28/15 5:28 PM, Steven Schveighoffer wrote:
> On 7/28/15 5:24 PM, David Nadlinger wrote:
>> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>>> It[Accepting Booleans]'s far more flexible in generic code.
>>
>> It's the other way round. pragma(inline) has currently *three* behaviors:
>>
>> pragma(inline);
>> pragma(inline, true);
>> pragma(inline, false);
>>
>> There is no way to represent those as a single boolean.
>
> Ugh. And pragma(inline) doesn't mean what you would think it means. This
> is not a very good API for it, it's going to confuse everyone.

Er.. nevermind. I misread the docs. I think.

-Steve

On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:
> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>> It[Accepting Booleans]'s far more flexible in generic code.
>
> It's the other way round. pragma(inline) has currently *three* behaviors:
>
> pragma(inline);
> pragma(inline, true);
> pragma(inline, false);
>
> There is no way to represent those as a single boolean.

The second two states can be. So, you can turn inlining on and off by feeding it a template argument or the result of a function or something. But it is true that you'd be stuck with a static if in the case that you just wanted to set it to the default behavior. I don't know what you'd do to be able to take an argument for all three though - maybe a string or just some known integral value?

I don't know how much it really matters ultimately though, since I expect that for the most part, the folks who are going to be using this pragma won't be using it generically.

Personally, I very much doubt that I'll ever use it, since I've never worked on code that cared about performance so much that you _had_ to force inlining somewhere. The compiler usually does a good enough job (though that's with C++ compilers; who knows how well dmd does).

- Jonathan M Davis

On Tuesday, 28 July 2015 at 21:29:45 UTC, Steven Schveighoffer wrote:
> On 7/28/15 5:28 PM, Steven Schveighoffer wrote:
>> On 7/28/15 5:24 PM, David Nadlinger wrote:
>>> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>>>> It[Accepting Booleans]'s far more flexible in generic code.
>>>
>>> It's the other way round. pragma(inline) has currently *three* behaviors:
>>>
>>> pragma(inline);
>>> pragma(inline, true);
>>> pragma(inline, false);
>>>
>>> There is no way to represent those as a single boolean.
>>
>> Ugh. And pragma(inline) doesn't mean what you would think it means. This
>> is not a very good API for it, it's going to confuse everyone.
>
> Er.. nevermind. I misread the docs. I think.

I do think it is terribly confusing. pragma(inline) does not cause any inlining by itself at all. It just means to let the compiler do what it normally does (i.e. try to inline if -inline is specified).

 — David

On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer wrote:
> On 7/28/15 5:24 PM, David Nadlinger wrote:
>> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>>> It[Accepting Booleans]'s far more flexible in generic code.
>>
>> It's the other way round. pragma(inline) has currently *three* behaviors:
>>
>> pragma(inline);
>> pragma(inline, true);
>> pragma(inline, false);
>>
>> There is no way to represent those as a single boolean.
>
> Ugh. And pragma(inline) doesn't mean what you would think it means. This is not a very good API for it, it's going to confuse everyone.
>
> -Steve

I don't think it's terrible confusing, just deceptive.

If pragma(inline) means "attempt to inline just like the -inline compile time attribute" then it's just an ugly way of repeating yourself.

In my opinion it shouldn't be any kind of expression. How often will ever need evaluate an expression for inlining? The hint: Once in 3 programmer's lifetimes.

It should be something like:

@inline @noinline

Or some other pragma or attribute.

If I want inlining, I want inlining. If the compiler cannot inline, throw an exception. Otherwise, do as I ask. I'm not here to joke around with a compiler. I'm here to develop my programs and have the compiler be on my side, not against me.

On Tuesday, 28 July 2015 at 21:30:11 UTC, Jonathan M Davis wrote:
> On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:
>> On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
>>> It[Accepting Booleans]'s far more flexible in generic code.
>>
>> It's the other way round. pragma(inline) has currently *three* behaviors:
>>
>> pragma(inline);
>> pragma(inline, true);
>> pragma(inline, false);
>>
>> There is no way to represent those as a single boolean.
>
> The second two states can be. So, you can turn inlining on and off by feeding it a template argument or the result of a function or something. But it is true that you'd be stuck with a static if in the case that you just wanted to set it to the default behavior. I don't know what you'd do to be able to take an argument for all three though - maybe a string or just some known integral value?
>
> I don't know how much it really matters ultimately though, since I expect that for the most part, the folks who are going to be using this pragma won't be using it generically.
>
> Personally, I very much doubt that I'll ever use it, since I've never worked on code that cared about performance so much that you _had_ to force inlining somewhere. The compiler usually does a good enough job (though that's with C++ compilers; who knows how well dmd does).
>
> - Jonathan M Davis

Even for an application that you would assume does a fine job, if you know, via profiling or unittests that a certain expression or method takes a bit of time due to excessive calls, it might just shave off a noticeable amount of time.

Case in point: live dynamic report generation. Let's say we have millions of records from a database and we want to process them and churn out a report. If this is done live, this could easily take minutes depending on the calculations and manipulations you need to do. If a call to a method is made every record, you could easily shave off 10-30 seconds with forcing an inline. And believe me, 10-30 seconds makes a huge difference when you're waiting around for 5+ minutes or more.

There's also time sensitive trading systems that don't want to be half a second slow, due to all that money they want now, now , now.

You'd be surprised how many places you could save a few seconds here or there with a smart inline attribute that the compiler might have missed.

It's been my experience that DMD doesn't really do a good job with this. GDC is much much better, but DMD truly lacks luster with inlining.

On Tue, 28 Jul 2015 11:15:58 -0400, Steven Schveighoffer wrote:

> the only thing I can thing of is that true/false are (or have the potential to be in this context) expressions, which means one could use compile-time logic to specify inlining. The same wouldn't be true of arbitrary identifiers.

pragma(inline, "always");
pragma(inline, "never");
pragma(inline, "whatever");

this way argument still can be expression, and compiler is able to test for correct argument too (for semantic analyzer there is almost no difference between testing for some given id and for some given string).

yet "that ship has sailed", i think.

On Tuesday, 28 July 2015 at 23:55:00 UTC, Brandon Ragland wrote:
> On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer wrote:
>> On 7/28/15 5:24 PM, David Nadlinger wrote:
>>> […]
>>>
>>> pragma(inline);
>>> pragma(inline, true);
>>> pragma(inline, false);
>>>
>>> There is no way to represent those as a single boolean.
>>
>> Ugh. And pragma(inline) doesn't mean what you would think it means. This is not a very good API for it, it's going to confuse everyone.
>>
>> -Steve
>
> I don't think it's terrible confusing, just deceptive.
>
> If pragma(inline) means "attempt to inline just like the -inline compile time attribute" then it's just an ugly way of repeating yourself.

Unless I misread the source, it does not mean that at all. Instead, it leads to the same behavior as if no pragma(inline) was specified at all, i.e. use the normal heuristics if -inline is specified, and do not do any inlining otherwise.

 — David

On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:
> yet "that ship has sailed", i think.

It hasn't yet. 2.068.0 will be the first release to include the pragma.

 — David