www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP56 - inlining

reply Walter Bright <newshound2 digitalmars.com> writes:
http://wiki.dlang.org/DIP56

There's been enough discussion, time to make a decision and move on.

I changed the description to:

"If a pragma specifies always inline, and the compiler cannot inline it, a 
warning will be generated. Implementations will likely vary in their ability to 
inline."
Feb 03 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 There's been enough discussion, time to make a decision and 
 move on.


I'm glad this is being said more and more around these parts. 
Some stuff just seems to be stagnating forever.
Feb 03 2015
prev sibling next sibling parent reply "Orvid King" <blah38621 gmail.com> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


I just created a proposal for a more general syntax to allow 
user's to apply attributes like inlining in a way that can easily 
be supported across compilers, and, in my eyes, is clearer about 
what code the attribute is applied to than a pragma is.

http://wiki.dlang.org/DIP72
Feb 03 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2015 2:47 PM, Orvid King wrote:

 I just created a proposal for a more general syntax to allow user's to apply
 attributes like inlining in a way that can easily be supported across
compilers,
 and, in my eyes, is clearer about what code the attribute is applied to than a
 pragma is.

 http://wiki.dlang.org/DIP72


I appreciate that you took the time to create a proposal, but no. Please, let's 
move on.
Feb 03 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 03 Feb 2015 22:47:30 +0000, Orvid King wrote:


 On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot inline
 it, a warning will be generated. Implementations will likely vary in
 their ability to inline."


=20
 I just created a proposal for a more general syntax to allow user's to
 apply attributes like inlining in a way that can easily be supported
 across compilers, and, in my eyes, is clearer about what code the
 attribute is applied to than a pragma is.
=20
 http://wiki.dlang.org/DIP72


gcc using ` attribute("name")` for this. it's easier and requires no=20
compiler hacks to ignore.=
Feb 03 2015
parent reply "Orvid King" <blah38621 gmail.com> writes:
On Wednesday, 4 February 2015 at 05:17:11 UTC, ketmar wrote:

 On Tue, 03 Feb 2015 22:47:30 +0000, Orvid King wrote:


 On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright 
 wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline
 it, a warning will be generated. Implementations will likely 
 vary in
 their ability to inline."


 
 I just created a proposal for a more general syntax to allow 
 user's to
 apply attributes like inlining in a way that can easily be 
 supported
 across compilers, and, in my eyes, is clearer about what code 
 the
 attribute is applied to than a pragma is.
 
 http://wiki.dlang.org/DIP72


 gcc using ` attribute("name")` for this. it's easier and 
 requires no
 compiler hacks to ignore.


Yes, but  attribute isn't defined when compiling with DMD, 
resulting in the need for some fun with version statements. My 
proposal was to add a mechanism in the frontend to recognize it. 
 attribute also has the limitation of it being a UDA, so it can't 
be used for things like branch hinting. I meant to include it in 
DIP 72, but forgot about that aspect of it; but I'd hope with DIP 
72 to be able to allow  compiler attributes on statements, and, 
potentially, on expressions as well.
Feb 03 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 05:24:18 +0000, Orvid King wrote:


 Yes, but  attribute isn't defined when compiling with DMD, resulting in
 the need for some fun with version statements.


exactly one module, say, for example, `gcccompat.d`:

  module gcccompat;

  version(GNU) {
    public import gcc.attribute;
  } else {
    private struct Attribute(A...) { A args; }
    auto attribute(A...) (A args)
      if (A.length > 0 && is(A[0] =3D=3D string))
      { return Attribute!A(args); }
  }

   attribute("forceinline") int test () { return 42; }
    // wow, this works in DMD and LDC!

that's it. only one module, which can be easily added to any project. no=20
need to modify the compiler in any way.


  attribute also has the
 limitation of it being a UDA, so it can't be used for things like branch
 hinting.


how ` compiler(inline, never)` can be used for branch hinting? oh, on the=20
second thought i don't want to see that syntax.


 I meant to include it in DIP 72, but forgot about that aspect
 of it; but I'd hope with DIP 72 to be able to allow  compiler attributes
 on statements, and, potentially, on expressions as well.


it still looks like UDA, it *can* be completely substituted by one UDA=20
with string arguments, it adds hacks and special rules to the compiler.=20
no wander Walter says "no" for it.=
Feb 03 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


We have an attribute system, why make this a pragma ?

Also, this is going to be a challenge to detect if something have 
been inlined unless inlining is done in the frontend.
Feb 03 2015
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:

 We have an attribute system, why make this a pragma ?


