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

Reply via email to