Steven Schveighoffer, el 3 de agosto a las 11:53 me escribiste: > >But the DIP I wrote isn't about general-purpose annotations. It's just the > >first step. Are "pure" and "nothrow" part of the mangling? Or which are? I > >thought not. Can you overload a pure and a not-pure function with the same > >parameter count and types? > > Yes, they have to be. There are reasons besides overloading for including > other > attributes in the naming. > > For example, if a function is pure, then becomes unpure, you don't existing > code > that is expecting a pure function to link against it. > > In other words, the linker is dumb. It only knows how to match symbols, so > you > have to embed into the symbols the important pieces of the interface that you > want the linker to consider important. > > To answer Don's point, there is nothing saying that the compiler can't read > attributes and change its behavior. Of course, those would have to be > builtin > attributes. > > My opinion on removing existing keywords is -- don't. There's little to no > gain. Let that ship sail, and concentrate on future keyword proposals.
I think old keywords can be maintained for backward compatibility but deprecated (allowing using both "naked" keywords or "annotations"), favoring the usage of annoatations where sensible. In a far far future, the old keywords can be removed if annotations prove to be a success. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Novocaine for the soul you better give me something to fill the hole before I sputter out