In article <cu454v$7km$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3tn3$292$1@digitaldaemon.com...
>> I would agree, for reasons of legacy breaking, were it not that D is pre-1.0. Since I'm coming to believe more and more that PwC should _not_ be considered a debug only thing, I think it should be the default.
>>
>> Naturally, I'm looking at this from the perspective of large commercial systems. For simple utilities, I'd be adding -contracts=off to my makefiles, and be content with that decision.
>>
>> Walter, may we have it on by default? (and divorce from debug?)
>>
>> Please. I'll be polite. Honest, ...., mate! :-)
>
>It is on by default. All -release does is turn it off. You could compile with:
>
>dmd -O foo
>
>and you'll get debug off, contracts on, optimization on.
>

But right now (when not using -release) there are invariant calls for each method of each class even when the class doesn't have or inherit an invariant definition.

Can that issue be addressed?

Thanks,

- Dave

I'd just like to say three more things and then I'll shut up since no one asked me anyway:

1. I never said whether I actually think a warning of some sort would be nice.  To say it now: I would like one indeed, although lint would be okay.

2. Some of you live in a vacuum where only bad programmers make mistakes and where maintenance programmers find every flaw there is.  Read this: Customers see bugs in software all of the time.  It happens.  Get over it.  Now make it so when they see it they don't use other software because it screws them over.

3. The code below is what I hate about this feature in some compilers. If I throw an exception I *should not* have to put a return (but have to at least in, for example, C# last I checked.)  If the compiler can detect unreachable code, why can't it detect that?

-[Unknown]

>     int foo(CollectionClass c, int y)
>     {
>         foreach (Value v; c)
>         {
>             if (v.x == y)
>                 return v.z;
>         }
> 
>         throw logic_error("This function has encountered a situation which contradicts its design and/or the design of the software within which it resides");
> 
>         return 0;
>     }

In article <cu4c88$ecu$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu45td$89b$1@digitaldaemon.com...
>> Cool. Sounds like the _only_ thing to do is rename the misnomer "-release" to "-nocontracts". Can we have that, and forestall all the wasted mental cycles for people who have to learn what it really means?
>
>The original idea behind -release was to not require the DMD programmer to learn a bunch of arcane weird switches (look at any C++ compiler!), there'd be a switch that would make it "just work".
>
>Looks like I failed :-(

Maybe you could recycle -release to turn off contracts and debug, etc. It appears that you also need to provide individual control for the major D features.

Do the GDC folks use the same switches?


>

Mark T wrote:

> Do the GDC folks use the same switches?

For the most part, yes. See this page:
http://home.earthlink.net/~dvdfrdmn/d/

With GDC, they are called for instance:
-frelease
-finline-functions
-fbounds-check
-fdeprecated
-funittest
-fdebug
(i.e. usually the same, with a "f" prefix)

There's also a "dmd" wrapper perl script,
that converts DMD syntax to a GDC call...

--anders

PS.
The Missing Manual Pages can be found at:
http://www.algonet.se/~afb/d/d-manpages/

> I don't think it would be hard to morph the D front end code into a lint. Such a program could also be configurable by the end user to enforce the local coding style guide. I think it could be a valuable tool. Anyone looking for a D project to do? <g>

I hope someone picks this up. Some of the possible rules that come to mind:
1) casting arrays to pointers vs using the ptr property
2) unused variables
3) dead code
4) returns at end of functions
5) switch statements without default clauses
6) checks for compilation errors
7) properties with getters and setters that mismatch types
8) replace simple for loops with foreach
9) comparing an object with null using ==, < or >

maybe some others...
10) replace memmove/memcpy with slice assignment
11) using an floating point or char variable that has been initialized (I
know D initializes all variables but the initial values for some types are
chosen to usually force programmers to initialize variables)

Ben Hinkle wrote:

> Some of the possible rules that come to mind:

> 5) switch statements without default clauses

Currently this throws an Error at run-time, for non-release builds.
"Error: Switch Default"

This Exception is not thrown with -release. (like ArrayBoundsError)

> 6) checks for compilation errors

Using -c sort of works, with the side effect of generating objects.

> 9) comparing an object with null using ==, < or >

Hopefully this will be made into a "hard" compilation error, even ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cu5d4b$19r6$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> Some of the possible rules that come to mind:
>
>> 5) switch statements without default clauses
>
> Currently this throws an Error at run-time, for non-release builds. "Error: Switch Default"
>
> This Exception is not thrown with -release. (like ArrayBoundsError)

That's why it would make a good candidate for dlint. It is legal code but potentially dangerous. I can sympathize with Walter's argument that "potentially dangerous" shouldn't necessarily be "illegal" (maybe I shouldn't put words in his mouth but hopefully I'm not too far off the mark). A tool to find potentially dangerous code should be available.

>> 6) checks for compilation errors
>
> Using -c sort of works, with the side effect of generating objects.

