We're very far from experiencing any speed problems at compilation.

These checks simply don't need any significant time.

Juan C. wrote:
> A file doesn't need to be checked for rookie mistakes every time it's compiled,
> only when it's changed. If we write and check a file and then put it into a code
> library, why check it again when it's pulled out for inclusion in a new project?

When you compile the library, you need to place the source into src. And then incude the binary when linking. However, the source is generally unused when compiling other modules, only declarations are extracted, the code itself is added by the linker. For efficiency reasons, source code can be taken for inlining from src, but nontheless no warnings about the code should be output. BTW, you can compile a library from source, then install "headers" stripped of function bodies into src. This also works.

> If D is to be for beginners, then OK, put training wheels on it. But if it's to
> be for experienced power programmers who write expressively and perhaps
> obfuscatedly (?), then trust us to know what we're doing!

D should definately be good for beginners. Professionals have C++: a language which is somewhat complicated but fascinating and wonderful as you start to get it. But one which calls for trouble if you just begin to learn it.

Obfuscated code is to be more or less forbidden in D. Look at Walter's code, it's very clean. It looks more or less like code a Delphi programmer would write. :)

> Or maybe add an /expert or /fast switch to the command line, or have /release
> not check such things?

You know that Walter is strongly against such things. Compiler switches should not change the sematics of the language, else we shall have portability problems among build environments.

Anyway, who cares how long release compiles take? And by the way, the back-end takes itself quite some time when you want to compile with optimisations.

-eye

PS. Walter, wouldn't you call this if(x=y) check a "nag"? No, i'm not against it, but i was questioning consistency.

I think that you are missing one of the central tenets of Walter's design of D.  Quoted from http://digitalmars.com/d/overview.html, the First Major Goal of D is:

<quote>
Reduce software development costs by at least 10% by adding in proven productivity enhancing features and by adjusting language features so that common, time-consuming bugs are eliminated from the start.
</quote>

So, as I have seen over and over, Walter's intention is to design a language which makes it easy to do the Right Thing and hard(er) to do the Wrong Thing.  He has made the language very C-like so that it is easy to port, but intentionally breaks things that he believes led to lots of bugs in C.

In this discussion, we have seen a wide variety of opinions about what the Right Thing is; thus, we have had a lot of debate.  I think it's fair to discuss with Walter about what the Right Thing is, but I don't think it's fair to call him inconsistent.  C compatibility was never a stated goal.

Hang in there, Walter!  The current storm will subside.

Russ

The Lone Haranguer wrote:
> C has an implicit default:break; ?
> 
> Regardless, as I don't like your built-in assert(), I certainly don't want the
> compiler to add one.
> 
> Why do you insist on not breaking ported C code in some cases, while going out
> of your way to break it in other cases? Make up your mind!
> 
> In article <br3sjr$1ajv$2@digitaldaemon.com>, Walter says...
> 
>>
>>"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message
>>news:bqjr7a$197c$1@digitaldaemon.com...
>>
>>>Ok, I can (hopefully) see where you're not understanding our argument.
>>>AFAICT no-one's arguing for a C status-quo, which is what all your
>>
>>arguments
>>
>>>seem to be addressing.
>>
>>So, we all agree that C's implicit default:break; is not what we want? (This
>>may cause some C code ported to D to have problems crop up. I think this is
>>bearable, I just want to make sure it is known.)
>>
>>Does this also mean we agree that throwing a runtime exception on the
>>default is not a bad thing if it is intended that cases cover all the bases?
>>
>>
>>>Put in its simplest form: we want the compiler to
>>>force us to write a default, *in all cases*.
>>
>>If this is our only point of disagreement on this, I don't think it's worthy
>>of all the heat!
>>
>>
>>>My previous suggestion was to
>>>enable the syntactic sugar of substituting "unexpected:" for "default:
>>>assert(0);". (Note that "unexpected:" would throw something a little more
>>>informative than assert(0), perhaps an UnexpectedCaseException?)
>>
>>Actually, it throws a SwitchError exception, giving file name and line
>>number.
>>
>>
> 
> 
> 

In a recent post Walter wrote:
> 
> While I generally agree with you here, the point I make is that the language should make the right thing to do the easiest thing to do.
> 
In another recent post Walter wrote:
> 
> Mine too, but I like to put in a default:break; to signal to anyone reading the code that I didn't just overlook the other cases!

These statements combined would seem to vote for an obligatory explicit default in switch statements?

I think most of the time people don't put a default in their switch 'cause they forgot. The compiler could "remind" them.

If one is stupid enough to put a default:break when they shouldn't, then it's their own fault. But most people would just remember that this was what they forgot, no biggie.

