On 03/08/13 19:38, Iain Buclaw wrote: > On 8 March 2013 18:19, Artur Skawina <art.08...@gmail.com > <mailto: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.
Really "always_inline"? IIRC gcc throws an error if can't inline a function marked 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. > > - 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... It's good to have a way to mark pure functions as such, D's pure doesn't help when the args aren't immutable, but the code is pure /logically/. > > - 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. Oh, I'm just mentioning this because marking some code to be compiled for one cpu, and having other unrelated code be mistakenly built for that cpu can result in nasty bugs. These attributes are useful, but there are easy workarounds, like compiling the code separately, so supporting them can indeed be very low prio. artur
