problem with size_t and an easy solution

[ketmar via Digitalmars-d]

On Wed, 10 Dec 2014 10:36:22 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via 
> Digitalmars-d wrote:
> > On Tue, 09 Dec 2014 17:28:15 +0000
> > Ivan Kazmenko via Digitalmars-d <digitalmars-d at puremagic.com> 
> > wrote:
> >
> >> A well-designed language allows to recover from errors with 
> >> good probability
> > if compiler can recover from error, it should not report the 
> > error at
> > all -- 'cause it can fix the code for me.
> >
> > that is absolutely nonsense, you *CAN'T* "recover" from invalid 
> > code.
> > that is the fact. fact: Earth is not a sphere. fact: you can't
> > automatically recover from invalid code.
> 
> That sounds much like an opinion, a lot less like a fact.  If you 
> are willing to convince people, please provide some evidence, 
> aside from another unrelated fact.
the ones who believes that recovery covers most of the cases should
bring proofs, not me. it's obvious that guessing on invalid input is
unreliable.

> In my experience, I find multiple reported compile errors useful 
> in a number of programming languages and compilers including D.  
> It allows for somewhat faster error fixing than the 
> first-error-only reporting strategy - seen that, too, back in the 
> Borland Pascal MS-DOS IDE and few other compilers.  I won't trade 
> the extra benefit just for philosophical notions.
most of the bugs compiler reports can be catched by good IDE without
compiling the source at all. what's left is bugs where all hell breaks
loose due to things that can't be "recovered" (like missing brackets,
for example -- and ah, that can be catched by IDE too!), thus producing
a pool of vomit.

and with fast compiler there is no sense in vomiting, as you physically
can't edit two code fragments simultaneously, thus you *will* fix bugs
one by one. and "go to next bug" hotkey can simply invoke fast compiler
to get another error message.

last, but not least: "recovering" attempts increases parser complexity.
-------------- 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/ff36ed14/attachment.sig>