July 29, 2015
On 29 July 2015 at 20:34, David Nadlinger via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> 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
>
>
Of course, team sanity will do something different... Won't we? :o)

Well, for me it seems more obvious to let the GCC backend warn against any functions that were marked pragma(inline) by the user, but will never be inlined for one reason or another.

Regards
Iain


July 29, 2015
On Wednesday, 29 July 2015 at 18:34:34 UTC, David Nadlinger wrote:
> 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

Does anybody know what happens when you annotate a unittest with pragma(inline, true)? Unittests are functions as well, right?
July 30, 2015
On 7/28/15 6:12 PM, David Nadlinger wrote:
> 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).

OK, that is what I first thought. Then I thought it meant that for that function, it works as if -inline was passed on the command line (i.e. try to inline if possible, if not, don't worry about it). So you are saying the first interpretation is correct?

That means pragma(inline) is essentially useless.

-Steve
July 30, 2015
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
> OK, that is what I first thought. Then I thought it meant that for that function, it works as if -inline was passed on the command line (i.e. try to inline if possible, if not, don't worry about it). So you are saying the first interpretation is correct?
>
> That means pragma(inline) is essentially useless.

Well, if pragmas work with : like attributes (I don't know if they do), then pragma(inline) would be a way to undo a pragma(inline, true) or pragma(inline, false) on specific functions, similar to how many folks want !final or final(false) after using final:, but if : doesn't work with pragmas, then yeah, it's totally useless.

- Jonathan M Davis
July 30, 2015
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
> So you are saying the first interpretation is correct?

As far as I can see, this is what the implementation currently does, yes.

 — David
July 31, 2015
On 7/30/15 4:37 PM, Jonathan M Davis wrote:
> On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
>> OK, that is what I first thought. Then I thought it meant that for
>> that function, it works as if -inline was passed on the command line
>> (i.e. try to inline if possible, if not, don't worry about it). So you
>> are saying the first interpretation is correct?
>>
>> That means pragma(inline) is essentially useless.
>
> Well, if pragmas work with : like attributes (I don't know if they do),
> then pragma(inline) would be a way to undo a pragma(inline, true) or
> pragma(inline, false) on specific functions, similar to how many folks
> want !final or final(false) after using final:, but if : doesn't work
> with pragmas, then yeah, it's totally useless.

Without knowing the rules what does this do:

pragma(inline):
int foo()
{
   return 1;
}

If anyone reads this and says he intuitively thinks "oh, that will mean you have to pass -inline on the command line to get it inlined," I think he is not being truthful.

-Steve
July 31, 2015
On 31 July 2015 at 14:06, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 7/30/15 4:37 PM, Jonathan M Davis wrote:
>
>> On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
>>
>>> OK, that is what I first thought. Then I thought it meant that for that function, it works as if -inline was passed on the command line (i.e. try to inline if possible, if not, don't worry about it). So you are saying the first interpretation is correct?
>>>
>>> That means pragma(inline) is essentially useless.
>>>
>>
>> Well, if pragmas work with : like attributes (I don't know if they do),
>> then pragma(inline) would be a way to undo a pragma(inline, true) or
>> pragma(inline, false) on specific functions, similar to how many folks
>> want !final or final(false) after using final:, but if : doesn't work
>> with pragmas, then yeah, it's totally useless.
>>
>
> Without knowing the rules what does this do:
>
> pragma(inline):
> int foo()
> {
>    return 1;
> }
>
> If anyone reads this and says he intuitively thinks "oh, that will mean you have to pass -inline on the command line to get it inlined," I think he is not being truthful.
>
> -Steve
>

Yeah...  I'm sticking to my earlier assertion on this.

Using -(f)inline on the command line should not be read as being related to
pragma(inline).  The pragma is explicit request by the user which says that
this function should be inlined.

So the way I read it, is that uninlineable functions marked with pragma(inline) should come with whatever diagnostics necessary to heed off the user from using it in situations that are impossible.

When I say this, I mean things like:
- Naked functions
- Functions with D-style asm
- Functions with calls to alloca()
- Variadic functions

With everything else, you can either expect the function to be inlined... or not - it really does depend on whether or not the compiler sees it as worth it, but at least you don't get errors about it.  It's at this point that pragma(inline, true) comes into the picture.

Regards
Iain.


July 31, 2015
On Tuesday, 28 July 2015 at 22:12:21 UTC, David Nadlinger wrote:
> 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).

I suppose people were frustrated with attributes which can't be negated, so they requested default inlining policy just for the heck of it, it probably doesn't have a compelling use case? Decide on inlining in generic way?
August 01, 2015
"Steven Schveighoffer"  wrote in message news:mp86be$8f2$1@digitalmars.com...

> 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.

That's why the proposal was for strings, not arbitrary identifiers. 

August 04, 2015
On Wed, 29 Jul 2015 18:35:36 +0000, David Nadlinger wrote:

> 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.

but one has to convince Walter, and it's not the easiest thing to do. ;-)

1 2 3 4
Next ›   Last »