On 8 March 2013 18:19, Artur Skawina <art.08...@gmail.com> wrote: > 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. > > > - 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... > > - optimise, target: I'm sure the guy who implemented these meant well, > but I fail to see the point as to why you'd want such an attribute. > > They are useful. And it reminds me that last time i looked, GDC handled > "target", "tune" > etc wrongly: > http://forum.dlang.org/post/mailman.1.1325716211.16222.digitalmar...@puremagic.com > > And I'd rather not want to spend time fixing it. The code that handles these attributes are a bit bulky, and require a bit of questionable copying from the c-family frontend. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
