In article <cc2ai7$25r$1@digitaldaemon.com>, Russ Lewis says...
>
>Ok, I'm not going to take sides on the warning issue, because frankly I agree with both sides here.  But I am going to jump in and say that you could treat this as an error, and still handle the legitimate cases, if you had an 'expire' construct, that worked like this:
>
>   int foo(int a)
>   {
>     expire a;
>     return 1;
>   }
>
>'expire' would simply make a contract that a variable must not be used later in the function.  So, it would be an error to have a function which did not use one of its arguments - unless it explicitly expired them.  It is an explicit contract of "I don't care about this value."

The equivalent thing in C/C++ would be to define foo this way:

int foo(int) { return 1; }

Thus indicating to the compiler that the parameter is not used in the function body.  D does not allow this syntax, but I favor it over the "expire" idea since it avoids the creation of a new keyword.


Sean

In article <cc4bb3$ap1$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <cc2ai7$25r$1@digitaldaemon.com>, Russ Lewis says...
>>
>>Ok, I'm not going to take sides on the warning issue, because frankly I agree with both sides here.  But I am going to jump in and say that you could treat this as an error, and still handle the legitimate cases, if you had an 'expire' construct, that worked like this:
>>
>>   int foo(int a)
>>   {
>>     expire a;
>>     return 1;
>>   }
>>
>>'expire' would simply make a contract that a variable must not be used later in the function.  So, it would be an error to have a function which did not use one of its arguments - unless it explicitly expired them.  It is an explicit contract of "I don't care about this value."
>
>The equivalent thing in C/C++ would be to define foo this way:
>
>int foo(int) { return 1; }
>
>Thus indicating to the compiler that the parameter is not used in the function body.  D does not allow this syntax, but I favor it over the "expire" idea since it avoids the creation of a new keyword.

and we can make intellisense for IDEs aware of it.

Ant

Sean Kelly wrote:
> In article <cc2ai7$25r$1@digitaldaemon.com>, Russ Lewis says...
> 
>>Ok, I'm not going to take sides on the warning issue, because frankly I agree with both sides here.  But I am going to jump in and say that you could treat this as an error, and still handle the legitimate cases, if you had an 'expire' construct, that worked like this:
>>
>>  int foo(int a)
>>  {
>>    expire a;
>>    return 1;
>>  }
>>
>>'expire' would simply make a contract that a variable must not be used later in the function.  So, it would be an error to have a function which did not use one of its arguments - unless it explicitly expired them.  It is an explicit contract of "I don't care about this value."
> 
> 
> The equivalent thing in C/C++ would be to define foo this way:
> 
> int foo(int) { return 1; }
> 
> Thus indicating to the compiler that the parameter is not used in the function
> body.  D does not allow this syntax, but I favor it over the "expire" idea since
> it avoids the creation of a new keyword.

I agree that it is desirable to avoid a new keyword.  However, let me point out another use for expire that is hard (sometimes impossible) to do currently:

void bar() {
  int rc = GoDoStuff();
  if(rc != 0)
    throw SomeSortOfException;
  expire rc;	// we're not going to use this value again

  ...more code...
}

Thus, 'expire' would help us write more self-documenting code.

Walter wrote:
> Check out this exerpt from:
> 
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
<snip>

Arcane Jill has half taken the words out of my mouth, but I'll say it anyway.  The idea of a _language_ having warnings or not having warnings makes little or no sense to me.  Indeed, does the C specification say anything about whether the compiler should complain about an unused function parameter, a comparison with an inherently constant truth value, or the common typo of

	if (qwert = yuiop) { ... }

...?

Different compiler writers, and hence different compilers, have different conceptions of what is probably a coding error and what isn't.  For example, Borland C++ has warnings that GCC doesn't, and vice versa.

Is this meant to be a decree that any D compiler written by anybody should never output a warning in its life?  This has its own problems. Three options remain:

(a) let the dodgy code silently slip through, no matter how dodgy it is.  This would hinder the principle of eliminating common bugs from the start, and consequently reduce the scope for competition in implementation quality.  Since D aims to help get rid of common bugs, it seems silly to try and stop different compilers from helping further.

(b) take anything the implementer feels is dodgy as an error.  This could seriously break the other bit of D philosophy: portability.

(c) have (a) and (b) as separate compilation modes.  (a) would be used to compile programs written by someone else, (b) would be used to compile your own stuff.  But what about using libraries?  You'd end up mixing the two compilation modes in the process of building a project, even within a single module and its imports.

I for one don't know what I'd do if I decided to write a D compiler....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

On Mon, 05 Jul 2004 11:53:13 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Walter wrote:
>> Check out this exerpt from:
>>
>> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
> <snip>
>
> Arcane Jill has half taken the words out of my mouth, but I'll say it anyway.  The idea of a _language_ having warnings or not having warnings makes little or no sense to me.  Indeed, does the C specification say anything about whether the compiler should complain about an unused function parameter, a comparison with an inherently constant truth value, or the common typo of
>
> 	if (qwert = yuiop) { ... }
>
> ...?
>
> Different compiler writers, and hence different compilers, have different conceptions of what is probably a coding error and what isn't.   For example, Borland C++ has warnings that GCC doesn't, and vice versa.
>
> Is this meant to be a decree that any D compiler written by anybody should never output a warning in its life?  This has its own problems. Three options remain:
>
> (a) let the dodgy code silently slip through, no matter how dodgy it is.   This would hinder the principle of eliminating common bugs from the start, and consequently reduce the scope for competition in implementation quality.  Since D aims to help get rid of common bugs, it seems silly to try and stop different compilers from helping further.
>
> (b) take anything the implementer feels is dodgy as an error.  This could seriously break the other bit of D philosophy: portability.
>
> (c) have (a) and (b) as separate compilation modes.  (a) would be used to compile programs written by someone else, (b) would be used to compile your own stuff.  But what about using libraries?  You'd end up mixing the two compilation modes in the process of building a project, even within a single module and its imports.
>
> I for one don't know what I'd do if I decided to write a D compiler....

