On 03/08/13 19:38, Iain Buclaw wrote:
> On 8 March 2013 18:19, Artur Skawina <art.08.09@gmail.com <mailto:art.08.09@gmail.com>> wrote:Really "always_inline"? IIRC gcc throws an error if can't inline a function marked
>
> On 03/08/13 18:54, Iain Buclaw wrote:
> > Also not needed:
> > - aligned: because D has align() for that.
>
> D's align wasn't nearly enough last time i looked. (There were changes to
> it since, but as I can't upgrade, haven't looked at the details)
>
> > - gnu_inline, artificial: because D has no inline keyword, nor has need for one.
>
> always_inline is needed, the heuristics are not always enough. Of course it
> should map to just "inline".
>
>
> 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).
>
> 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.
with that one - in fact that was one reason why i had to use @flatten instead of
marking everything @always_inline - to avoid these errors. Things like methods
should not be marked as such, as they can be huge; the inlining heuristics should
be able to handle them.
It's good to have a way to mark pure functions as such, D's pure doesn't help
> > - 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.
>
> "const" may not be needed. "pure" is useful /exactly/ because of the D semantics.
>
>
> 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...
when the args aren't immutable, but the code is pure /logically/.