"Alisdair Meredith" <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | | > I know the proposals did not dig into all the corner cases -- and I | > don't even know whether they considered the case. But, at some point, | > someone has to go through the sheer number of proposals and try to | > paint a global picture and see how they interact with existing | > implementation techniques; C++ is not known to be orthogonal :-) | | Oh, we dug through that proposal quite thoroughly <g>
no doubt, but I claim the coverage wasn't complete and did not consider other proposals that are targetting the same syntactically crowded areas and semantically connected notions. | I specifically brought up the case of diagnosing recursion and making | it malformed. The consensus was that while it was clearly a | programming error to write recursive ctors, no-one wanted to diagnose | recursive chains of calls, especially with all the other wonders we can | throw in to make 'indirect' recursion hard to detect. I don't consider it "nice". I think it is an essential invariant. | It would be nice if there was a sop in there so that well-meaning | implementations could choose-but-not-be-required-to declare the easily | diagnosed cases malformed, but I don't think that got any support | either, as no-one was aware of anyone wanting to do this. | | The point I forgot to make though, is that any program using recursive | constructors is broken, so I don't know how much it is worth worrying | about g++ implementation details for broken programs - it might be best | to just ignore the issue (so long as it does not produce new | compile/link time errors, and I don't think that is the case here) By the same token, any program that contains an error is broken. Consequently, we should remove the notion of diagnosable constructs. -- Gaby