On Monday, 27 July 2015 at 02:19:28 UTC, Jonathan M Davis wrote:
> On Sunday, 26 July 2015 at 22:59:49 UTC, Gary Willoughby wrote:
>> It looks like support is being considered:
>>
>> http://dlang.org/pragma.html#inline
>
> Yeah. IIRC, there was a big discussion a few months back on how pragma(inline) worked vs how it should work. In particular, I think that there was a big dispute over whether pragma(inline, true) should force inlining outright or make it so that it gave you an error if it wasn't inlined. I'd have to go find that discussion and dig through it though to know for sure what was being discussed exactly. I paid some attention to it, but not a lot.

The result was that the pragma _forces_ inlining. If the compiler cannot inline it for whatever reason, it prints an error and exits. This is mostly to accommodate DMD, which has some restrictions about which functions can be inlined.

On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:
> I just started writing an emulator in D for some fun; I needed an
> application to case-study aggressive performance characteristics in
> hot-loop situations.
> I know this has come up time and time again, but I just want to put it out
> there again... if I were shipping this product, I would NEED forceinline +
> force-not-inline.

I don't know if it's possible right now with GDC/LDC but did you try PGO+LTO ?
Just curious.

On Monday, 27 July 2015 at 08:52:02 UTC, Marc Schütz wrote:
> On Monday, 27 July 2015 at 02:19:28 UTC, Jonathan M Davis wrote:
>> [...]
>
> The result was that the pragma _forces_ inlining. If the compiler cannot inline it for whatever reason, it prints an error and exits. This is mostly to accommodate DMD, which has some restrictions about which functions can be inlined.

Why not like pragma(inline, [try | force | no]) ?

"tcak"  wrote in message news:psflpqqpsukpfgpzhngn@forum.dlang.org... 

> Why not like pragma(inline, [try | force | no]) ?

Walter liked the boolean version, which is certainly better than nothing.

On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
> "tcak"  wrote in message news:psflpqqpsukpfgpzhngn@forum.dlang.org...
>
>> Why not like pragma(inline, [try | force | no]) ?
>
> Walter liked the boolean version, which is certainly better than nothing.

I regret I missed this pull request and the chance to vote for "always"/"never" proposed by yebblies, which hit the right neurons in reader's brain instantly, unlike the generic true/false.

On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:
> On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
>> "tcak"  wrote in message news:psflpqqpsukpfgpzhngn@forum.dlang.org...
>>
>>> Why not like pragma(inline, [try | force | no]) ?
>>
>> Walter liked the boolean version, which is certainly better than nothing.
>
> I regret I missed this pull request and the chance to vote for "always"/"never" proposed by yebblies, which hit the right neurons in reader's brain instantly, unlike the generic true/false.

Someone made this exact suggestion in the PR, but as happens with most sensible suggestions, it was shot down.

On Tuesday, 28 July 2015 at 13:30:52 UTC, Marc Schütz wrote:
> On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:
>> On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
>>> "tcak"  wrote in message news:psflpqqpsukpfgpzhngn@forum.dlang.org...
>>>
>>>> Why not like pragma(inline, [try | force | no]) ?
>>>
>>> Walter liked the boolean version, which is certainly better than nothing.
>>
>> I regret I missed this pull request and the chance to vote for "always"/"never" proposed by yebblies, which hit the right neurons in reader's brain instantly, unlike the generic true/false.
>
> Someone made this exact suggestion in the PR, but as happens with most sensible suggestions, it was shot down.

I feel like that is becoming a trend for D, lately it feels like the only things that end up making its way into the language are dirty hacks.

On 7/28/15 9:30 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:
>> On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
>>> "tcak"  wrote in message news:psflpqqpsukpfgpzhngn@forum.dlang.org...
>>>
>>>> Why not like pragma(inline, [try | force | no]) ?
>>>
>>> Walter liked the boolean version, which is certainly better than
>>> nothing.
>>
>> I regret I missed this pull request and the chance to vote for
>> "always"/"never" proposed by yebblies, which hit the right neurons in
>> reader's brain instantly, unlike the generic true/false.
>
> Someone made this exact suggestion in the PR, but as happens with most
> sensible suggestions, it was shot down.

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.

-Steve

On Tuesday, 28 July 2015 at 15:15:58 UTC, 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.

Which is likely why boolean values were chosen. It's the same for why if we ever do end up with being able to negate attributes, it's almost certainly going to be something like final(false) rather than !final. It's far more flexible in generic code.

Now, in the case of inlining, I don't know how much it actually buys you, since you would probably normally wouldn't be looking to have that inferred or determined by another piece of code, but if boolean values are used, you at least have that flexibility without having to use static if to provide the function multiple times.

- Jonathan M Davis

On Tuesday, 28 July 2015 at 15:15:58 UTC, 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.

Of course it would, e.g. if they are strings, or constants/types defined in druntime.

 — David