<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 March 2013 19:00, Artur Skawina <span dir="ltr"><<a href="mailto:art.08.09@gmail.com" target="_blank">art.08.09@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/08/13 19:38, Iain Buclaw wrote:<br>
<div class="im">> On 8 March 2013 18:19, Artur Skawina <<a href="mailto:art.08.09@gmail.com">art.08.09@gmail.com</a> <mailto:<a href="mailto:art.08.09@gmail.com">art.08.09@gmail.com</a>>> wrote:<br>
><br>
>     On 03/08/13 18:54, Iain Buclaw wrote:<br>
>     > Also not needed:<br>
>     > - aligned:  because D has align() for that.<br>
><br>
>     D's align wasn't nearly enough last time i looked. (There were changes to<br>
>     it since, but as I can't upgrade, haven't looked at the details)<br>
><br>
>     > - gnu_inline, artificial:  because D has no inline keyword, nor has need for one.<br>
><br>
>     always_inline is needed, the heuristics are not always enough. Of course it<br>
>     should map to just "inline".<br>
><br>
><br>
> inline and always_inline are two subtly different beasts.  But altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).<br>
><br>
> Some things are marked as always_inline anyway by gdc:  struct/class methods, lambdas and delegate literals.  Though it is probably known that this only worked within the module being compiled.  Cross-module inlining is not there yet.<br>

<br>
</div>Really "always_inline"? IIRC gcc throws an error if can't inline a function marked<br>
with that one - in fact that was one reason why i had to use @flatten instead of<br>
marking everything @always_inline - to avoid these errors. Things like methods<br>
should not be marked as such, as they can be huge; the inlining heuristics should<br>
be able to handle them.<br>
<div class="im"><br>
>     > - pure, const:  Although D has pure keyword that does not necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.<br>
><br>
>     "const" may not be needed. "pure" is useful /exactly/ because of the D semantics.<br>
><br>
><br>
> Infact, strongly pure functions (where all parameters are immutable) are indeed marked as C "pure" by gdc if the functions are also nothrow.  Whether this might cause some bad behaviour I'm yet to run into or find a case of...<br>

<br>
</div>It's good to have a way to mark pure functions as such, D's pure doesn't help<br>
when the args aren't immutable, but the code is pure /logically/.<br>
<div class="im"><br></div></blockquote><div><br></div><div>If the code is pure logically, it may be const folded away by the GCC backend given correct circumstances.  However what we don't want to happen is for it to accidentally optimise away a call that may alter an internal state that affects runtime behaviour.<br>
<br></div></div><br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra">-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>