plus dlint should generate output that is easy to parse by other tools. The compiler generates errors when it has to but its main job is to compile code. I wouldn't expect it to have a nice interface for dlint-like uses. Plus I would bet the output format would change from compiler to compiler so each tool would have to have special logic for parsing the output of every supported compiler.

>> 9) comparing an object with null using ==, < or >
>
> Hopefully this will be made into a "hard" compilation error, even ?

Actually I would be satisfied if dlint caught it. I just worry about my ported Java code that has these things floating around. I've been scanning the code manually or with grep but without some tool I just don't have confidence that I've found all the bugs. To me it doesn't really matter if that tool is the compiler or something else.

>
> --anders

Ben Hinkle wrote:
>>I don't think it would be hard to morph the D front end code into a lint.
>>Such a program could also be configurable by the end user to enforce the
>>local coding style guide. I think it could be a valuable tool. Anyone
>>looking for a D project to do? <g>
> 
> 
> I hope someone picks this up. Some of the possible rules that come to mind:
> 1) casting arrays to pointers vs using the ptr property
> 2) unused variables
> 3) dead code
> 4) returns at end of functions
> 5) switch statements without default clauses
> 6) checks for compilation errors
> 7) properties with getters and setters that mismatch types
> 8) replace simple for loops with foreach
> 9) comparing an object with null using ==, < or >
> 
> maybe some others...
> 10) replace memmove/memcpy with slice assignment
> 11) using an floating point or char variable that has been initialized (I know D initializes all variables but the initial values for some types are chosen to usually force programmers to initialize variables) 
> 
> 

and some more:
12) detect unused parameters/methods/members/labels/code blocks
13) suggest the use of "with" statement when applicable
14) list classes with high cyclomatic complexity measurements
15) list classes with getters/setters only
16) rant on use of uninstantiated objects
17) highlight ill-named identifiers
...
wait a sec.  is there anyone passionate enough to launch the dlint project?

In article <cu4c88$ecu$1@digitaldaemon.com>, Walter says...
>The original idea behind -release was to not require the DMD programmer to learn a bunch of arcane weird switches (look at any C++ compiler!), there'd be a switch that would make it "just work".
>
>Looks like I failed :-(

I would say, -release is more intutive and self-explainatory, its just a matter of documentation to specify what -release does.

or

have multiple switches -nocontracts, -noarrayboundchecks etc etc ...... and specify in documentation that -release is shortcut to all above switches.

Sai

"Walter" <newshound@digitalmars.com> wrote in message news:cu4c88$ecu$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu45td$89b$1@digitaldaemon.com...
>> Cool. Sounds like the _only_ thing to do is rename the misnomer "-release" to "-nocontracts". Can we have that, and forestall all the wasted mental cycles for people who have to learn what it really means?
>
> The original idea behind -release was to not require the DMD programmer to
> learn a bunch of arcane weird switches (look at any C++ compiler!),
> there'd
> be a switch that would make it "just work".
>
> Looks like I failed :-(
>

I don't think you failed - actually I think the original plan and how it's implemented makes a lot of sense, with perhaps one exception on the implementation.. If this issue:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15834

is addressed (basically, so a call to check for invariants at run-time is done /only/ if there is an invariant defined or inherited for a class), then I think PwC can be divorced from the -release switch altogether.

What that would mean for developers is that 1) they could always have PwC without paying for it where it isn't used, 2) there would be no new switches and 3) they would have to change asserts to throws, i.e.:

import std.stream;

class X
{
    int i,j;
    this(int iVal, int jVal) { i = iVal; j = jVal; }
    // code that also manipulates i and j here
    invariant
    {
//      assert(i >= 6 && i <= 10);
        if(i < 6 || i > 10)
            throw new Exception("Class X value i is out of range");
//      assert(i >= 20 && i <= 100);
        if(j < 20 || j > 100)
            throw new Exception("Class X value j is out of range");
    }
}

void main()
{
    X x;
    int iVal = 0, jVal = 0;
//  simulate a confused user picking the values
    iVal = 6; jVal = 102;
    while(!foo(x,iVal,jVal))
    {
        if(!(jVal % 2)) iVal--;
        else iVal++;
        jVal--;
    }
//  ...
    if(x) stdout.writefln("x.i,j = %d,%d",x.i,x.j);
}

bool foo(out X x, int iVal, int jVal)
{
    try {
        x = new X(iVal,jVal);
        return true;
    } catch(Exception e) {
        stdout.writefln("%s",e);
        delete x;
        return false;
    }
}

which will probably work out to be a good thing because the error messages displayed to users can be better than the asserts, plus the developer can use invariant blocks to roll up common exceptions for a class into one place if they so desire.

What that would mean for /users/ is that 1) they could always have PwC without paying for it where it isn't used, 2) Developers would be encouraged to use catchable exceptions in PwC that would make more sense than cryptic asserts and allow for better exception recovery.

This could move PwC into being something that commonly makes it into production code instead of stopping at the release build.

I think that could be a great thing to move the whole concept of language formalized PwC forward.

- Dave