problem with size_t and an easy solution

[bitwise via Digitalmars-d]

> D devs are quite willing to improve error messages, they have 
> improved many of them.

I'm not trying to call anyone lazy ;) Sometimes though, the bugs 
I imagine I would submit seem like they would lead to a wild 
goose chase more than a solution.

> Don't forget to mention DustMite.

I'll definitely check this out.

> 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.

I suppose the rest of the errors could be generated on a second 
pass though. For example, if the first error was an unidentified 
identifier, the compiler could then re-parse the file and report 
all instances of that identifier's usage.

> D compiler is fast enough to stop that horrible "now you have
> 100500 errors reported, enjoy" practice.

On the other hand, this sounds a lot like failed template 
instantiations in old versions of MSVC ;)

> the second thing that i want to have is compiler explaining why 
> it
> rejected some templates. i.e. what constrains failed. those 
> messages
> about "can't instantiate" are among the most noisy and cryptic 
> ones.

Yep.