Incidentally, I was one who got derailed with the assert(0) thing. That sounded really unfriendly. Throwing a proper error is much better, although I still vote for an obligatory and explicit default.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:br7rue$1gaa$2@digitaldaemon.com...
> Hang in there, Walter!  The current storm will subside.

Thanks! At the end of the day, I just have to make a decision and stick with it, or D will never move forward.

Well, based on both those arguments, fall-through should be abandoned. I understood fall-through was left in for C compatibility, and it leads to many bugs.

In article <br7rue$1gaa$2@digitaldaemon.com>, Russ Lewis says...
>
>I think that you are missing one of the central tenets of Walter's design of D.  Quoted from http://digitalmars.com/d/overview.html, the First Major Goal of D is:
>
><quote>
>Reduce software development costs by at least 10% by adding in proven
>productivity enhancing features and by adjusting language features so
>that common, time-consuming bugs are eliminated from the start.
></quote>
>
>So, as I have seen over and over, Walter's intention is to design a language which makes it easy to do the Right Thing and hard(er) to do the Wrong Thing.  He has made the language very C-like so that it is easy to port, but intentionally breaks things that he believes led to lots of bugs in C.
>
>In this discussion, we have seen a wide variety of opinions about what the Right Thing is; thus, we have had a lot of debate.  I think it's fair to discuss with Walter about what the Right Thing is, but I don't think it's fair to call him inconsistent.  C compatibility was never a stated goal.
>
>Hang in there, Walter!  The current storm will subside.
>
>Russ
>

I think perhaps this could be used as an argument for strongly-typed booleans
too.
The C practice of:
int x = something ;
if ( x ) ... ;
or worse:
char* s = something ;
if ( s ) ... ;
is at least poor style, and can lead to higher maintenance time and cost (due to
maintenance being done by programmers less-experienced than the original
programmers (who didn't write any comments because they feel that the code is
the documentation)).

<On my last job I had to deal with a lot of the latter example and always replaced them with  if ( s != NULL ) ... ; >

So, although it may not lead to bugs, it's the "Wrong Thing". And strongly-typed booleans should be the fix.

And it seems the only reason to continue to allow it is because of portability with C.

And furthermore, as mentioned before, strongly-typed booleans also solve the problem of when someone writes  if ( x = y ) ... ;  accidently. (Unless x and y are boolean, but how often would you do that?)

Oh, sheesh, I'm still writing? Well let me get it over with here and not have to
write another message.
As mentioned before, yet another solution to the "assign instead of equality"
mistake is to have a different assignment operator, e.g. := . At one point
Walter said that makes sense. Again, it seems that the only reason to keep the
"C assignment operator" is for portability!


In article <br7rue$1gaa$2@digitaldaemon.com>, Russ Lewis says...
>
>I think that you are missing one of the central tenets of Walter's design of D.  Quoted from http://digitalmars.com/d/overview.html, the First Major Goal of D is:
>
><quote>
>Reduce software development costs by at least 10% by adding in proven
>productivity enhancing features and by adjusting language features so
>that common, time-consuming bugs are eliminated from the start.
></quote>
>
>So, as I have seen over and over, Walter's intention is to design a language which makes it easy to do the Right Thing and hard(er) to do the Wrong Thing.  He has made the language very C-like so that it is easy to port, but intentionally breaks things that he believes led to lots of bugs in C.
>
>In this discussion, we have seen a wide variety of opinions about what the Right Thing is; thus, we have had a lot of debate.  I think it's fair to discuss with Walter about what the Right Thing is, but I don't think it's fair to call him inconsistent.  C compatibility was never a stated goal.
>
>Hang in there, Walter!  The current storm will subside.
>
>Russ

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:br72i4$9f2$1@digitaldaemon.com...
> Shouldn't the cast line had a runtime check? Just asking.

I could argue it both ways <g>.

Walter <walter@digitalmars.com> escribió en el mensaje de noticias brtenf$1uqp$1@digitaldaemon.com...
>
> "Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:br72i4$9f2$1@digitaldaemon.com...
> > Shouldn't the cast line had a runtime check? Just asking.
>
> I could argue it both ways <g>.

At least in debug builds, please! (Just like array bounds checking)

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:brtn8a$2blv$1@digitaldaemon.com...
>
>
>
> Walter <walter@digitalmars.com> escribió en el mensaje de noticias brtenf$1uqp$1@digitaldaemon.com...
> >
> > "Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:br72i4$9f2$1@digitaldaemon.com...
> > > Shouldn't the cast line had a runtime check? Just asking.
> >
> > I could argue it both ways <g>.
>
> At least in debug builds, please! (Just like array bounds checking)

It's a good idea, but I have to redo the template stuff first.

Shall we reopen the discussion, or do you already know what you are going to do?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:brv8kk$1ldt$1@digitaldaemon.com...
> It's a good idea, but I have to redo the template stuff first.