It's my impression that compilation and lint-like processing are 2 different steps.
The compiler does the first, it does not do the second.

What this means is that regardless of which D *compiler* you use, you will get the exact same errors. This gives the code greater portability, no more weird errors on system X.

In addition, imagine you are writing a cross platform app, compiling it on Windows, Linux, FreeBSD, MacOSX, ..etc.. why do the lint-like process X times (where X is the number of operating systems you compile for), you only *need* to do it once.

Furthermore, you want to be able to choose which lint-like program to run, with your favourite config options and you want to run it on the fastest hardware, not that old Mac you use for your MacOSX compilations.

Walter has implied that it would be easy to write a lint-like program using the DMD front end. I suggest that anyone who is really worried about catching these sorts of 'possibly a coding error' errors starts a lint-like project using the dmd front end.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opsany5h0b5a2sq9@digitalmars.com>, Regan Heath says...
>
>It's my impression that compilation and lint-like processing are 2
>different steps.
>The compiler does the first, it does not do the second.
>
>What this means is that regardless of which D *compiler* you use, you will get the exact same errors. This gives the code greater portability, no more weird errors on system X.
>
>In addition, imagine you are writing a cross platform app, compiling it on Windows, Linux, FreeBSD, MacOSX, ..etc.. why do the lint-like process X times (where X is the number of operating systems you compile for), you only *need* to do it once.
>
>Furthermore, you want to be able to choose which lint-like program to run, with your favourite config options and you want to run it on the fastest hardware, not that old Mac you use for your MacOSX compilations.
>
>Walter has implied that it would be easy to write a lint-like program using the DMD front end. I suggest that anyone who is really worried about catching these sorts of 'possibly a coding error' errors starts a lint-like project using the dmd front end.
>
>Regan.


An interesting idea, but it sounds like solving the problem just by calling things by different names. Which is okay, of course.

What I mean is, if a third party brought out the ACME-D compiler which generated warnings, it could get away with it just by calling itself, not a compiler, but a lint-tool and compiler combined. It could simply state that it was the lint-component, not the compiler-component, which was generating the warnings, and everyone would be happy. Well, I'd buy it.

However, I imagine that those purists who argue that D is so inherently well-defined that there should never be any such thing as a warning (and I am not one of them) might see this as just re-introducing warnings through the back door.

Well, whatever. I'd be happy to call it a lint add-on if it did the job and kept everyone happy.

Arcane Jill

On Mon, 5 Jul 2004 20:51:12 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:
> In article <opsany5h0b5a2sq9@digitalmars.com>, Regan Heath says...
>>
>> It's my impression that compilation and lint-like processing are 2
>> different steps.
>> The compiler does the first, it does not do the second.
>>
>> What this means is that regardless of which D *compiler* you use, you will
>> get the exact same errors. This gives the code greater portability, no
>> more weird errors on system X.
>>
>> In addition, imagine you are writing a cross platform app, compiling it on
>> Windows, Linux, FreeBSD, MacOSX, ..etc.. why do the lint-like process X
>> times (where X is the number of operating systems you compile for), you
>> only *need* to do it once.
>>
>> Furthermore, you want to be able to choose which lint-like program to run,
>> with your favourite config options and you want to run it on the fastest
>> hardware, not that old Mac you use for your MacOSX compilations.
>>
>> Walter has implied that it would be easy to write a lint-like program
>> using the DMD front end. I suggest that anyone who is really worried about
>> catching these sorts of 'possibly a coding error' errors starts a
>> lint-like project using the dmd front end.
>>
>> Regan.
>
>
> An interesting idea, but it sounds like solving the problem just by calling
> things by different names. Which is okay, of course.

It is.. and it isn't. I think the core idea is that to be called a D compiler it must behave as do all other D compilers (if only by default). This gives all the benefits I have mentioned above:
 - portability of code
 - speed/efficiency of compilation
 - flexibility to choose (the lint process/options)

This does not mean a D compiler cannot have a non-conformant 'mode', this mode should not be the default mode however.

> What I mean is, if a third party brought out the ACME-D compiler which generated
> warnings, it could get away with it just by calling itself, not a compiler, but
> a lint-tool and compiler combined. It could simply state that it was the
> lint-component, not the compiler-component, which was generating the warnings,
> and everyone would be happy. Well, I'd buy it.

As long as ACME-D did not do the lint-processing by default, no problem.

Making the 2 processes part of the same executable does have benefits:
 - smaller than 2 containing the same dmd front-end or similar syntax processing code.
 - you only need one executable to do both things, more likely it's installed on system X.
 - you can do both in 1 step.

So as long as lint processing is not the default behaviour you only get benefits from doing it this way.

> However, I imagine that those purists who argue that D is so inherently
> well-defined that there should never be any such thing as a warning (and I am
> not one of them)

I don't believe this is even possible. The compiler can and does know the syntax and can verify that. The compiler cannot and does not know your intent, it only knows what you wrote, not what you meant to write.

> might see this as just re-introducing warnings through the back door.

Not the secretive back door, instead the more obvious and well signposted service entrance.

> Well, whatever. I'd be happy to call it a lint add-on if it did the job and kept everyone happy.

An 'add-on' by it's very nature is not 'default', so by renaming it, we have defined behaviour which I believe is the best way to handle this desire/situation.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/