Christian Schladetsch wrote:
I have skimmed this thread and wanted to offer my opinion.
I do not see code like the OP has provided in what I write, so to me this is a solution looking for a problem. Like most, I prefer small blocks of code with simple patterns such as:
type method(args) { if (cond(args)) return foo(args); intermediate val = calc(args); return result(val, args); }
The case for 'Breakable' seems to be to support a code style that is, pardon me, quite archaic. As has been noted in this thread, if the code was written to be modular and self-documenting to start with, there is no need for 'breakable'.
It really is just a way of inlining an anonymous half-function, with implicit arguments and an implicit return type. Contrary to the authors claims, I do not see this as a mechanism for producing better or more readable code.
It is not very common but sometimes logical structure of a function can be expressed more precisely using a control flow statement similar to this breakable thing. As Gottlob Frege has pointed out this kind of logic sometimes occur in Windows GUI programming. It seems to me that DirectX API at least in some old versions also tend to cause this kind of logic in the client code. Here is a real life sample I was able to find using Google Code search: http://tinyurl.com/mlc6zo We are trying to load a cursor. There are 3 different points were it can fail. And we want to return a default cursor in case of any failure. Another context were this kind of logic may appear are parsers. Here is another real life sample: http://tinyurl.com/ljq5n9 I do not think that "cutting out" the "do { ... } while (false);" part into a separate function would add readability. I do agree that it is possible to use this breakable construct incorrectly. Actually most of the uses of "while (false)" that I have looked through (with exception of usages inside macros definitions) while looking for these examples were "incorrect" usages in a sense that using a separate function would improve readability. My point is that not *all* usages of breakable construct are "archaic". There are reasonable use cases. Cretan languages support this "breakable" construct natively. OvermindDL1 wrote that D have something similar and it was designed quite recently. I can add that Perl have direct support for this kind of control flow. In Perl it looks like this: { /* Code */ last if /* block termination condition */ /* More code */ last if /* another block termination condition */ /* The rest of the block code */ } /* All "last" jumps here */ Almost exactly as in Gottlob Frege's hypothetical sample.
At the end of the day, it is about style and for that reason I do not think it is a good candidate for inclusion into boost. [...]
It may be that I'm just missing your point, but it seems to me that you are telling that Boost should impose a certain coding style on its users. Isn't it better to support different coding styles then to impose one on everyone around? On a related topic I have just remembered that I have "discovered" another not very common but still recurring control flow construct. In C++ it looks like this: while (true) { /* code */ if (/* above code failed */) continue; /* code */ if (/* failed */) continue; /* more code */ break; } Perl is the only language I know of to have support of this construct almost natively. It has a redo command that restarts current loop iteration and it treats an unnamed block as a loop that is executed once. -- Ilya Bobir