Rationale is in the DIP: "These are not attributes because they 
should not affect the semantics of the function. In particular, 
the function signature must not be affected."
Feb 03 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 February 2015 at 23:25:26 UTC, Peter Alexander 
wrote:

 On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:

 We have an attribute system, why make this a pragma ?


 Rationale is in the DIP: "These are not attributes because they 
 should not affect the semantics of the function. In particular, 
 the function signature must not be affected."


That's bullshit. UDA do not change the semantic of a function. By 
the same reasoning they should be user defined pragma ?!??
Feb 03 2015
prev sibling next sibling parent reply "an" <anonymous mail.invalid> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


Pragmas can be used as attribute that doesn't affect the 
semantics. This syntax is not supported in this DIP?

pragma(inline, true)
{
void foo() { }
void bar() { }
}
Feb 03 2015
parent reply Justin Whear <justin economicmodeling.com> writes:
On Tue, 03 Feb 2015 23:34:15 +0000, an wrote:


 Pragmas can be used as attribute that doesn't affect the semantics. This
 syntax is not supported in this DIP?
 
 pragma(inline, true)
 {
 void foo() { }
 void bar() { }
 }


I assume it's covered by "If this pragma is outside of a function, it 
affects the functions in the block it encloses."
Feb 03 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 03 Feb 2015 23:37:58 +0000, Justin Whear wrote:


 On Tue, 03 Feb 2015 23:34:15 +0000, an wrote:
=20

 Pragmas can be used as attribute that doesn't affect the semantics.
 This syntax is not supported in this DIP?
=20
 pragma(inline, true)
 {
 void foo() { }
 void bar() { }
 }


=20
 I assume it's covered by "If this pragma is outside of a function, it
 affects the functions in the block it encloses."


and so it's completely unusable on module level, as "{}" is not allowed=20
there. i still can't see what's wrong with ` attribute("inline")`,=20
` attribute("force_inline")` and so on. ah, except it breaks one of the=20
first rules in The Book Of D: "try to escape uniformity whenever it is=20
possible".=
Feb 03 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:

 there. i still can't see what's wrong with 
 ` attribute("inline")`,
 ` attribute("force_inline")` and so on. ah, except it breaks 
 one of the
 first rules in The Book Of D: "try to escape uniformity 
 whenever it is possible".


Using pragmas for inlining is common in compilers for other clean 
languages (Ada, Haskell).

Unless inlining affects the ability to use functions as actual 
parameters it is not part of the language and therefore a pragma, 
but I agree that the pragma syntax is ugly, but " attribute" is 
also ugly.

Maybe better to reserve " _word" so that they cannot be used for 
UDA and let all pragmas start with " _":

 _inline(0) // never, inline_weight*0 => 0
 _inline(1) // default, inline_weight*1 => inline_weight
 _inline(Inf) // always, inline_weight*Inf => Inf
 _inline       // same as  _inline(Inf)
Feb 03 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 06:59:52 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:

 there. i still can't see what's wrong with ` attribute("inline")`,
 ` attribute("force_inline")` and so on. ah, except it breaks one of the
 first rules in The Book Of D: "try to escape uniformity whenever it is
 possible".


=20
 Using pragmas for inlining is common in compilers for other clean
 languages (Ada, Haskell).
=20
 Unless inlining affects the ability to use functions as actual
 parameters it is not part of the language and therefore a pragma,
 but I agree that the pragma syntax is ugly, but " attribute" is also
 ugly.
=20
 Maybe better to reserve " _word" so that they cannot be used for UDA and
 let all pragmas start with " _":
=20
  _inline(0) // never, inline_weight*0 =3D> 0  _inline(1) // default,
 inline_weight*1 =3D> inline_weight  _inline(Inf) // always,
 inline_weight*Inf =3D> Inf  _inline       // same as  _inline(Inf)


using ` attribute("...")` is ugly, but it has the advantage of simple=20
workarounding for compilers that still not supporting that attribute.=20
plus, it allows things like ` attribute("...") { ... }` or ` attribute
("..."):` on module level, whereas `pragma` isn't.

as for uglyness... it's too late to thing about this. one more, one=20
less... ;-)=
Feb 03 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:

 as for uglyness... it's too late to thing about this. one more, 
 one less... ;-)


Are you following the reasoning: the uglier the better, because 
that will set us up for a clean slate syntax redesign? :)
Feb 03 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 07:26:04 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:

 as for uglyness... it's too late to thing about this. one more,
 one less... ;-)


=20
 Are you following the reasoning: the uglier the better, because that
 will set us up for a clean slate syntax redesign? :)


