I've just thought of it... would be good if error and warning
numbers were the same across all the compilers, and to have
some language feature to turn them off. Remember that case
when you write a program for, say, VC++, disable some senseless
warnings using #pragma, and then compile it with BCC and get
all those things back - simply because warning IDs don't match.
Also, not all compilers support #pragma in the same manner...
so some standard construct for this would be really great.
For example, nowarning and noerror attributes:

    nowarning(123, 321)    // disable warnings 123 and 321
    {
        ...
    }

    noerror(456, 654)    // disable errors 456 and 654
    {
        ...
    }

Pavel Minayev wrote:
> I've just thought of it... would be good if error and warning
> numbers were the same across all the compilers, and to have
> some language feature to turn them off.

I'm pretty sure the error and warning IDs are the same
across all currently available D compilers. :)

-R

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a5dtef$1o6m$1@digitaldaemon.com...
> I've just thought of it... would be good if error and warning numbers were the same across all the compilers, and to have some language feature to turn them off. Remember that case when you write a program for, say, VC++, disable some senseless warnings using #pragma, and then compile it with BCC and get all those things back - simply because warning IDs don't match. Also, not all compilers support #pragma in the same manner... so some standard construct for this would be really great.

Unfortunately, doing this will dictate the parsing strategy/tool used. Different parser implementations will realize at different points that there's a syntax error, and so will necessarilly produce different messages. What is actually wrong is open to debate:

    a = b + c
    d + q;

Is the error a missing semicolon? Or is it a missing operator? The quality of error messages is a quality of implementation issue, and implementations should be free to try and produce the most accurate message possible. Certainly, in the C/C++ compiler business, there has been steady improvement in the quality of the error messages over the years.

Also, D will not have warnings. The language should be defined so it compiles or does not. Having various warning levels, and whether those warnings are real errors or not, what to do when some package you download gets warnings when compiling it, etc., are all problems with the language definition.

"Walter" <walter@digitalmars.com> wrote in message news:a5e4e0$1ren$1@digitaldaemon.com...

> Also, D will not have warnings. The language should be defined so it compiles or does not. Having various warning levels, and whether those warnings are real errors or not, what to do when some package you download gets warnings when compiling it, etc., are all problems with the language definition.

Look at it from another point: warning is when the compiler sees something that looks like an error, but cannot be sure it actually is - just like that "missing return" thing.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a5ean2$1ufd$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a5e4e0$1ren$1@digitaldaemon.com...
>
> > Also, D will not have warnings. The language should be defined so it compiles or does not. Having various warning levels, and whether those warnings are real errors or not, what to do when some package you
download
> > gets warnings when compiling it, etc., are all problems with the
language
> > definition.
> Look at it from another point: warning is when the compiler sees something that looks like an error, but cannot be sure it actually is - just like that "missing return" thing.

What needs to be done for each warning is look at why it's a warning and not an error. Then, adjust the language specification, or add something like your suggestion to throw an exception for missing returns.

"Walter" <walter@digitalmars.com> wrote in message news:a5egdb$21nn$1@digitaldaemon.com...

> What needs to be done for each warning is look at why it's a warning and
not
> an error. Then, adjust the language specification, or add something like your suggestion to throw an exception for missing returns.

Okay, so what about "parameter not used in function" argument that Borland C++ really likes? It seems pretty much logical to me since C/C++ has a neat feature of unnamed function parameters - those aren't reported as unused for obvious reasons. However, D does not allow unnamed parameters in function definition, but only in declaration... why?

API & callback functions are where this feature is mostly used:

    int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, int nCmdShow) { ... }
    int EnumWindowsProc(HWND hWnd, LPARAM) { ... }

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a5f5kb$2anr$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a5egdb$21nn$1@digitaldaemon.com...
>
> > What needs to be done for each warning is look at why it's a warning and
> not
> > an error. Then, adjust the language specification, or add something like your suggestion to throw an exception for missing returns.
>
> Okay, so what about "parameter not used in function" argument that Borland C++ really likes? It seems pretty much logical to me since C/C++ has a neat feature of unnamed function parameters - those aren't reported as unused for obvious reasons. However, D does not allow unnamed parameters in function definition, but only in declaration... why?

I suppose that naming them is a documentation thing, even though they are not used.

"Walter" <walter@digitalmars.com> wrote in message news:a5ffqd$2fli$1@digitaldaemon.com...

> I suppose that naming them is a documentation thing, even though they are not used.

There ain't much reason in naming them in callback function or WinMain. After all, if the argument is not used, it has no meaning - so it doesn't need a name (which usually ends up being "reserved" or "dummy" or something like that). Any additional info (like "must be 0") can be mentioned in accompanying comment.

"Walter" <walter@digitalmars.com> wrote in news:a5e4e0$1ren$1@digitaldaemon.com:

> 
> Unfortunately, doing this will dictate the parsing strategy/tool used. Different parser implementations will realize at different points that there's a syntax error, and so will necessarilly produce different messages. What is actually wrong is open to debate:
> 
>     a = b + c
>     d + q;
> 
> Is the error a missing semicolon? Or is it a missing operator? The quality of error messages is a quality of implementation issue, and implementations should be free to try and produce the most accurate message possible. Certainly, in the C/C++ compiler business, there has been steady improvement in the quality of the error messages over the years.
> 

Error detection is directly linked with the compiler implementation. But
the programmers errors have nothing, in most cases, with the compiler.
They are linked with syntax or semantic.
In the same way, the message showed for the programmer could depend of
compiler implementation. But the error is the same in all compilers. The
error is in the same point and different compilers could detect or
choose different errors.

But there are advantages in standartizing error messages. All compilers
will need treat the same errors.
Supose the following:

compiler A :

source.d Error 123 Line 456 column 78 : Missing parameter to function.

compiler A :

source.d Error 123 Line 456 column 78 : Missing parameter "Param" to function.

The error messages will be more accurated depending the compiler implementation. But the error is the same and the error code is the same.

This will help writing documentation for errors, integrating texteditors with the compilers and so on.

Of course cannot we standartizing all errors possible. But we can allow ranges of errors :

0-10000 : language errors
20000-30000: environment errors
10000-20000: specific compiler errors

comments ?

"Juarez Rudsatz" <juarez@correio.com> wrote in message
news:Xns91C390C7D5CBEjuarez@63.105.9.61...
<SNIP>
> The error messages will be more accurated depending the compiler implementation. But the error is the same and the error code is the same.
>
> This will help writing documentation for errors, integrating texteditors with the compilers and so on.
>
> Of course cannot we standartizing all errors possible. But we can allow ranges of errors :
>
> 0-10000 : language errors
> 20000-30000: environment errors
> 10000-20000: specific compiler errors
>
> comments ?

Fairly good idea, although I hate ranges, because you always end up with one range nearly filled while another uses only a few numbers....It would be well suited for this though, but how far can you extend the idea, because this on it's own will not really help that much.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail