Steffen Wrote:Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.
If the new syntax is optional, and you anyway have to implement fallback code, then you could use the fallback code from the beginning. That proves the redundancy of the new syntax.
Hi Steffen,
Except: the old fallback code will produce _incorrect output_ some of the time (because the fallback code cannot distinguish between header comments like "this is what needs to be fixed" and implementation comments like "first outer contour of left flange").
So if a programmer cares about correctness of parsing, then the fallback code does not render the new syntax (and new code) redundant because the new code+new syntax fixes an otherwise unfixable bug.
So...I think you can make the argument, if you wish, that the cure is worse than the disease, that this is a small bug and a meta is a big deal, and that the value trade-off is not good.
But I do not think you can make the argument that the syntax does not solve a currently unsolvable problem.
@Allen: I think that not only can you not right a future-proof algorithm, but you can't even parse the headers correctly now. But the point about future-proofing is important too - even if we were to fix this bug by "fixing" the spec (e.g. just saying no comments in the headers, ever) the introduction of new directives and new metas would break parsing.
@Steffen, one last thought: any time new syntax is optional and tries to make things easier, I agree that it does temporarily make things harder for programmers (by putting a second case into the spec).
But such "let's try again" format changes also start a clock; if we hope to ever move to cleaner formatting that allows for simple parsing, better to get the extension sorted out sooner. Then later, the part library can be searched for non-conforming parts, they can be batch-updated, and eventually the optional can be dropped by a new extension. That's a long, slow process, but it's even slower if we defer introducing a syntax fix.
(That's not an argument that this is really important either, of course.)
Cheers
Ben