don't tell it anyone, it's a *secret* plan after all!=
Feb 03 2015
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:

 On Wed, 04 Feb 2015 06:59:52 +0000, Ola Fosheim Grøstad wrote:


 On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:





 as for uglyness... it's too late to thing about this. one more, 
 one
 less... ;-)


Wait... That used to be told about C++, not about D...
Feb 04 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 08:06:06 +0000, eles wrote:


 On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:

 On Wed, 04 Feb 2015 06:59:52 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=




:

 On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:




=20

 as for uglyness... it's too late to thing about this. one more, one
 less... ;-)


=20
 Wait... That used to be told about C++, not about D...


D is in the same position now. "that ship is sailed", "we don't break the=20
code", "happy legacy, folks!"=
Feb 04 2015
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 09:07:12 ketmar via Digitalmars-d wrote:

 D is in the same position now. "that ship is sailed", "we don't break the
 code", "happy legacy, folks!"


Not quite. The C++ folks basically won't break backwards compatibility for
anything. There are a few rare cases in the recent standards where they
deprecated something that was just outright a bad idea and that no one
sensible was using better anyway (e.g. non-empty throw specifiers). With D,
we're reaching the point where we don't want to break backwards
compatability if we can avoid it, and the bar for doing so is relatively
high, but we'll still do it if we deem that the cost is worth gain (though
part of the problem is how subjective that can be). So, we're not as rigid
as C++ is, but we _are_ past the point where we purposefully make breaking
changes on a regular basis (though unfortunately, regressions get through
with pretty much every release). So, anyone looking for a particularly
malleable language is going to be unhappy with D, but unlike C++, it's not
set in stone.

- Jonathan M Davis
Feb 04 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 4 February 2015 at 08:06:08 UTC, eles wrote:

 On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:

 On Wed, 04 Feb 2015 06:59:52 +0000, Ola Fosheim Grøstad wrote:


 On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:





 as for uglyness... it's too late to thing about this. one 
 more, one
 less... ;-)


 Wait... That used to be told about C++, not about D...


:-D

John Nagle on Rust:

«I'm concerned that Rust is starting out at the cruft level it 
took C++ 20 years to achieve. I shudder to think of what things 
will be like once the Boost crowd discovers Rust.»

http://lambda-the-ultimate.org/node/5113

Seems like the C++ replacement languages have problems reaching a 
stable release without aggregating cruft...
Feb 04 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 February 2015 at 07:16, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wed, 04 Feb 2015 06:59:52 +0000, Ola Fosheim Grøstad wrote:


 On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:

 there. i still can't see what's wrong with ` attribute("inline")`,
 ` attribute("force_inline")` and so on. ah, except it breaks one of the
 first rules in The Book Of D: "try to escape uniformity whenever it is
 possible".


 Using pragmas for inlining is common in compilers for other clean
 languages (Ada, Haskell).

 Unless inlining affects the ability to use functions as actual
 parameters it is not part of the language and therefore a pragma,
 but I agree that the pragma syntax is ugly, but " attribute" is also
 ugly.

 Maybe better to reserve " _word" so that they cannot be used for UDA and
 let all pragmas start with " _":

  _inline(0) // never, inline_weight*0 => 0  _inline(1) // default,
 inline_weight*1 => inline_weight  _inline(Inf) // always,
 inline_weight*Inf => Inf  _inline       // same as  _inline(Inf)


 using ` attribute("...")` is ugly, but it has the advantage of simple
 workarounding for compilers that still not supporting that attribute.


You can tell the compiler to ignore unknown pragmas too...
Feb 04 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 08:11:40 +0000, Iain Buclaw via Digitalmars-d wrote:


 You can tell the compiler to ignore unknown pragmas too...


` attribute("...")` has another advantage: it's already working at least=20
in one compiler. whereas proposed `pragma` is not working yet. ;-)=
Feb 04 2015
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 04 Feb 2015 06:59:52 +0000
schrieb "Ola Fosheim Gr=C3=B8stad" <ola.fosheim.grostad+dlang gmail.com>:


 but I agree that the pragma syntax is ugly, but " attribute" is=20
 also ugly.
=20
 Maybe better to reserve " _word" so that they cannot be used for=20
 UDA and let all pragmas start with " _":


That's not necessary. For GDC you can do this:

