problem with size_t and an easy solution

[ketmar via Digitalmars-d]

On Tue, 09 Dec 2014 18:08:48 +0000
bitwise via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> > somehow Walter can't accept that after emiting the first error 
> > compiler
> > is in undefined state, and trying to pretend that it is in 
> > well-defined
> > state or guess what well-defined state must be is a nonsense.
> 
> I don't think I would call this nonsense. MSVC for example, often 
> emits multiple errors correctly. I haven't checked this with 
> MSVC, but I imagine an unidentified identifier could be a case 
> where this is possible. Also, many intellisense systems are able 
> to recover after multiple errors and continue parsing a file.
so let "intellisense-like" systems do the guesswork. i don't trust a
compiler that tries to guess what i mean instead of reporting the error
and stop right there. i.e. i once tried PL/1 compiler which was able to
"guess" what lone `IF` means. and now i don't want the compiler to
do *ANY* guesswork. it's ok for support tools, but compiler should not
claim that it can "recover" from invalid code, 'cause invalid code
is... well... invalid and irrecoverable without manual human fixing.
and if it is "recoverable", why do i have to do any manual fixing at
all? if compiler is so smart, he should fix the code and go on.

see, you *CAN'T* recover from such error. even in D you can catch Error,
but program state is already undefined. in the case of compiler the
state of the compiler itself is defined, but input data is trashed. i
can't see any sense in trying to figure out something sane from trashed
input. let the user fix the input instead of guessing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141210/7f887511/attachment-0001.sig>