On 30/06/17 10:11, Alexander Monakov wrote: > On Fri, 30 Jun 2017, Andrew Haley wrote: >> Perhaps so. However, it would make more sense and be more maintainable >> if, rather than use a command-line option, a variable attribute was used >> to tell the compiler what this program is supposed to mean. IMO. > > Correction: this can't be a variable attribute, because when you take a pointer > to such object, the property remains relevant to the result of dereferencing > that pointer. Therefore, it would need to be a type attribute as Richard said. > > I'd caution against adding attributes due to source code uglification and > compiler compatibility concerns. > > An option is also simple; adding the attribute would be repeating history with > refusing native 128-bit CAS-based atomics due to r/o issue: creating extra work > for compiler writers and frustration for users, only to handle an edge case they > don't care about. > NO. AN OPTION WILL NOT WORK. An option cannot fix up existing binary objects and change the ABI that they expect. You cannot force a recompile on all users so the ABI for this type is NOW FIXED. Mixing objects with potentially different ABIs in play is a recipe for disaster. As they say: Get over it. R. > Alexander >
