why ; ?

[Janice Caron]

On 08/05/2008, Leandro Lucarella <llucax at gmail.com> wrote:
>  Please remove " shitty and" in my previous mail and tell me what
>  flaws you find in my proposal?

Sure, but I think it's kinda obvious. In answer to your question:
"What's the point of putting unreal examples to prove a point?", the
reason is /to prove a point/.

The onus is on you to prove that no examples are ambiguous. I only
have to provide a single counterexample. That, I have done, as have
many other people. Whether or not an example is "real" or "unreal" is
in the eye of the beholder, but certainly I simplified my examples so
as to demonstrate /only/ the point being made. Superflous information
just sidetracks the issue.

I'm not sure there's anything further to say, however. The reason is,
when you said "Yes, in my suggestion you need to escape
false-newline-end-of-statement", you effectively closed all
ambiguities. My arguments were predicated on the assumption that there
would be no newline-escaping. That means, your plan /is/ workable -
but the price (having to escape newlines) is higher than I want to
pay. It becomes a matter of taste. I prefer C-style; you prefer
Python-style. Maybe you (or someone else who wants this) can write
that conversion tool I mentioned somewhere.

But even with the "you need to escape escape
false-newline-end-of-statement" rule, there is still room for silent
bugs to creep in. For example:

    foo(int x)  // Danger!
    {
        /* stuff */
    }

Under your scheme that would have to be rewritten as either

    foo(int x)  {
        /* stuff */
    }

or

    foo(int x)  \
    {
        /* stuff */
    }

or else run the risk of being misparsed as

    foo(int x);
    {
        /* stuff */
    }

which often times will be valid D. (Not always, but sometimes - e.g.
as an inner function). So unless you go "all the way" and aim for full
Python style, you run the risk of introducing some very hard to find
bugs.