On Mon, 3 Sep 2012, Andrew Haley wrote: > This isn't the only way to proceed. I'd encourage someone wanting to > do this to branch GCC and implement a rough cut of the feature. That
That would very likely be "build one to throw away" - features built without a clear definition of how they interact with other language features have been particularly problematic in the past. So have extensions built based on "take this feature from another language, and put it in GNU C". > will provide useful information about the amount of work likely to be > needed to complete the task. Also, it will provide the opportunity to > try out the language feature to see how well it works in practice. Whether people *will* use it is probably the more significant question than whether it *can* be used to address particular issues. Given that code needs to be modified for "strict mode", the key question is why people would care to do that (or, for that matter, to use the feature in new code) any more than they've cared to modify large bodies of existing code for most of the other approaches (based on annotations, new library facilities, etc.) that have been tried - not a technical question, but one about the practical lifecycle of code. The most people seem to do much in practice is limited local changes to the use of library facilities such as changing sprintf to snprintf. It's the question about why users would react to this feature differently from all the others that a compelling answer is most needed to. -- Joseph S. Myers jos...@codesourcery.com