alias forceinline =3D Attribute!("forceinline");
(I don't remember the exact syntax but you can use an alias)

Then you can simply do
 forceinline void test (){};

There's no need to reserve  _ as UDAs follow normal lookup rules.
 forceinline consflicts with some other UDA? Than use the full name,
renamed imports, add an alias, ...

That's a huge benefit of UDAs.
Feb 04 2015
next sibling parent "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau 
wrote:


 alias forceinline = Attribute!("forceinline");
 (I don't remember the exact syntax but you can use an alias)


The syntax I'm using is...

version (GNU)
{
   static import gcc.attribute;
   enum inline = gcc.attribute.attribute("forceinline");
}

 inline T volatileLoad(T)(T* a)
{
     asm { "" ::: "memory"; };
     return *cast(shared T*)a;
}

 inline void volatileStore(T)(T* a, in T v)
{
     asm { "" ::: "memory"; };
     *cast(shared T*)a = v;
}

Quite nice IMO.

Mike
Feb 04 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau 
wrote:

 That's not necessary. For GDC you can do this:

 alias forceinline = Attribute!("forceinline");
 (I don't remember the exact syntax but you can use an alias)

 Then you can simply do
  forceinline void test (){};


Yes, your attribute syntax is quite ok, but if the outcome is 
that each program is having their own inline syntax then it is 
less than satisfactory.
Feb 04 2015
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 04 Feb 2015 12:47:24 +0000
schrieb "Ola Fosheim Gr=C3=B8stad" <ola.fosheim.grostad+dlang gmail.com>:


 On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau=20
 wrote:

 That's not necessary. For GDC you can do this:

 alias forceinline =3D Attribute!("forceinline");
 (I don't remember the exact syntax but you can use an alias)

 Then you can simply do
  forceinline void test (){};


=20
 Yes, your attribute syntax is quite ok, but if the outcome is=20
 that each program is having their own inline syntax then it is=20
 less than satisfactory.


obviously the alias could also be standardized and placed into
gcc.attribute...
Feb 04 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


I think this whole debate could have been avoided if the DIP was 
worded differently.

Instead of...

pragma(inline, true);  // always inline
pragma(inline, false); // never inline
pragma(inline);        // revert to default behavior

...it should read...

pragma(inline, true);  // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);        // use whatever is passed in on the 
command line

...as that is really the intent of DIP56 as confirmed by Walter 
[1].

Now the problem with this is it is DMD specific, as the compiler 
flags vary greatly between compilers.  So instead it may be 
better to generalize it.

pragma(compile, inline, true)   // enable -inline compiler flag
pragma(compile, inline, false)  // disable -inline compiler flag
pragma(compile, inline)         // use whatever is passed in on 
the command line

Since GDC doesn't have an -inline flag, it may instead choose to 
use any or all of the following...
pragma(compile, finline-small-functions, true|false)
pragma(compile, fno-inline, true|false)
pragma(compile, finline-functions, true|false)

... or choose not to implement it a all since it already has 
` attribute` mappings to GCC's `__attribute__` syntax [4].

Only the GDC developers can say whether this is feasible or not, 
but it matches much better to the intent of DIP56 [2].  Perhaps 
this is more along the lines of what DIP72 [3] is trying to 
achieve.

Mike

[1] - Walter confirming behavior of pragma(inline) - 
http://forum.dlang.org/post/maq4rp$2f9o$1 digitalmars.com
[2] - DIP56 - http://wiki.dlang.org/DIP56
[3] - DIP72 - http://wiki.dlang.org/DIP72
[4] - GCC's Attribute Syntax - 
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Feb 03 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 February 2015 at 00:24:25 UTC, Mike wrote:

 I think this whole debate could have been avoided if the DIP 
 was worded differently.

 Instead of...

 pragma(inline, true);  // always inline
 pragma(inline, false); // never inline
 pragma(inline);        // revert to default behavior

 ...it should read...

 pragma(inline, true);  // enable -inline compiler flag
 pragma(inline, false); // disable -inline compiler flag
 pragma(inline);        // use whatever is passed in on the 
 command line

 ...as that is really the intent of DIP56 as confirmed by Walter 
 [1].


No this is definitely not what I wanted.

Proposed version with warning sounds like acceptable compromise 
though.
Feb 03 2015
parent reply "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:

 pragma(inline, true);  // enable -inline compiler flag
 pragma(inline, false); // disable -inline compiler flag
 pragma(inline);        // use whatever is passed in on the 
 command line

 ...as that is really the intent of DIP56 as confirmed by 
 Walter.


 No this is definitely not what I wanted.


This is not what I want either.  I find  always_inline and 
 never_inline attributes with compile-time enforcement *far* more 
useful.

But DIP56 was not originally intended to address that need, and 
it's a shame it was worded as if it was.  pragma(inline, true) is 
not "always inline" and pragma(inline, false) is not "never 
inline".

Implementing DIP56 as it was originally intended (or more 
intuitively as a way to add compiler flags to part of a file) 
would not prevent the addition of future features to enable 
inlining enforcement.

But now we're compromising to mediocrity where noone really wins.

Mike
Feb 03 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/15 6:44 PM, Mike wrote:

 On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:

 pragma(inline, true);  // enable -inline compiler flag
 pragma(inline, false); // disable -inline compiler flag
 pragma(inline);        // use whatever is passed in on the command line

 ...as that is really the intent of DIP56 as confirmed by Walter.


 No this is definitely not what I wanted.


 This is not what I want either.  I find  always_inline and  never_inline
 attributes with compile-time enforcement *far* more useful.

 But DIP56 was not originally intended to address that need, and it's a
 shame it was worded as if it was.  pragma(inline, true) is not "always
 inline" and pragma(inline, false) is not "never inline".

 Implementing DIP56 as it was originally intended (or more intuitively as
 a way to add compiler flags to part of a file) would not prevent the
 addition of future features to enable inlining enforcement.

 But now we're compromising to mediocrity where noone really wins.


Nobody really loses, either. (I'll note that gcc has several mechanisms 
for enabling/disabling inlining, all of which issue a warning at the most.)

The question is, can you get work done with the currently proposed 
semantics? If so, let's commit to this and move on.


Andrei
Feb 03 2015
parent "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 02:52:07 UTC, Andrei 
Alexandrescu wrote:

 The question is, can you get work done with the currently 
 proposed semantics? If so, let's commit to this and move on.


Yes, I may be able to make use of it on occasion, but only 
because other, more useful features are not implemented.

Mike
Feb 03 2015
prev sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 4 February 2015 at 02:44:46 UTC, Mike wrote:

 This is not what I want either.  I find  always_inline and 
  never_inline attributes with compile-time enforcement *far* 
 more useful.


pragma(inline, true) will not compile if you enabled warnings as 
errors.
Feb 03 2015
parent reply "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:

 pragma(inline, true) will not compile if you enabled warnings 
 as errors.


I know, but this is the mediocrity I'm talking about:  it only 
works as one wishes/expects under certain conditions.

Mike
Feb 03 2015
parent "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 04:11:39 UTC, Mike wrote:

 On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:

 pragma(inline, true) will not compile if you enabled warnings 
 as errors.


 I know, but this is the mediocrity I'm talking about:  it only 
 works as one wishes/expects under certain conditions.


Allow me to elaborate as that sounds awfully whiny.

The original DIP56 was actually ok because it left open the 
chance of implementing some kind of  always_inline/ never_inline 
with compile-time enforcement.  It was just worded poorly, so 
everyone appeared to think is was being proposed as 
half-implemented.

However, now with this latest proposal, it will always be used as 
an excuse for not implementing  always_inline/ never_inline with 
compile-time enforcement.

So, yes, we are better off than we are now with this proposal, 
but we lose the chance of being great.

Mike
Feb 03 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2015 4:24 PM, Mike wrote:

 ...it should read...

 pragma(inline, true);  // enable -inline compiler flag
 pragma(inline, false); // disable -inline compiler flag
 pragma(inline);        // use whatever is passed in on the command line

 ...as that is really the intent of DIP56 as confirmed by Walter [1].


Well, perhaps I worded that poorly. The compiler has a 'cost' function it uses 
to decide whether to inline or not. The pragma will cause it to ignore the cost 
function and always inline it.
Feb 03 2015
parent reply "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright 
wrote:

 The pragma will cause it to ignore the cost function and always 
 inline it.


So, if pragma(inline, true) ignores the cost function, will it 
*always* inline it, or always apply the -inline compiler flag 
rules (whatever they are)?

If the former, then I have misunderstood DIP56 yet again.

If the latter, then yes, it could have been worded better.

Mike
Feb 03 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2015 9:00 PM, Mike wrote:

 On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright wrote:

 The pragma will cause it to ignore the cost function and always inline it.


 So, if pragma(inline, true) ignores the cost function, will it *always* inline
 it, or always apply the -inline compiler flag rules (whatever they are)?

 If the former,


Yes.


 then I have misunderstood DIP56 yet again.
 If the latter, then yes, it could have been worded better.


Entirely my fault. Sorry about the confusion.
Feb 03 2015
parent "Mike" <none none.com> writes:
On Wednesday, 4 February 2015 at 05:03:03 UTC, Walter Bright 
wrote:

 So, if pragma(inline, true) ignores the cost function, will it 
 *always* inline
 it, or always apply the -inline compiler flag rules (whatever 
 they are)?

 If the former,


 Yes.


Ok, then please ignore all my posts on this topic if you aren't 
already.

Mike
Feb 03 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


Looks OK. Can't say that I fully understand your reasoning but 
this should at least be good enough to be practical :)
Feb 03 2015
prev sibling next sibling parent reply "ZombineDev" <valid_email he.re> writes:
Will this proposal allow to override the inlining of a function 
at the call site?
Feb 03 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2015 5:57 PM, ZombineDev wrote:

 Will this proposal allow to override the inlining of a function at the call
site?


No. It marks the function, not the call site.

Though there would a simple way to do this - make a 'never inline' function
that 
wraps the 'always inline' one, and call the former.
Feb 03 2015
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


It's a bikeshed argument, but why not:

pragma(inline, always);  // warn if unable to inline
pragma(inline, never);
pragma(inline);        // revert to default behavior

...?

I know `true` and `false` are keywords, but why confuse people? 
What is a "true" inline?
Feb 03 2015
next sibling parent zeljkog <zeljkog home.com> writes:
On 04.02.15 07:46, Zach the Mystic wrote:

 It's a bikeshed argument, but why not:

 pragma(inline, always);  // warn if unable to inline
 pragma(inline, never);
 pragma(inline);        // revert to default behavior

 ...?

 I know `true` and `false` are keywords, but why confuse people? What is
 a "true" inline?


I don't think it's about confusion or aesthetic.

For me it's about flexibility and evolution.

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

You can easily add new meaning.
pragma(inline, whatever);

There are maybe some potential here, why to preclude.
Feb 04 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/4/15 1:46 AM, Zach the Mystic wrote:

 On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot inline
 it, a warning will be generated. Implementations will likely vary in
 their ability to inline."


 It's a bikeshed argument, but why not:

 pragma(inline, always);  // warn if unable to inline
 pragma(inline, never);
 pragma(inline);        // revert to default behavior

 ....?

 I know `true` and `false` are keywords, but why confuse people? What is
 a "true" inline?


enum always = true;
enum never = false;

-Steve
Feb 05 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Thursday, 5 February 2015 at 14:43:40 UTC, Steven 
Schveighoffer wrote:

 On 2/4/15 1:46 AM, Zach the Mystic wrote:

 It's a bikeshed argument, but why not:

 pragma(inline, always);  // warn if unable to inline
 pragma(inline, never);
 pragma(inline);        // revert to default behavior

 ....?

 I know `true` and `false` are keywords, but why confuse 
 people? What is
 a "true" inline?


 enum always = true;
 enum never = false;

 -Steve


Actually, the better reason is that, as subsequently clarified, 
the pragma accepts a boolean expression, rather than just `true` 
or `false`, allowing for greater flexibility. Accepting an 
integer, for 3+ inlining strategies, would allow even more, but 
it might not carry its own weight (same with enum always = true;, 
because of namespace pollution). My gut says that an integer is 
better, but I don't know if there really are more than 3 good 
inlining strategies.

A more general approach would be:

enum {
   inlineOff,
   inlineOn,
   inlineDefault,
   codePathHot,
   codePathCold
}

pragma(optimize, inlineOn);
pragma(optimize, codePathHot);

You'd get everything here, with options to add more later. Note 
that codePathCold/Hot need not cancel inlineOff/On/Default, as 
they could be implemented as orthogonally.
Feb 05 2015
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot 
 inline it, a warning will be generated. Implementations will 
 likely vary in their ability to inline."


I like it. This feels better than the C++ force_inline attribute 
solution.

Would pragma(inline, <bool-expr>) be supported though? This would 
allow to pass inlining as a template parameter (can be useful to 
force recursive inlining, or to force inlining depending on the 
call point).
Feb 04 2015
next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 4 February 2015 at 09:39:56 UTC, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though? This 
 would allow to pass inlining as a template parameter (can be 
 useful to force recursive inlining, or to force inlining 
 depending on the call point).


Nice idea.
Feb 04 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


Yes. That's what I intended, sorry the wording wasn't clear.
Feb 04 2015
next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 4 February 2015 at 12:02:32 UTC, Walter Bright 
wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


As long as you're sure the pragma will never need more than three 
values ([revert to default], true, and false).
Feb 04 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


Please nail it down in the doc so it doesn't get neglected. -- Andrei
Feb 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- Andrei


Reading the DIP again,

"This adds a pragma 'inline', which is followed by an optional boolean 
expression, which influences the inlining of the function it appears in. An 
evaluation of 'true' means always inline, 'false' means never inline, and no 
argument means the default behavior."

Seems clear enough.
Feb 04 2015
next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- 
 Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional 
 boolean expression, which influences the inlining of the 
 function it appears in. An evaluation of 'true' means always 
 inline, 'false' means never inline, and no argument means the 
 default behavior."

 Seems clear enough.


That was me, based on what you had posted. I will now add "... 
default behavior, as indicated in the command line."
Feb 04 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 12:46 PM, Zach the Mystic wrote:

 On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional boolean
 expression, which influences the inlining of the function it appears in. An
 evaluation of 'true' means always inline, 'false' means never inline, and no
 argument means the default behavior."

 Seems clear enough.


 That was me, based on what you had posted. I will now add "... default
behavior,
 as indicated in the command line."


Thanks.
Feb 04 2015
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- 
 Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional 
 boolean expression, which influences the inlining of the 
 function it appears in. An evaluation of 'true' means always 
 inline, 'false' means never inline, and no argument means the 
 default behavior."

 Seems clear enough.


Also, the "Rationale" seems outdated now too. Currently: 
"Sometimes generating better code requires runtime profile 
information. But being a static compiler, not a JIT, the compiler 
could use such hints from the programmer."

I would change that rationale to this one (feel free to confirm 
and/or copy): "Programmers will sometimes want precise control of 
the compiler's inlining behavior, either to improve performance 
in debug builds, or to be completely sure that a function is 
inlined, or to ensure access to the function's runtime profiling 
information by not inlining it. This DIP addresses those needs. 
Warning: Careless forcing of inlining can decrease performance 
dramatically. Use with caution."

Also, speaking of hints to the compiler:

pragma(hotcodepath, true/false);

... seems really interesting to me, although that's clearly the 
subject for a different DIP. I just wanted to emphasize that the 
current DIP is not meant to address that feature.
Feb 04 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 4 February 2015 at 21:05:59 UTC, Zach the Mystic 
wrote:

 On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
 wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. 
 -- Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional 
 boolean expression, which influences the inlining of the 
 function it appears in. An evaluation of 'true' means always 
 inline, 'false' means never inline, and no argument means the 
 default behavior."

 Seems clear enough.


 Also, the "Rationale" seems outdated now too. Currently: 
 "Sometimes generating better code requires runtime profile 
 information. But being a static compiler, not a JIT, the 
 compiler could use such hints from the programmer."

 I would change that rationale to this one (feel free to confirm 
 and/or copy): "Programmers will sometimes want precise control 
 of the compiler's inlining behavior, either to improve 
 performance in debug builds, or to be completely sure that a 
 function is inlined, or to ensure access to the function's 
 runtime profiling information by not inlining it. This DIP 
 addresses those needs. Warning: Careless forcing of inlining 
 can decrease performance dramatically. Use with caution."

 Also, speaking of hints to the compiler:

 pragma(hotcodepath, true/false);

 ... seems really interesting to me, although that's clearly the 
 subject for a different DIP. I just wanted to emphasize that 
 the current DIP is not meant to address that feature.



Profile guided optimizations would also be an option I guess.

--
Paulo
Feb 05 2015
prev sibling next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- 
 Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional 
 boolean expression, which influences the inlining of the 
 function it appears in. An evaluation of 'true' means always 
 inline, 'false' means never inline, and no argument means the 
 default behavior."

 Seems clear enough.


It just occurred to me, you might to take an small integer as the 
second parameter, so people can customize their whole builds:

enum useDefaultInline = 0;
enum useProfilingInline = 1;
enum forceInlines = 2;

enum inlineStrategy = forceInlines; // change this at will

pragma(inline, inlineStrategy); // now you can get always, never, 
or default as you choose

With only a bool as the second parameter, you couldn't do this.
Feb 04 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 12:08 PM, Walter Bright wrote:

 On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:

 On 2/4/15 4:02 AM, Walter Bright wrote:

 On 2/4/2015 1:39 AM, ponce wrote:

 Would pragma(inline, <bool-expr>) be supported though?


 Yes. That's what I intended, sorry the wording wasn't clear.


 Please nail it down in the doc so it doesn't get neglected. -- Andrei


 Reading the DIP again,

 "This adds a pragma 'inline', which is followed by an optional boolean
 expression, which influences the inlining of the function it appears in.
 An evaluation of 'true' means always inline, 'false' means never inline,
 and no argument means the default behavior."

 Seems clear enough.


I have preliminarily approved http://wiki.dlang.org/DIP56 for post 
2.067. -- Andrei
Feb 04 2015
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 03 Feb 2015 14:29:59 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:


 http://wiki.dlang.org/DIP56
 
 There's been enough discussion, time to make a decision and move on.
 
 I changed the description to:
 
 "If a pragma specifies always inline, and the compiler cannot inline
 it, a warning will be generated. Implementations will likely vary in
 their ability to inline."


One thing this DIP should clearly state is whether a pragma(inline,
true) functions must still have a valid address.

The answer is probably yes as this is how C compilers handle inline.
This however makes pragma(inline, true) functions less useful as
replacements for C macros: The compiler will still have to
generate a complete function which takes up space in the object
file.


The reasoning why it can't be an attribute is kinda flawed. People
want this to be an compiler recognized UDA like in GDC (1), not a
normal attribute. UDAs never affect the function signature. 

(1)
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
Feb 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 3:08 AM, Johannes Pfau wrote:

 The compiler will still have to
 generate a complete function which takes up space in the object
 file.


Space in the object file is not important, space in the executable is. It's the 
linker's job to remove unreferenced functions (dmd places each function in its 
own section for that and other reasons). If the linker falls down on that job, 
an alternative is to use dmd to generate a library, where it will generate one 
object in the library per function. Then, the linker will only pull objects out 
of the library that are actually referenced.
Feb 04 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 4:08 AM, Walter Bright wrote:

 On 2/4/2015 3:08 AM, Johannes Pfau wrote:

 The compiler will still have to
 generate a complete function which takes up space in the object
 file.


 Space in the object file is not important, space in the executable is. It's the
 linker's job to remove unreferenced functions (dmd places each function in its
 own section for that and other reasons). If the linker falls down on that job,
 an alternative is to use dmd to generate a library, where it will generate one
 object in the library per function. Then, the linker will only pull objects out
 of the library that are actually referenced.


Forgot to mention, you could also use string mixins.
Feb 04 2015
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 04 Feb 2015 04:11:22 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 2/4/2015 4:08 AM, Walter Bright wrote:

 On 2/4/2015 3:08 AM, Johannes Pfau wrote:

 The compiler will still have to
 generate a complete function which takes up space in the object
 file.


 Space in the object file is not important, space in the executable
 is. It's the linker's job to remove unreferenced functions (dmd
 places each function in its own section for that and other
 reasons). If the linker falls down on that job, an alternative is
 to use dmd to generate a library, where it will generate one object
 in the library per function. Then, the linker will only pull
 objects out of the library that are actually referenced.


 
 Forgot to mention, you could also use string mixins.


OK, I just said the DIP should make that clear. I'm not going to
discuss this any further it's just wasted time.
Feb 04 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:08 AM, Walter Bright wrote:

 On 2/4/2015 3:08 AM, Johannes Pfau wrote:

 The compiler will still have to
 generate a complete function which takes up space in the object
 file.


 Space in the object file is not important


Yah, just within reason etc. etc. -- Andrei
Feb 04 2015
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.


Great, gets the job done and you even thought of on/off/default 
to apply this to multiple functions.
It provides the common inline hint semantics, so it should be 
easy to support across all compilers.
Feb 04 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-03 23:29, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and move on.


This is affected by the -inline flag?

-- 
/Jacob Carlborg
Feb 04 2015
next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 4 February 2015 at 18:00:19 UTC, Jacob Carlborg 
wrote:

 On 2015-02-03 23:29, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and 
 move on.


 This is affected by the -inline flag?


Interesting question. I'd say without -inline we don't perform an 
inline pass so nothing gets inline.
Feb 04 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 10:00 AM, Jacob Carlborg wrote:

 On 2015-02-03 23:29, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and move on.


 This is affected by the -inline flag?


With -inline:

     pragma(inline, true) inlines
     pragma(inline, false) does not inline
     pragma(inline) inlines at compiler's discretion

Without -inline:

     pragma(inline, true) inlines
     pragma(inline, false) does not inline
     pragma(inline) does not inline
Feb 04 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-02-04 21:06, Walter Bright wrote:


 With -inline:

      pragma(inline, true) inlines
      pragma(inline, false) does not inline
      pragma(inline) inlines at compiler's discretion

 Without -inline:

      pragma(inline, true) inlines
      pragma(inline, false) does not inline
      pragma(inline) does not inline


I see it's in the DIP now, that's great, thanks.

-- 
/Jacob Carlborg
Feb 05 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/3/15 5:29 PM, Walter Bright wrote:

 http://wiki.dlang.org/DIP56

 There's been enough discussion, time to make a decision and move on.

 I changed the description to:

 "If a pragma specifies always inline, and the compiler cannot inline it,
 a warning will be generated. Implementations will likely vary in their
 ability to inline."



Some details need to be explained, but I think this looks fine to me.

Please put in an example for each rule, that will probably help the details.

-Steve
Feb 05 2015