www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D - Looks great! Open to changes still?

reply Munch <Munch_member pathlink.com> writes:
Hi,

First off thanks so much all of you guys, and especially Walter, for working on
what looks like a fantastic new language. My reaction and those of the
colleagues I've mailed about it has bascially been "this is what we've been
wanting for years". I love the way you've taken great ideas from all over the
place and added a few new ones of your own.

Is the language fairly fixed now, or are you still open to ideas? There are a
couple of robustness suggestions I had that would find more bugs at compile time
in a way that would be familiar to your hardened C/C++ programmer target
audience.

Thanks again

Munch
Nov 17 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
If you have a suggestion to make the language better, don't be afraid to 
say it. As of yet D is still a work in progress.

Munch wrote:

 Hi,
 
 First off thanks so much all of you guys, and especially Walter, for working on
 what looks like a fantastic new language. My reaction and those of the
 colleagues I've mailed about it has bascially been "this is what we've been
 wanting for years". I love the way you've taken great ideas from all over the
 place and added a few new ones of your own.
 
 Is the language fairly fixed now, or are you still open to ideas? There are a
 couple of robustness suggestions I had that would find more bugs at compile
time
 in a way that would be familiar to your hardened C/C++ programmer target
 audience.
 
 Thanks again
 
 Munch
Nov 17 2005
next sibling parent reply Munch <Munch_member pathlink.com> writes:
OK so here is my other suggestion. It's very simple to implement from a compiler
perspective - it adds robustness - it just needs a slight rearangement of the
sytnax. I found a thread on it in the archives here:
http://www.digitalmars.com/d/archives/1418.html

Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:

while (i < 9)
i++; j++;

or this

if (cond)
<debug statement added to find bug>;
<line of code intended to be conditional>;

or more generally

if (cond)
<added code here>;
<ORIGINAL conditional line of code>; <and/or more added code>;
<and/or more added code>;

This is one of those things that when you start out coding you kid yourself that
you save time by skipping out the braces. As the years roll by you gradually
come across bugs that are harder and harder to find, that had part of their
cause in missing curlys. Sooner or later you learn to use braces everywhere. I
occasionally do code reviews and whenever I've come across code which doesn't
have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
This is easy to fix in the language syntax, thus:

IfStatement:
if ( Expression ) BlockStatement
if ( Expression ) BlockStatement else BlockStatement
if ( Expression ) BlockStatement else IfStatement

Not enough motivation yet? Finally, this also kills one of the most insidious
bugs in C/C++/Java:

if (cond);
<code intended to be conditional>

I've only done this a few times in my programming life, mainly in the first few
years, but boy did some of those bugs take a long time to find. Note that this
one can't be fixed by voluntarily entering braces yourself:

if (cond);
{
<code intended to be conditional>
}

The above syntax however, makes this a compile time error =)

(Obviously the above also applies to "for", "while" etc. )

Regards

Munch
Nov 17 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
 
 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement
 


I'm all for this.  I almost always go ahead and use the braces anyway, because
seemingly 
invariably if I leave them out, then I end up adding them later anyhow so I can
insert 
some debugging code.  D wouldn't be the first language to make them mandatory,
really.

-- Chris Sauls
Nov 17 2005
parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:dlj8hv$2s2n$1 digitaldaemon.com...

 Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a 
 compiler
 perspective - it adds robustness - it just needs a slight rearangement of 
 the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html

 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like 
 this:

 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement


 I'm all for this.  I almost always go ahead and use the braces anyway, 
 because seemingly invariably if I leave them out, then I end up adding 
 them later anyhow so I can insert some debugging code.  D wouldn't be the 
 first language to make them mandatory, really.


I agree  entirely.  It's been my experience where  I'll insert a nifty 
little no-brace if statement, then have to debug that line; I put in a 
writefln call, and find out my wonderful no-brace trick doesn't work in this 
case, and I have to put in braces.


 -- Chris Sauls
Nov 17 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 18 Nov 2005 00:32:54 +0000 (UTC), Munch wrote:


 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:


No argument from me. I'm constantly adding in braces anyway.


 Not enough motivation yet? Finally, this also kills one of the most insidious
 bugs in C/C++/Java:
 
 if (cond);
 <code intended to be conditional>


The DMD compiler already catches this one. If you try it you get this
message ...

   use '{ }' for an empty statement, not a ';'

It is not well documented and it might not even be a part of the D-Language
(as opposed to a compiler implementation). There is a small comment in the
'for' statement documentation that says ...

   Function bodies cannot be empty: 

     for (int i = 0; i < 10; i++)
        ; // illegal

   Use instead: 

     for (int i = 0; i < 10; i++)
     {
     }

But it seems to apply to other statements as well.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/11/2005 12:07:43 PM
Nov 17 2005
parent Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
Derek Parnell wrote:

Not enough motivation yet? Finally, this also kills one of the most insidious
bugs in C/C++/Java:

if (cond);
<code intended to be conditional>


 
 
 The DMD compiler already catches this one. If you try it you get this
 message ...
 
    use '{ }' for an empty statement, not a ';'
 
 It is not well documented and it might not even be a part of the D-Language
 (as opposed to a compiler implementation). There is a small comment in the
 'for' statement documentation that says ...
 
    Function bodies cannot be empty: 
 
      for (int i = 0; i < 10; i++)
         ; // illegal
 
    Use instead: 
 
      for (int i = 0; i < 10; i++)
      {
      }
 
 But it seems to apply to other statements as well.
 


Great - thanks =) That's good news, but like you say it would be nice to 
have braces forced anyway.

Munch
Nov 18 2005
prev sibling next sibling parent reply JT <JT_member pathlink.com> writes:
In article <dlj7fm$2rk9$1 digitaldaemon.com>, Munch says...

OK so here is my other suggestion. It's very simple to implement from a compiler
perspective - it adds robustness - it just needs a slight rearangement of the
sytnax. I found a thread on it in the archives here:
http://www.digitalmars.com/d/archives/1418.html

Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:

while (i < 9)
i++; j++;

or this

if (cond)
<debug statement added to find bug>;
<line of code intended to be conditional>;

or more generally

if (cond)
<added code here>;
<ORIGINAL conditional line of code>; <and/or more added code>;
<and/or more added code>;

This is one of those things that when you start out coding you kid yourself that
you save time by skipping out the braces. As the years roll by you gradually
come across bugs that are harder and harder to find, that had part of their
cause in missing curlys. Sooner or later you learn to use braces everywhere. I
occasionally do code reviews and whenever I've come across code which doesn't
have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
This is easy to fix in the language syntax, thus:

IfStatement:
if ( Expression ) BlockStatement
if ( Expression ) BlockStatement else BlockStatement
if ( Expression ) BlockStatement else IfStatement

Not enough motivation yet? Finally, this also kills one of the most insidious
bugs in C/C++/Java:

if (cond);
<code intended to be conditional>

I've only done this a few times in my programming life, mainly in the first few
years, but boy did some of those bugs take a long time to find. Note that this
one can't be fixed by voluntarily entering braces yourself:

if (cond);
{
<code intended to be conditional>
}

The above syntax however, makes this a compile time error =)

(Obviously the above also applies to "for", "while" etc. )

Regards

Munch



I completely disagree. I enjoy the flexibility and I dont believe it should be
limited just because someone, somewhere, might screw up. I would suggest using
some sort of D lint application, such as a modified front end that would catch
something like that, it would be fairly easy to do.
Nov 17 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 18 Nov 2005 01:26:24 +0000 (UTC), JT <JT_member pathlink.com>  
wrote:

 In article <dlj7fm$2rk9$1 digitaldaemon.com>, Munch says...

 OK so here is my other suggestion. It's very simple to implement from a  
 compiler
 perspective - it adds robustness - it just needs a slight rearangement  
 of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html

 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like  
 this:

 while (i < 9)
 i++; j++;

 or this

 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;

 or more generally

 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;

 This is one of those things that when you start out coding you kid  
 yourself that
 you save time by skipping out the braces. As the years roll by you  
 gradually
 come across bugs that are harder and harder to find, that had part of  
 their
 cause in missing curlys. Sooner or later you learn to use braces  
 everywhere. I
 occasionally do code reviews and whenever I've come across code which  
 doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in  
 the code.
 This is easy to fix in the language syntax, thus:

 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement

 Not enough motivation yet? Finally, this also kills one of the most  
 insidious
 bugs in C/C++/Java:

 if (cond);
 <code intended to be conditional>

 I've only done this a few times in my programming life, mainly in the  
 first few
 years, but boy did some of those bugs take a long time to find. Note  
 that this
 one can't be fixed by voluntarily entering braces yourself:

 if (cond);
 {
 <code intended to be conditional>
 }

 The above syntax however, makes this a compile time error =)

 (Obviously the above also applies to "for", "while" etc. )

 Regards

 Munch



 I completely disagree. I enjoy the flexibility and I dont believe it  
 should be
 limited just because someone, somewhere, might screw up. I would suggest  
 using
 some sort of D lint application, such as a modified front end that would  
 catch
 something like that, it would be fairly easy to do.


I'm with JT. D isn't supposed to to enforce one code style over another,  
though you could argue it already does this to a limited degree.

The D compiler front end source is open source (or similarly licensed)  
such that writing a lint checking tool should be fairly easy. Ben Hinkle  
even simplified the process some, search for "dmdfe" in these newsgroups  
if you're interested.

Regan
Nov 17 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 18 Nov 2005 01:26:24 +0000 (UTC), JT wrote:



 I completely disagree. I enjoy the flexibility and I dont believe it should be
 limited just because someone, somewhere, might screw up. 


You, of course, have every right to that opinion. Just as I have to mine,
and that is that I do *not* enjoy maintaining code written with these sort
of embedded 'mine fields'. The 'goto' is another similar problem however
there are extenuating circumstances for its occasional usage, but what
benefit is there to an application by omitting braces?

In general, coding practices that increase the probability of mistakes
should only be allowed when there is a demonstrable benefit, on a per
instance basis, to the application over its lifetime. Failing that, the
language should actively discourage such practices. 


 I would suggest using
 some sort of D lint application, such as a modified front end that would catch
 something like that, it would be fairly easy to do.


Yes, we need more band-aids. ;-)

I would argue the opposite. If a coder wishes to enjoy the flexibility of
omitting braces then a compiler option should be given to allow that
practice. Either a command-line switch or (even better) a pragma in the
source code. In other words, the cost of making mistakes easier to create
should be born by the coder.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/11/2005 1:15:17 PM
Nov 17 2005
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 I completely disagree. I enjoy the flexibility and I dont believe it should be
 limited just because someone, somewhere, might screw up. I would suggest using
 some sort of D lint application, such as a modified front end that would catch
 something like that, it would be fairly easy to do.


i will never understand why people allways fight for their right to make 
coding errors which can be handle totaly by an good snytax (or paradigm) 
change.

and i still don't understand why people use arguments like

"this could handle a tool" - what codeing-help-tool have ever worked in 
the right (and standartrized) way for us?

"programmers should/could do it the right way" - mistakes are mostly 
made under bad conditions like stress or something

or "i never had this problem" ;-]


just a tip:

though of an

   big-1-to-x-Mio-lines,
   10-years-rotten,
   and 100-programmers with-different-experince,

sized project and you will understand why small changes can be gain an 
very huge benefit

ciao dennis
Nov 17 2005
parent reply JT <JT_member pathlink.com> writes:
In article <dlk018$hcv$1 digitaldaemon.com>, dennis luehring says...

 I completely disagree. I enjoy the flexibility and I dont believe it should be
 limited just because someone, somewhere, might screw up. I would suggest using
 some sort of D lint application, such as a modified front end that would catch
 something like that, it would be fairly easy to do.


i will never understand why people allways fight for their right to make 
coding errors which can be handle totaly by an good snytax (or paradigm) 
change.

and i still don't understand why people use arguments like

"this could handle a tool" - what codeing-help-tool have ever worked in 
the right (and standartrized) way for us?

"programmers should/could do it the right way" - mistakes are mostly 
made under bad conditions like stress or something

or "i never had this problem" ;-]


just a tip:

though of an

   big-1-to-x-Mio-lines,
   10-years-rotten,
   and 100-programmers with-different-experince,

sized project and you will understand why small changes can be gain an 
very huge benefit

ciao dennis


Its a fundamental issue that has nothing actually to do with coding. Some people
wish to force a style upon another group of people 'for their own good'

All I can say is I am delighted that Walter is the one making these kinds of
decisions :D
Nov 18 2005
next sibling parent Don Clugston <dac nospam.com.au> writes:
JT wrote:

 Its a fundamental issue that has nothing actually to do with coding. Some
people
 wish to force a style upon another group of people 'for their own good'
 
 All I can say is I am delighted that Walter is the one making these kinds of
 decisions :D


Personally, I use

if (cond) return val;

and

if (cond) break;

frequently. This has no risk of the coding error mentioned, and is much 
clearer than the brace alternative.

However, I agree that using an 'else' clause without braces between 'if' 
and 'else' is asking for trouble. Ditto for while and for. And 
definitely for do-while.

If you look in phobos you'll find plenty of examples of "if" statements 
with no braces. I think the request is in vain.
Nov 18 2005
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
 Its a fundamental issue that has nothing actually to do with coding. Some
people
 wish to force a style upon another group of people 'for their own good'


sorry i don't want to force - just push a little bit :-)


 All I can say is I am delighted that Walter is the one making these kinds of
 decisions :D


your right - walter will make the best possible decision (i hope)


ciao dennis
Nov 18 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Honestly, and I mean no disrespect, but I've never understood why people 
make such a big deal out of this one.

I personally value my vertical real estate when programming, and as I 
use so much for train-of-thought comments (unlike many programmers these 
days), I always leave the braces off for single statements.

Indeed, I've seen some who use:

if (condition) expression;

While that goes against my coding standards, and as such is something I 
never do, I don't think the people who prefer that style for short if 
conditionals would like the requirement of braces either.

I strictly follow coding standards, and although I have had problems 
with a semicolon at the end of my ifs, whiles, and fors... I have never 
(nor have any of the programmers under me ever) accidentally screwed up 
a conditional because it didn't have braces.

Don't get me wrong; I understand that if you were used to braces always 
being there, you might make the mistake.  We're all only human.  But... 
and again, with all due respect... it seems to me such a weird mistake 
to make.  If I ever employed a programmer who seriously had this 
problem, I would worry that requiring braces wouldn't help much.  But 
this is only me, and again I am not in any way judging you or anyone who 
does have the problem, just explaining my own worries.

That said, I personally would like a compiler that could (optionally, 
e.g. with a "plugin") check code against coding standards: no multiple 
statements on one line, no lack of spaces around operators, no braces on 
ifs and other conditionals.  But, there'd have to be a way to ensure 
that only developers use these conditions; not people compiling code for 
their system.

-[Unknown]



 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
 
 while (i < 9)
 i++; j++;
 
 or this
 
 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;
 
 or more generally
 
 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;
 
 This is one of those things that when you start out coding you kid yourself
that
 you save time by skipping out the braces. As the years roll by you gradually
 come across bugs that are harder and harder to find, that had part of their
 cause in missing curlys. Sooner or later you learn to use braces everywhere. I
 occasionally do code reviews and whenever I've come across code which doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
 This is easy to fix in the language syntax, thus:
 
 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement
 
 Not enough motivation yet? Finally, this also kills one of the most insidious
 bugs in C/C++/Java:
 
 if (cond);
 <code intended to be conditional>
 
 I've only done this a few times in my programming life, mainly in the first few
 years, but boy did some of those bugs take a long time to find. Note that this
 one can't be fixed by voluntarily entering braces yourself:
 
 if (cond);
 {
 <code intended to be conditional>
 }
 
 The above syntax however, makes this a compile time error =)
 
 (Obviously the above also applies to "for", "while" etc. )
 
 Regards
 
 Munch
Nov 17 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 17 Nov 2005 21:55:56 -0800, Unknown W. Brackets  
<unknown simplemachines.org> wrote:

 That said, I personally would like a compiler that could (optionally,  
 e.g. with a "plugin") check code against coding standards: no multiple  
 statements on one line, no lack of spaces around operators, no braces on  
 ifs and other conditionals.  But, there'd have to be a way to ensure  
 that only developers use these conditions; not people compiling code for  
 their system.


I think this is a great idea "Optional pluggable compiler modules".

Regan
Nov 17 2005
prev sibling next sibling parent reply Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
Unknown W. Brackets wrote:

 Don't get me wrong; I understand that if you were used to braces always 
 being there, you might make the mistake.  We're all only human.  But... 
 and again, with all due respect... it seems to me such a weird mistake 
 to make.


Actually in my experience this mistake is more often made by newer 
programmers who haven't got used to using brackets yet. Since I work 
with a wide range of programmers, from "just graduated" to 35 years on 
the job, if we're going to move our teams over to using D in the future 
(and I'd like us to) I'm looking for a language that is suitable for all 
  programmers. As an aside though, like you say, we are all human. When 
it's late and you're tired and haven't eaten and the deadlines looming 
and you also know your family is wanting you home etc. etc. it's very 
easy to add a line of debug and forget to add the braces. It's not so 
much about the kind of mistake - sure it's fairly rare - but given the 
ease of fixing it -why not?

I can appreciate the "vertical real estate" argument, but in that case
how about:

    if (cond) {
       blah; }

Or even:

    if (cond) { blah; }

I hear Bruno's point about auto indent, and the lint ideas, compiler 
warning flags etc. but surely the whole spirit of D is to include this 
stuff _in_the_language_ otherwise people end up not using it.

Cheers

Munch
Nov 18 2005
next sibling parent reply JT <JT_member pathlink.com> writes:
In article <dlkk2p$15cr$1 digitaldaemon.com>, Munchgreeble says...

Unknown W. Brackets wrote:

 Don't get me wrong; I understand that if you were used to braces always 
 being there, you might make the mistake.  We're all only human.  But... 
 and again, with all due respect... it seems to me such a weird mistake 
 to make.


Actually in my experience this mistake is more often made by newer 
programmers who haven't got used to using brackets yet. Since I work 
with a wide range of programmers, from "just graduated" to 35 years on 
the job, if we're going to move our teams over to using D in the future 
(and I'd like us to) I'm looking for a language that is suitable for all 
  programmers. As an aside though, like you say, we are all human. When 
it's late and you're tired and haven't eaten and the deadlines looming 
and you also know your family is wanting you home etc. etc. it's very 
easy to add a line of debug and forget to add the braces. It's not so 
much about the kind of mistake - sure it's fairly rare - but given the 
ease of fixing it -why not?

I can appreciate the "vertical real estate" argument, but in that case
how about:

    if (cond) {
       blah; }

Or even:

    if (cond) { blah; }

I hear Bruno's point about auto indent, and the lint ideas, compiler 
warning flags etc. but surely the whole spirit of D is to include this 
stuff _in_the_language_ otherwise people end up not using it.

Cheers

Munch



but heres the thing.... a lot of people simply DONT NEED IT. In fact I cant
believe anyone actually wants this.

and im sorry but this is ugly:

    if (cond) {
       blah; }



I mean come on, this is like those people who want to put breathalizer
interlocks on all cars because some people drive drunk. is the world going mad?
Nov 18 2005
parent reply JT <JT_member pathlink.com> writes:
In article <dlkl1b$16c6$1 digitaldaemon.com>, JT says...

In article <dlkk2p$15cr$1 digitaldaemon.com>, Munchgreeble says...

Unknown W. Brackets wrote:

 Don't get me wrong; I understand that if you were used to braces always 
 being there, you might make the mistake.  We're all only human.  But... 
 and again, with all due respect... it seems to me such a weird mistake 
 to make.


Actually in my experience this mistake is more often made by newer 
programmers who haven't got used to using brackets yet. Since I work 
with a wide range of programmers, from "just graduated" to 35 years on 
the job, if we're going to move our teams over to using D in the future 
(and I'd like us to) I'm looking for a language that is suitable for all 
  programmers. As an aside though, like you say, we are all human. When 
it's late and you're tired and haven't eaten and the deadlines looming 
and you also know your family is wanting you home etc. etc. it's very 
easy to add a line of debug and forget to add the braces. It's not so 
much about the kind of mistake - sure it's fairly rare - but given the 
ease of fixing it -why not?

I can appreciate the "vertical real estate" argument, but in that case
how about:

    if (cond) {
       blah; }

Or even:

    if (cond) { blah; }

I hear Bruno's point about auto indent, and the lint ideas, compiler 
warning flags etc. but surely the whole spirit of D is to include this 
stuff _in_the_language_ otherwise people end up not using it.

Cheers

Munch



but heres the thing.... a lot of people simply DONT NEED IT. In fact I cant
believe anyone actually wants this.

and im sorry but this is ugly:

    if (cond) {
       blah; }



I mean come on, this is like those people who want to put breathalizer
interlocks on all cars because some people drive drunk. is the world going mad?


Sorry I didnt mean to be rude or anything, and I can understand why some people
would find this usefull. I simply cannot understand wanting to impose this on
everyone, because, to me, its actually a style issue more than anything....
Nov 18 2005
parent reply Munch <Munch_member pathlink.com> writes:
In article <dlkmou$1882$1 digitaldaemon.com>, JT says...


Sorry I didnt mean to be rude or anything, and I can understand why some people
would find this usefull. I simply cannot understand wanting to impose this on
everyone, because, to me, its actually a style issue more than anything.... 


Don't worry, no offense taken =) I can understand that you can't understand it,
but that doesn't mean it's not a good idea of course, it probably just means we
have different experience of coding.

I guess a lot of this comes down to the kind of software you write. I'm used to
working in teams - each new project I work on I'll be working with at least some
people who I've never worked with before. Some projects, I'm so removed from the
coding team that I hardly actually get to see the source code, othertimes I'm in
there coding with everybody else. It makes a big difference if a language has
something built in - which is one of the reasons I'm so keen on D. Loads of the
good stuff I try to encourage - fully fledged use of contracts (never managed
it), basic asserts, unit tests automatically run as part of the build process
(just managed it for the first time on my current project) etc. is part of the
language in D. The bracketing issue is another such thing.

I can understand that if for example somebody spends most of their time working
on code that they've written themselves, this kind of thing won't bother them
too much. Working on large code bases and/or in teams you come across a huge
variety of bugs - the worst ones always have multiple causes. Any cause that we
can rule out as part of the language has got to be a good thing.

To take a meta view on this problem, what you have here are two groups of
people: one whose experience identifies a problem that can easily be fixed,
another whose experience hasn't found this to be a problem.

The population of D users is made up of these two groups. The population can
also be split into people who think that the overhead of having to use braces is
a bad thing and those who don't.

What we need to weigh up is how much the population as a whole would be affected
1. by lack of brace enforcement and 2. by brace enforcement.

In my experience (which I'll admit is not the same as everybody elses), people
who wish to have the option of no braces are never that bothered about giving up
that option once they start doing it, but extra bugs bother everybody.

To summarise my argument:
- One of D's main strands is robustness (great - gets my vote)
- One of D's main principals is including features in the core language (great -
gets my vote)
- Another of D's main principals is to keep the compiler in mind (great - gets
my vote)
- This suggestion fits in with all three of these goals, and doesn't conflict
with any of D's aims.
- Some people can see the benefit of this, others not, but just because you
personally have no experience of this being a problem, doesn't mean it isn't.
- We need the language to be the best fit for the population as a whole, not any
particular subgroup. Assuming the target population is identified by the
language aims/goals as expressed above then it is logical to include this
change.

I will try not to add any more to this - these arguments do tend to ramble on!
It would be nice if somebody neutral could summarise the two sides of the
argument as I have probably been biased by my own experience. Perhaps the
anti-brace-enforcement guys could summarise their position and we coudl cut and
paste the two summaries? I was thinking it's worth putting this in the Wiki:
(http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same ground
being covered over and over.

Cheers

Munch
Nov 18 2005
next sibling parent reply JT <JT_member pathlink.com> writes:
In article <dllivh$21r4$1 digitaldaemon.com>, Munch says...

In article <dlkmou$1882$1 digitaldaemon.com>, JT says...


Sorry I didnt mean to be rude or anything, and I can understand why some people
would find this usefull. I simply cannot understand wanting to impose this on
everyone, because, to me, its actually a style issue more than anything.... 


Don't worry, no offense taken =) I can understand that you can't understand it,
but that doesn't mean it's not a good idea of course, it probably just means we
have different experience of coding.

I guess a lot of this comes down to the kind of software you write. I'm used to
working in teams - each new project I work on I'll be working with at least some
people who I've never worked with before. Some projects, I'm so removed from the
coding team that I hardly actually get to see the source code, othertimes I'm in
there coding with everybody else. It makes a big difference if a language has
something built in - which is one of the reasons I'm so keen on D. Loads of the
good stuff I try to encourage - fully fledged use of contracts (never managed
it), basic asserts, unit tests automatically run as part of the build process
(just managed it for the first time on my current project) etc. is part of the
language in D. The bracketing issue is another such thing.

I can understand that if for example somebody spends most of their time working
on code that they've written themselves, this kind of thing won't bother them
too much. Working on large code bases and/or in teams you come across a huge
variety of bugs - the worst ones always have multiple causes. Any cause that we
can rule out as part of the language has got to be a good thing.

To take a meta view on this problem, what you have here are two groups of
people: one whose experience identifies a problem that can easily be fixed,
another whose experience hasn't found this to be a problem.

The population of D users is made up of these two groups. The population can
also be split into people who think that the overhead of having to use braces is
a bad thing and those who don't.

What we need to weigh up is how much the population as a whole would be affected
1. by lack of brace enforcement and 2. by brace enforcement.

In my experience (which I'll admit is not the same as everybody elses), people
who wish to have the option of no braces are never that bothered about giving up
that option once they start doing it, but extra bugs bother everybody.

To summarise my argument:
- One of D's main strands is robustness (great - gets my vote)
- One of D's main principals is including features in the core language (great -
gets my vote)
- Another of D's main principals is to keep the compiler in mind (great - gets
my vote)
- This suggestion fits in with all three of these goals, and doesn't conflict
with any of D's aims.
- Some people can see the benefit of this, others not, but just because you
personally have no experience of this being a problem, doesn't mean it isn't.
- We need the language to be the best fit for the population as a whole, not any
particular subgroup. Assuming the target population is identified by the
language aims/goals as expressed above then it is logical to include this
change.

I will try not to add any more to this - these arguments do tend to ramble on!
It would be nice if somebody neutral could summarise the two sides of the
argument as I have probably been biased by my own experience. Perhaps the
anti-brace-enforcement guys could summarise their position and we coudl cut and
paste the two summaries? I was thinking it's worth putting this in the Wiki:
(http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same ground
being covered over and over.

Cheers

Munch


I cant believe you actually felt the need to spoon feed us all of that. I know
exactly why you want it, just because I dont find the need to have the compiler
hold my hand doesnt mean I lack the experience to comprehend this oh so complex
issue. I have encountered that before, then I learned, now I dont have those
problems. Personally, I find it almost insulting that you would even suggest
forcing this upon people. But I guess thats me.....
Nov 18 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 18 Nov 2005 22:16:29 +0000 (UTC), JT wrote:


 Personally, I find it almost insulting that you would even suggest
 forcing this upon people. But I guess thats me.....


Hang on ... The language already 'forces' a whole lot of stuff on us. 

For example, if I'm coding a function that has no return value, why am I
forced to write 'void' as the return type? If I have an empty /while/
block, why am I forced to write '{};' instead of just ';'? There are plenty
of other examples too. 

The omission of braces is certain statements is just another situation in
which the language designer could have 'forced' a syntax requirement. The
fact that it doesn't is most likely so that people can copy code from C/C++
without having to 'convert' it to D.

-- 
Derek Parnell
Melbourne, Australia
19/11/2005 9:23:35 AM
Nov 18 2005
next sibling parent "Kris" <fu bar.com> writes:
"Derek Parnell" <derek psych.ward> wrote ...

 On Fri, 18 Nov 2005 22:16:29 +0000 (UTC), JT wrote:


 Personally, I find it almost insulting that you would even suggest
 forcing this upon people. But I guess thats me.....


 Hang on ... The language already 'forces' a whole lot of stuff on us.

 For example, if I'm coding a function that has no return value, why am I
 forced to write 'void' as the return type? If I have an empty /while/
 block, why am I forced to write '{};' instead of just ';'? There are 
 plenty
 of other examples too.



Yes: if you forget a return statement, you get a nasty runtime error!

I do wish that would throw an exception instead, with a file and line number 
:-(



 The omission of braces is certain statements is just another situation in
 which the language designer could have 'forced' a syntax requirement. The
 fact that it doesn't is most likely so that people can copy code from 
 C/C++
 without having to 'convert' it to D.


I think you nailed it.
Nov 18 2005
prev sibling parent reply Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <vu98s9vt79vw$.ey82ts0amb11.dlg 40tude.net>, Derek Parnell says...

The omission of braces is certain statements is just another situation in
which the language designer could have 'forced' a syntax requirement. The
fact that it doesn't is most likely so that people can copy code from C/C++
without having to 'convert' it to D.


Ah yes, now that's an interesting argument. But people aren't gonig to be able
to copy code without running it through a converter first are they? (e.g. due to
the new semantics of "int *i, j;", or const, or switch statements with fall
though clauses, or complicated pointer type declarations etc. to cite a few
examples that spring to mind). Therefore it's just an extra thing to add to the
converter.

In fact given that some of the changes have identical syntax but different
semantics, it would be very dangerous to promote direct copying from C. The
copier could easily end up with some compilable D code which had different
meaning to that intended in the orginal C. Far better then to have features in
the D syntax which allow the compiler to spot sections of copied C and alert the
coder to run them through a converter.

Oh my goodness it's 1 o'clock again.

How does this group suck the time away like that?

Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code
Must spend less time on D group and more time on code

=)
Nov 18 2005
parent reply "Kris" <fu bar.com> writes:
"Munchgreeble" <Munchgreeble_member pathlink.com> wrote in message


 Oh my goodness it's 1 o'clock again.

 How does this group suck the time away like that?


Because it's so much warmer near the computer!

Guessing you're somewhere near Scotland/Ireland/Wales/England ~ it's /cold/ 
there at this time of year.
Nov 18 2005
parent Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <dlluaa$2bev$1 digitaldaemon.com>, Kris says...

"Munchgreeble" <Munchgreeble_member pathlink.com> wrote in message


 Oh my goodness it's 1 o'clock again.

 How does this group suck the time away like that?


Because it's so much warmer near the computer!

Guessing you're somewhere near Scotland/Ireland/Wales/England ~ it's /cold/ 
there at this time of year. 


Yes UK =) And you're right it is cooold here this morning. I can't see the
garden out of the window because the window is covered in ice.
Nov 19 2005
prev sibling parent reply Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <dlljrs$22hs$1 digitaldaemon.com>, JT says...

I cant believe you actually felt the need to spoon feed us all of that. I know
exactly why you want it, just because I dont find the need to have the compiler
hold my hand doesnt mean I lack the experience to comprehend this oh so complex
issue. I have encountered that before, then I learned, now I dont have those
problems. Personally, I find it almost insulting that you would even suggest
forcing this upon people. But I guess thats me.....


Well I certainly agree that we've got a high calibre group here - which is nice!
I do apologise if you felt you were being spoon fed, I was merely aiming to be
clear in the presentation of my argument in order to give a useful final summary
of my thoughts.

Again I'm sorry you feel almost insulted at my suggestion, it's intended to help
people rather than restrict freedom. This kind of defensive reaction is reallyh
common though:

In the past I've been responsible for writing coding tips for project coding
teams (yes spoon feeding if you like). What I've found is that most people are
very resistant to the guidelines that I give when I first present them, and
become defensive even before they're presented.... but people come back to me
later (maybe years later) and say "wow you were so right about those coding
tips". The sad thing is that some people just stay defensive and cheat
themselves out of the benefit they could have had. If they find bugs in their
own code which could be avoided by these sorts of rules, they become resentful
and start to want to prove the guidlines wrong. It's seems really wierd to me -
but I'm no psychologist!

What concerns me here: there is a danger of people getting defensive and dug in
and denying a benefit _to_other_users_ as well as themselves. Perhaps this is
because they're not used to dealing with other people's code and so aren't aware
of the impact. If people are faced with debugging something which shows these
sorts of bugs up in _somebody_else's_ code, they tend to become convinced.
That's what I've found anyway =)

I think some people get defensive because they are insecure about their own
ability as a coder, and feel they can't admit that something like
consistently-using-braces will help them. Of course some people are genuinely
brilliant coders, never make any mistakes even when tired and under pressure.
Hopefully such people might have keen enough perception to see that we're not
all like that and perhaps be gracious enough to allow the rest of us mortals the
benefit of the help that they don't need?

Here's hoping =)

Munch
Nov 18 2005
parent reply J C Calvarese <technocrat7 gmail.com> writes:
In article <dllt4i$2akj$1 digitaldaemon.com>, Munchgreeble says...

I think some people get defensive because they are insecure about their own
ability as a coder, and feel they can't admit that something like
consistently-using-braces will help them. Of course some people are genuinely
brilliant coders, never make any mistakes even when tired and under pressure.
Hopefully such people might have keen enough perception to see that we're not
all like that and perhaps be gracious enough to allow the rest of us mortals the
benefit of the help that they don't need?


How long have you been reading this newsgroup? Have you been lurking at all or
have you actually just arrived?

I'm just suggesting that it's good to listen as well as speak. You've been doing
quite a bit of speaking. You might want to spend some time getting to know the
group dynamic -- before you manage to offend everyone. ;)

I'm not a professional programmer, but I write some code. And I can't remember
ever getting an error by leaving off braces on what I meant to be a block if
statement. I'm not saying it never happened. I've probably been stung by this,
too. I just remember other problems I've had a lot more clearly (such as
forgetting to put breaks in my switch cases). But I really doubt Walter would
change something like this at this point -- especially if it's going to require
him to add brackets all over Phobos sources. And Walter's the one who has to be
sold on it.

jcc7
Nov 18 2005
parent reply Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <dlm6a3$2hd0$1 digitaldaemon.com>, J C Calvarese says...

In article <dllt4i$2akj$1 digitaldaemon.com>, Munchgreeble says...

I think some people get defensive because they are insecure about their own
ability as a coder, and feel they can't admit that something like
consistently-using-braces will help them. Of course some people are genuinely
brilliant coders, never make any mistakes even when tired and under pressure.
Hopefully such people might have keen enough perception to see that we're not
all like that and perhaps be gracious enough to allow the rest of us mortals the
benefit of the help that they don't need?


How long have you been reading this newsgroup? Have you been lurking at all or
have you actually just arrived?

I'm just suggesting that it's good to listen as well as speak. You've been doing
quite a bit of speaking. You might want to spend some time getting to know the
group dynamic -- before you manage to offend everyone. ;)

I'm not a professional programmer, but I write some code. And I can't remember
ever getting an error by leaving off braces on what I meant to be a block if
statement. I'm not saying it never happened. I've probably been stung by this,
too. I just remember other problems I've had a lot more clearly (such as
forgetting to put breaks in my switch cases). But I really doubt Walter would
change something like this at this point -- especially if it's going to require
him to add brackets all over Phobos sources. And Walter's the one who has to be
sold on it.

jcc7



OK thanks - good advice =) No I haven't been lurking - I'm just so excited by
this language I've kind of gone in with both feet a bit. I must admit that it
has annoyed me in the past when other people have done this on lists I've been
reading for ages, so I guess I owe you guys an apology: Sorry Everbody!

It's useful to know that this sort of stuff is unlikely to get changed at this
stage, so thanks for that =)

The above was really just me trying to reason through "out loud" why it is
people get so defensive when presented with guidlines or rules like this. It's
always a difficulty at work and seeing the same reaction here made me start to
consider the possibilities, because it often stops people thinking logically
without them realising it - I really didn't mean to offend anybody. I wasn't
intending to be sarcastic or anything, just trying to help. Again - apologies =)

OK so, what sort of stuff is decided already and what is changeable?

Cheers

Munch
Nov 19 2005
parent J C Calvarese <technocrat7 gmail.com> writes:
In article <dlmpq4$2uri$1 digitaldaemon.com>, Munchgreeble says...

.. (snip) ...


OK so, what sort of stuff is decided already and what is changeable?

Cheers

Munch


Since Walter is the dictator (he's a friendly and smart dictator, though), he's
the only one who can answer that. I think he's written things like he doesn't
expect any major changes at this point, but ultimately he's the one who decides
what's a major change and what's a minor change. And it's conceivable that if
someone makes a convincing argument that there's a show-stopper, he might be
persuaded to revisit a fundamental decision. 

I think he's busy fixing bugs right now, and that's the only changes that I
expect at this point. But he seems to welcome discussions about any idea that
might improve D. Even is he's not replying that doesn't mean he's not reading
them. Also, he has a habit of replying 2 months later to a discussion that had
long since died out. Often, it's just a "You're right" to someone that had
already guessed the answer to the question.

jcc7
Nov 19 2005
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Codebases I've worked on have ranged in size, but generally been fairly 
large, and have involved more programmers than just myself and one or 
two other people.

I'm sorry if you've had negative experiences with this, but quite 
frankly, if I ever met anyone who consistently (or even more than once) 
had a problem with something so simple, whether they were a doctor, 
programmer, or even a waiter... I wouldn't expect them to hold their job 
long.

In my view, whatever excuses you want to make (drunk, whatever) if you 
are working on the job, and you cannot put something in the right place 
for the compiler (which is the whole point of 80% of programming 
constructs) you don't know what you are doing.

It is very similar in my mind to a waiter or waitress dropping a tray. 
If someone needs to push around a cart (except in cirumstances like 
airplanes and trains) to avoid breaking plates and glasses... that does 
not mean all restaraunts should have carts installed.  That means that 
person needs to find another line of work.

You may think, everything would just be better if carts were used in 
restaraunts.  Everything would be better if cars had a builtin limit 
such that they could not go faster than 75 miles per hour.  This makes 
mistakes impossible, and these are such simple changes!

Well, I of course disagree.  There are always going to be possible 
mistakes you can make.  When I was much younger and first started 
programming, I made tons of mistakes.  I programmed a lot of Assembly 
and BASIC back then, and you can imagine how many times my computer 
crashed.  I'm not perfect, nor am I expecting anyone to be.

But I learned.  I still make mistakes, but I don't make the same 
elementary ones now.  That's what you're supposed to do.  Learn.  I 
know, I know, programmers seem to want to run from that word more and 
more these days.  Go to college, and you pop out an expert, just like 
that.  Unlike every other freaking profession in the world, including 
even driving a car.  Yeah, right.

There are common mistakes, and there are common mistakes.  I would 
really have to argue that this mistake you are talking about is just so 
elementary, that it will only hit those programmers who NEED to be hit. 
  It was stupid mistakes like this one that hit me when I was younger 
and taught me to understand program flow.  I didn't make mistakes like 
these because I was tired, I made them because I was stupid.  I am no 
longer as stupid.

You may choose to put those programmers you manage in small plastic 
boxes with soft plastic gloves, but in the end that will just have the 
effect of making them remain in that exact state.  They'll never learn, 
they'll never grow.  No, people need to make mistakes... it's just how 
it works.

And, yes, there will always be that person who makes the mistake 
consistently, but is good at what they do otherwise.  There are waiters 
and waitresses who break plates, but are amazing otherwise.  Doctors who 
need to be reminded to wash their hands, but can save more lives than 
Superman.  For these people, yes, an option might be nice.  But really, 
if such a person can't find a way to overcome their problem (by evasion 
or similar, I mean), they aren't so great after all.

I really wouldn't be nearly as interested in using D if it made such 
changes, and I'm totally serious when I say that.  I think D is a great 
and wonderful language, with lots of benefits over others, but if it 
goes the route of thick, soft, plastic gloves... well, I'll have to wait 
for another that actually takes the right route, or make my own.

-[Unknown]



 In article <dlkmou$1882$1 digitaldaemon.com>, JT says...
 
 

Sorry I didnt mean to be rude or anything, and I can understand why some people
would find this usefull. I simply cannot understand wanting to impose this on
everyone, because, to me, its actually a style issue more than anything.... 


 
 
 Don't worry, no offense taken =) I can understand that you can't understand it,
 but that doesn't mean it's not a good idea of course, it probably just means we
 have different experience of coding.
 
 I guess a lot of this comes down to the kind of software you write. I'm used to
 working in teams - each new project I work on I'll be working with at least
some
 people who I've never worked with before. Some projects, I'm so removed from
the
 coding team that I hardly actually get to see the source code, othertimes I'm
in
 there coding with everybody else. It makes a big difference if a language has
 something built in - which is one of the reasons I'm so keen on D. Loads of the
 good stuff I try to encourage - fully fledged use of contracts (never managed
 it), basic asserts, unit tests automatically run as part of the build process
 (just managed it for the first time on my current project) etc. is part of the
 language in D. The bracketing issue is another such thing.
 
 I can understand that if for example somebody spends most of their time working
 on code that they've written themselves, this kind of thing won't bother them
 too much. Working on large code bases and/or in teams you come across a huge
 variety of bugs - the worst ones always have multiple causes. Any cause that we
 can rule out as part of the language has got to be a good thing.
 
 To take a meta view on this problem, what you have here are two groups of
 people: one whose experience identifies a problem that can easily be fixed,
 another whose experience hasn't found this to be a problem.
 
 The population of D users is made up of these two groups. The population can
 also be split into people who think that the overhead of having to use braces
is
 a bad thing and those who don't.
 
 What we need to weigh up is how much the population as a whole would be
affected
 1. by lack of brace enforcement and 2. by brace enforcement.
 
 In my experience (which I'll admit is not the same as everybody elses), people
 who wish to have the option of no braces are never that bothered about giving
up
 that option once they start doing it, but extra bugs bother everybody.
 
 To summarise my argument:
 - One of D's main strands is robustness (great - gets my vote)
 - One of D's main principals is including features in the core language (great
-
 gets my vote)
 - Another of D's main principals is to keep the compiler in mind (great - gets
 my vote)
 - This suggestion fits in with all three of these goals, and doesn't conflict
 with any of D's aims.
 - Some people can see the benefit of this, others not, but just because you
 personally have no experience of this being a problem, doesn't mean it isn't.
 - We need the language to be the best fit for the population as a whole, not
any
 particular subgroup. Assuming the target population is identified by the
 language aims/goals as expressed above then it is logical to include this
 change.
 
 I will try not to add any more to this - these arguments do tend to ramble on!
 It would be nice if somebody neutral could summarise the two sides of the
 argument as I have probably been biased by my own experience. Perhaps the
 anti-brace-enforcement guys could summarise their position and we coudl cut and
 paste the two summaries? I was thinking it's worth putting this in the Wiki:
 (http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same
ground
 being covered over and over.
 
 Cheers
 
 Munch
Nov 19 2005
parent Munchgreeble bigfoot.com writes:
Hi There =)

OK, thanks for your point of view. It's always good to have the benefit of other
people's experience. I guess this is kind of academic now, (i.e. I'm not
expecting the brace thing to get changed), but I wanted to address a couple of
points:

1. I take your illustration on board, but D will presumably not just be used by
professional programmers. There will be plenty of school kids, hobbyists etc.
who pick the language up, maybe to try and help out on an open source project or
something. I agree about the need to put time into learning, but I would hope
that the language could be as helpful as possible in preventing new coders (or
old ones for that matter) falling into pitfalls.
2. I may have communicated my point poorly. I've never come across anybody who
consistently makes this coding mistake. Like a lot of trivial coding errors, you
make it once - go "d'oh" - then never conciously make the mistake again. If it
happens in future it happens by accident, but it still happens. Most people make
a wide variety of accidental errors with varying levels of frequency. E.g.
adding a semi-colon at the end of an if statement (which D now outlaws -hoorah)
is fairly rare, but most people have done it on occasion. Similarly with missing
out braces when you need them. It's just a statistical thing - it's about
reducing the probability of bugs occuring, and increasing the probability of
finding bugs when they do occur.

I really like your speed limiting example because it's exactly the same
argument. Here in the UK, all haulage is speed limited by law, there has been
massive pressure to get trains speed limited and that's now going ahead, there
have also been discussions of speed limiting all road vehicles. Similarly
wearing of seatbelts is requred by law. Thinking outside of road transport,
things like firearms are illegal. This is just because applying these rules
reduces the number of deaths. The rules are midly inconvenient and even
infuriate some. They may even *cause* deaths in some cases. But with them in
place the _total_ number of deaths is lower.

I have never understood the desire to have your own way, at the expense of
others, but I guess it's just a cultural thing. However, I accept that
regardless of me not understanding why, some people really do want that freedom,
so I take your point =) I shall try to stay more aware of it in future.

Thanks

Munch

In article <dlnnct$nd3$1 digitaldaemon.com>, Unknown W. Brackets says...

Codebases I've worked on have ranged in size, but generally been fairly 
large, and have involved more programmers than just myself and one or 
two other people.

I'm sorry if you've had negative experiences with this, but quite 
frankly, if I ever met anyone who consistently (or even more than once) 
had a problem with something so simple, whether they were a doctor, 
programmer, or even a waiter... I wouldn't expect them to hold their job 
long.

In my view, whatever excuses you want to make (drunk, whatever) if you 
are working on the job, and you cannot put something in the right place 
for the compiler (which is the whole point of 80% of programming 
constructs) you don't know what you are doing.

It is very similar in my mind to a waiter or waitress dropping a tray. 
If someone needs to push around a cart (except in cirumstances like 
airplanes and trains) to avoid breaking plates and glasses... that does 
not mean all restaraunts should have carts installed.  That means that 
person needs to find another line of work.

You may think, everything would just be better if carts were used in 
restaraunts.  Everything would be better if cars had a builtin limit 
such that they could not go faster than 75 miles per hour.  This makes 
mistakes impossible, and these are such simple changes!

Well, I of course disagree.  There are always going to be possible 
mistakes you can make.  When I was much younger and first started 
programming, I made tons of mistakes.  I programmed a lot of Assembly 
and BASIC back then, and you can imagine how many times my computer 
crashed.  I'm not perfect, nor am I expecting anyone to be.

But I learned.  I still make mistakes, but I don't make the same 
elementary ones now.  That's what you're supposed to do.  Learn.  I 
know, I know, programmers seem to want to run from that word more and 
more these days.  Go to college, and you pop out an expert, just like 
that.  Unlike every other freaking profession in the world, including 
even driving a car.  Yeah, right.

There are common mistakes, and there are common mistakes.  I would 
really have to argue that this mistake you are talking about is just so 
elementary, that it will only hit those programmers who NEED to be hit. 
  It was stupid mistakes like this one that hit me when I was younger 
and taught me to understand program flow.  I didn't make mistakes like 
these because I was tired, I made them because I was stupid.  I am no 
longer as stupid.

You may choose to put those programmers you manage in small plastic 
boxes with soft plastic gloves, but in the end that will just have the 
effect of making them remain in that exact state.  They'll never learn, 
they'll never grow.  No, people need to make mistakes... it's just how 
it works.

And, yes, there will always be that person who makes the mistake 
consistently, but is good at what they do otherwise.  There are waiters 
and waitresses who break plates, but are amazing otherwise.  Doctors who 
need to be reminded to wash their hands, but can save more lives than 
Superman.  For these people, yes, an option might be nice.  But really, 
if such a person can't find a way to overcome their problem (by evasion 
or similar, I mean), they aren't so great after all.

I really wouldn't be nearly as interested in using D if it made such 
changes, and I'm totally serious when I say that.  I think D is a great 
and wonderful language, with lots of benefits over others, but if it 
goes the route of thick, soft, plastic gloves... well, I'll have to wait 
for another that actually takes the right route, or make my own.

-[Unknown]



 In article <dlkmou$1882$1 digitaldaemon.com>, JT says...
 
 

Sorry I didnt mean to be rude or anything, and I can understand why some people
would find this usefull. I simply cannot understand wanting to impose this on
everyone, because, to me, its actually a style issue more than anything.... 


 
 
 Don't worry, no offense taken =) I can understand that you can't understand it,
 but that doesn't mean it's not a good idea of course, it probably just means we
 have different experience of coding.
 
 I guess a lot of this comes down to the kind of software you write. I'm used to
 working in teams - each new project I work on I'll be working with at least
some
 people who I've never worked with before. Some projects, I'm so removed from
the
 coding team that I hardly actually get to see the source code, othertimes I'm
in
 there coding with everybody else. It makes a big difference if a language has
 something built in - which is one of the reasons I'm so keen on D. Loads of the
 good stuff I try to encourage - fully fledged use of contracts (never managed
 it), basic asserts, unit tests automatically run as part of the build process
 (just managed it for the first time on my current project) etc. is part of the
 language in D. The bracketing issue is another such thing.
 
 I can understand that if for example somebody spends most of their time working
 on code that they've written themselves, this kind of thing won't bother them
 too much. Working on large code bases and/or in teams you come across a huge
 variety of bugs - the worst ones always have multiple causes. Any cause that we
 can rule out as part of the language has got to be a good thing.
 
 To take a meta view on this problem, what you have here are two groups of
 people: one whose experience identifies a problem that can easily be fixed,
 another whose experience hasn't found this to be a problem.
 
 The population of D users is made up of these two groups. The population can
 also be split into people who think that the overhead of having to use braces
is
 a bad thing and those who don't.
 
 What we need to weigh up is how much the population as a whole would be
affected
 1. by lack of brace enforcement and 2. by brace enforcement.
 
 In my experience (which I'll admit is not the same as everybody elses), people
 who wish to have the option of no braces are never that bothered about giving
up
 that option once they start doing it, but extra bugs bother everybody.
 
 To summarise my argument:
 - One of D's main strands is robustness (great - gets my vote)
 - One of D's main principals is including features in the core language (great
-
 gets my vote)
 - Another of D's main principals is to keep the compiler in mind (great - gets
 my vote)
 - This suggestion fits in with all three of these goals, and doesn't conflict
 with any of D's aims.
 - Some people can see the benefit of this, others not, but just because you
 personally have no experience of this being a problem, doesn't mean it isn't.
 - We need the language to be the best fit for the population as a whole, not
any
 particular subgroup. Assuming the target population is identified by the
 language aims/goals as expressed above then it is logical to include this
 change.
 
 I will try not to add any more to this - these arguments do tend to ramble on!
 It would be nice if somebody neutral could summarise the two sides of the
 argument as I have probably been biased by my own experience. Perhaps the
 anti-brace-enforcement guys could summarise their position and we coudl cut and
 paste the two summaries? I was thinking it's worth putting this in the Wiki:
 (http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same
ground
 being covered over and over.
 
 Cheers
 
 Munch
Nov 19 2005
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Again, it sounds like coding standards enforcement is what you really 
want, and it's something I'm greatly interested in myself.

Since I always use versioning systems whenever possible, it would 
probably also be workable to simply have a pre-checkin script/program 
which checks coding standards (and luckily, D is much much easier to 
parse.)  Still, it seems like the compiler - which already parses it, 
and has the most semantic logic - would be a great place to do it.

Thing is, I'm a real prude with my coding standards.  Having a { 
anywhere but on a line by itself properly indented would only be 
considered a bug by me.  In fact, I even treat mispellings and space at 
the end of lines similarly.  I've even had compliments on how clean, 
understandable, and commented my code and the code of those I've 
directed has been.

Still, it's very hard to enforce standards in larger projects... 
something automated would be great.

-[Unknown]



 Actually in my experience this mistake is more often made by newer 
 programmers who haven't got used to using brackets yet. Since I work 
 with a wide range of programmers, from "just graduated" to 35 years on 
 the job, if we're going to move our teams over to using D in the future 
 (and I'd like us to) I'm looking for a language that is suitable for all 
  programmers. As an aside though, like you say, we are all human. When 
 it's late and you're tired and haven't eaten and the deadlines looming 
 and you also know your family is wanting you home etc. etc. it's very 
 easy to add a line of debug and forget to add the braces. It's not so 
 much about the kind of mistake - sure it's fairly rare - but given the 
 ease of fixing it -why not?
 
 I can appreciate the "vertical real estate" argument, but in that case
 how about:
 
    if (cond) {
       blah; }
 
 Or even:
 
    if (cond) { blah; }
 
 I hear Bruno's point about auto indent, and the lint ideas, compiler 
 warning flags etc. but surely the whole spirit of D is to include this 
 stuff _in_the_language_ otherwise people end up not using it.
 
 Cheers
 
 Munch
Nov 18 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
Yeah; coding styles are a bit like religion to some. I remember a long 
thread about making the 'override' keyword mandatory (to help with 
maintenance), but some folks griped miserably about having to type a few 
extra characters ...

There's no pleasing everyone, I guess.


"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dljqcr$d63$1 digitaldaemon.com...

 Honestly, and I mean no disrespect, but I've never understood why people 
 make such a big deal out of this one.

 I personally value my vertical real estate when programming, and as I use 
 so much for train-of-thought comments (unlike many programmers these 
 days), I always leave the braces off for single statements.

 Indeed, I've seen some who use:

 if (condition) expression;

 While that goes against my coding standards, and as such is something I 
 never do, I don't think the people who prefer that style for short if 
 conditionals would like the requirement of braces either.

 I strictly follow coding standards, and although I have had problems with 
 a semicolon at the end of my ifs, whiles, and fors... I have never (nor 
 have any of the programmers under me ever) accidentally screwed up a 
 conditional because it didn't have braces.

 Don't get me wrong; I understand that if you were used to braces always 
 being there, you might make the mistake.  We're all only human.  But... 
 and again, with all due respect... it seems to me such a weird mistake to 
 make.  If I ever employed a programmer who seriously had this problem, I 
 would worry that requiring braces wouldn't help much.  But this is only 
 me, and again I am not in any way judging you or anyone who does have the 
 problem, just explaining my own worries.

 That said, I personally would like a compiler that could (optionally, e.g. 
 with a "plugin") check code against coding standards: no multiple 
 statements on one line, no lack of spaces around operators, no braces on 
 ifs and other conditionals.  But, there'd have to be a way to ensure that 
 only developers use these conditions; not people compiling code for their 
 system.

 -[Unknown]



 OK so here is my other suggestion. It's very simple to implement from a 
 compiler
 perspective - it adds robustness - it just needs a slight rearangement of 
 the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html

 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like 
 this:

 while (i < 9)
 i++; j++;

 or this

 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;

 or more generally

 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;

 This is one of those things that when you start out coding you kid 
 yourself that
 you save time by skipping out the braces. As the years roll by you 
 gradually
 come across bugs that are harder and harder to find, that had part of 
 their
 cause in missing curlys. Sooner or later you learn to use braces 
 everywhere. I
 occasionally do code reviews and whenever I've come across code which 
 doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in the 
 code.
 This is easy to fix in the language syntax, thus:

 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement

 Not enough motivation yet? Finally, this also kills one of the most 
 insidious
 bugs in C/C++/Java:

 if (cond);
 <code intended to be conditional>

 I've only done this a few times in my programming life, mainly in the 
 first few
 years, but boy did some of those bugs take a long time to find. Note that 
 this
 one can't be fixed by voluntarily entering braces yourself:

 if (cond);
 {
 <code intended to be conditional>
 }

 The above syntax however, makes this a compile time error =)

 (Obviously the above also applies to "for", "while" etc. )

 Regards

 Munch
Nov 18 2005
parent Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <dllj29$21st$1 digitaldaemon.com>, Kris says...

Yeah; coding styles are a bit like religion to some. I remember a long 
thread about making the 'override' keyword mandatory (to help with 
maintenance), but some folks griped miserably about having to type a few 
extra characters ...

There's no pleasing everyone, I guess.


You're right there! It seems sad that these sorts of complaints wrecked good
ideas like that. Surely we want to make a top level decision of prefering
freedom of expression, or prefering robustness, which everybody can contribute
to, but once the decision is made that can flavour the whole language. Each time
an issue like this comes up you go with the "robustness" or "freedom of
expression" choice as previously decided (unless the default choice has a
separate counter argument, other than the general ones associated with the
"robustness" or "freedom"). Otherwise, you are in danger of ending up with a
designed-by-committee hotch potch which has no clear direction.

Maybe that's putting it a bit too strongly, but it would be nice if all the
language features were pulling in the same direction.

Just my tuppence.

Now I really really must go to bed =)

Night all

Munchgreeble
Nov 18 2005
prev sibling next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
 
 while (i < 9)
 i++; j++;
 
 or this
 
 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;
 
 or more generally
 
 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;
 
 This is one of those things that when you start out coding you kid yourself
that
 you save time by skipping out the braces. As the years roll by you gradually
 come across bugs that are harder and harder to find, that had part of their
 cause in missing curlys. Sooner or later you learn to use braces everywhere. I
 occasionally do code reviews and whenever I've come across code which doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
 This is easy to fix in the language syntax, thus:
 
 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement
 
 Not enough motivation yet? Finally, this also kills one of the most insidious
 bugs in C/C++/Java:
 
 if (cond);
 <code intended to be conditional>
 
 I've only done this a few times in my programming life, mainly in the first few
 years, but boy did some of those bugs take a long time to find. Note that this
 one can't be fixed by voluntarily entering braces yourself:
 
 if (cond);
 {
 <code intended to be conditional>
 }
 
 The above syntax however, makes this a compile time error =)
 
 (Obviously the above also applies to "for", "while" etc. )
 
 Regards
 
 Munch
 
 


Such error is quite uncommon with nowadays modern IDEs, specifically, 
those with auto-indentation.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Nov 18 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
 From the 'What is D' page: "It doesn't come with a VM, a religion, or 
an overriding philosophy. It's a practical language for practical 
programmers who need to get the job done quickly, reliably, and leave 
behind maintainable, easy to understand code."

It appears forcing to use {} is dangerously close to having a 'religion' 
or 'overriding philosophy,' and yet if it produces more maintainable 
code it might be worth it. I'm more on the ledge leaning away from it 
however, simply because I couldn't do my favorite 'debug writef' lines 
anymore.

Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
 
 while (i < 9)
 i++; j++;
 
 or this
 
 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;
 
 or more generally
 
 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;
 
 This is one of those things that when you start out coding you kid yourself
that
 you save time by skipping out the braces. As the years roll by you gradually
 come across bugs that are harder and harder to find, that had part of their
 cause in missing curlys. Sooner or later you learn to use braces everywhere. I
 occasionally do code reviews and whenever I've come across code which doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
 This is easy to fix in the language syntax, thus:
 
 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement
 
 Not enough motivation yet? Finally, this also kills one of the most insidious
 bugs in C/C++/Java:
 
 if (cond);
 <code intended to be conditional>
 
 I've only done this a few times in my programming life, mainly in the first few
 years, but boy did some of those bugs take a long time to find. Note that this
 one can't be fixed by voluntarily entering braces yourself:
 
 if (cond);
 {
 <code intended to be conditional>
 }
 
 The above syntax however, makes this a compile time error =)
 
 (Obviously the above also applies to "for", "while" etc. )
 
 Regards
 
 Munch
Nov 18 2005
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dlkpot$1bc3$1 digitaldaemon.com>, clayasaurus says...

 From the 'What is D' page: "It doesn't come with a VM, a religion, or 
an overriding philosophy. It's a practical language for practical 
programmers who need to get the job done quickly, reliably, and leave 
behind maintainable, easy to understand code."

It appears forcing to use {} is dangerously close to having a 'religion' 
or 'overriding philosophy,' and yet if it produces more maintainable 
code it might be worth it. I'm more on the ledge leaning away from it 
however, simply because I couldn't do my favorite 'debug writef' lines 
anymore.


This idea sounds tempting, but I myself actually find neatly organized and well
indented code easier to maintain if the one-liner statement bodies are not {}'d
for the simple reason that the code seems less 'busy' and more fits on a screen.

OTOH, there's a consistency argument for the required {} idea too - if {} are
required to define one member classes, structs, unions, etc. and also one
statement functions, why should anything else with a different scope (like
conditional statement bodies) be different?


Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
 
 while (i < 9)
 i++; j++;
 
 or this
 
 if (cond)
 <debug statement added to find bug>;
 <line of code intended to be conditional>;
 
 or more generally
 
 if (cond)
 <added code here>;
 <ORIGINAL conditional line of code>; <and/or more added code>;
 <and/or more added code>;
 
 This is one of those things that when you start out coding you kid yourself
that
 you save time by skipping out the braces. As the years roll by you gradually
 come across bugs that are harder and harder to find, that had part of their
 cause in missing curlys. Sooner or later you learn to use braces everywhere. I
 occasionally do code reviews and whenever I've come across code which doesn't
 have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
 This is easy to fix in the language syntax, thus:
 
 IfStatement:
 if ( Expression ) BlockStatement
 if ( Expression ) BlockStatement else BlockStatement
 if ( Expression ) BlockStatement else IfStatement
 
 Not enough motivation yet? Finally, this also kills one of the most insidious
 bugs in C/C++/Java:
 
 if (cond);
 <code intended to be conditional>
 
 I've only done this a few times in my programming life, mainly in the first few
 years, but boy did some of those bugs take a long time to find. Note that this
 one can't be fixed by voluntarily entering braces yourself:
 
 if (cond);
 {
 <code intended to be conditional>
 }
 
 The above syntax however, makes this a compile time error =)
 
 (Obviously the above also applies to "for", "while" etc. )
 
 Regards
 
 Munch
Nov 18 2005
parent Dave <Dave_member pathlink.com> writes:
It appears forcing to use {} is dangerously close to having a 'religion' 
or 'overriding philosophy,' and yet if it produces more maintainable 
code it might be worth it. I'm more on the ledge leaning away from it 
however, simply because I couldn't do my favorite 'debug writef' lines 
anymore.


This idea sounds tempting, but I myself actually find neatly organized and well
indented code easier to maintain if the one-liner statement bodies are not {}'d
for the simple reason that the code seems less 'busy' and more fits on a screen.

OTOH, there's a consistency argument for the required {} idea too - if {} are
required to define one member classes, structs, unions, etc. and also one
statement functions, why should anything else with a different scope (like
conditional statement bodies) be different?


I had to write some Perl code today after a while away from it, and I take that
last paragraph back <g> Made for a long Friday!

I do like Perl's

<statement> if(<condition>);

syntax somewhat, but can't say I care for it enough to add it to D.

- Dave
Nov 18 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 18 Nov 2005 09:53:12 -0500, clayasaurus wrote:


  From the 'What is D' page: "It doesn't come with a VM, a religion, or 
 an overriding philosophy. It's a practical language for practical 
 programmers who need to get the job done quickly, reliably, and leave 
 behind maintainable, easy to understand code."
 
 It appears forcing to use {} is dangerously close to having a 'religion' 
 or 'overriding philosophy,' and yet if it produces more maintainable 
 code it might be worth it. I'm more on the ledge leaning away from it 
 however, simply because I couldn't do my favorite 'debug writef' lines 
 anymore.


That is why I'm saying allow the coder to omit braces but if they do so,
they also have to tell the compiler that they choosing to do so. This also
acts as a warning sign to future maintainers.

-- 
Derek Parnell
Melbourne, Australia
19/11/2005 8:38:39 AM
Nov 18 2005
parent Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <1u7tsrb0a3rql$.k8phrfnxfudx$.dlg 40tude.net>, Derek Parnell says...

On Fri, 18 Nov 2005 09:53:12 -0500, clayasaurus wrote:

 It appears forcing to use {} is dangerously close to having a 'religion' 
 or 'overriding philosophy,' and yet if it produces more maintainable 
 code it might be worth it. I'm more on the ledge leaning away from it 
 however, simply because I couldn't do my favorite 'debug writef' lines 
 anymore.


That is why I'm saying allow the coder to omit braces but if they do so,
they also have to tell the compiler that they choosing to do so. This also
acts as a warning sign to future maintainers.


We should definitely include this in any summary we produce! Good idea. I guess
the objection would be that we could end up with a language *full* of options if
we take this solution as a precedent. Also I guess making it optional increases
compiler complexity. Still, this solution would definitely suit me personally.

Cheers

Munch
Nov 18 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Munch wrote:

 OK so here is my other suggestion. It's very simple to implement from a
compiler
 perspective - it adds robustness - it just needs a slight rearangement of the
 sytnax. I found a thread on it in the archives here:
 http://www.digitalmars.com/d/archives/1418.html
 
 Why not get rid of the looks-like-it's-nested-when-it-isn't bugs.


It would break code portability.  And is this really a problem for most 
people?  I don't think I've ever encountered this bug myself.


Sean
Nov 18 2005
prev sibling parent Larry Evans <cppljevans cos-internet.com> writes:
On 11/17/2005 04:58 PM, clayasaurus wrote:

 If you have a suggestion to make the language better, don't be afraid to 
 say it. As of yet D is still a work in progress.
 


I'd like to suggest that, by default, class types are created on stack, 
just like struct types, instead of in heap, since heap creation is much 
slower, IIUC.  However, I suspect I'm unaware of some reason why it
was done this way.  Any references justifying this decision?


The above conclusion about class creation in heap is based on:

    Class objects are instantiated by reference only.

from:

    http://www.digitalmars.com/d/class.html

and also on:

    To have a class allocated on the stack that has a destructor, this
    is the same as a declaration with the auto attribute.

from:

    http://www.digitalmars.com/d/memory.html#stackclass

although the last quote is hard to understand.  Should it be:

    To have a class with a destructor allocated on the stack, add the
    auto attribute to the class declaration.  IOW, a class, Foo, is
    declared an auto class as follows:

      auto class Foo{...}

    as explained in

       http://www.digitalmars.com/d/class.html#auto

    ?
Nov 19 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
If your robustness suggestions are about 'const' and the like
then try to dig into archives first.

Andrew.
http://terrainformatica.com


"Munch" <Munch_member pathlink.com> wrote in message 
news:dlj15s$2dqp$1 digitaldaemon.com...

 Hi,

 First off thanks so much all of you guys, and especially Walter, for 
 working on
 what looks like a fantastic new language. My reaction and those of the
 colleagues I've mailed about it has bascially been "this is what we've 
 been
 wanting for years". I love the way you've taken great ideas from all over 
 the
 place and added a few new ones of your own.

 Is the language fairly fixed now, or are you still open to ideas? There 
 are a
 couple of robustness suggestions I had that would find more bugs at 
 compile time
 in a way that would be familiar to your hardened C/C++ programmer target
 audience.

 Thanks again

 Munch
Nov 17 2005
parent reply Munch <Munch_member pathlink.com> writes:
In article <dlj23c$2fmd$1 digitaldaemon.com>, Andrew Fedoniouk says...

If your robustness suggestions are about 'const' and the like
then try to dig into archives first.


Thanks for the tip - yes one of the ideas was about the different kinds of
const. Wow this is really encouraging I found nothing but well presented,
clearly thought out arguments in the archive - you guys are really working hard!
OK well I've nothing to add on the const issue. From what I've gathered the
reason const means "compile time constant" is
1. the read-only "in" parameter is basically part of the contract of the method
(so presumably, the answer is to use contracts to enforce it at run time)
2. the effort of adding "contract-const" checking to the compiler is non-trivial

So now I have a question: how do you specify read-onlyness in contracts?

Is there some syntax I could use inside the contract blocks to mark a method
parameter or class member as read-only?

One really useful thing in specifying post conditions is to be able to get at
the value of the parameters as they were when they were passed in. Is there
syntax for that? What I mean is - in the same way that "result" gets bound to
the return value on exit, it would be really handy if each parameter "p" got
bound to say "p_in", so if you had parameters "alpha" and "kappa" in the
function prototype then in the out block you'd have "alpha", "kappa", "alpha_in"
and "kappa_in". This would make it straightfoward to check all kinds of post
conditions, including read-onlyness.

Looking at the example code:

long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) == x);
}
body
{
return math.sqrt(x);
}

That's fine as long as you have a nice short routine and you're sure that x is
the same at the end as it is at the start. A lot of the time you have a longer
routine though and can't be sure x hasn't been changed accidentally. In fact you
might well want to assert specifically that the sqrt is performed on the value
of x that was passed in, so you want to specify:

long square_root(long x)
in
{
assert(x >= 0);
}
out (result, x_in)
{
assert((result * result) == x_in);
}
body
{
return math.sqrt(x);
}

I'm new to the language so feel free to point me at the appropriate manual
page/archive post if this has already been covered. Thanks for your time.

Cheers

Munch

PS In article <dlj1t3$2f00$1 digitaldaemon.com>, clayasaurus says...

If you have a suggestion to make the language better, don't be afraid to 
say it. As of yet D is still a work in progress.


Great - thanks for the encouragement =)
Nov 17 2005
parent reply Sean Kelly <sean f4.ca> writes:
Munch wrote:

 From what I've gathered the reason const means "compile time constant" is
 1. the read-only "in" parameter is basically part of the contract of the method
 (so presumably, the answer is to use contracts to enforce it at run time)
 2. the effort of adding "contract-const" checking to the compiler is
non-trivial

 So now I have a question: how do you specify read-onlyness in contracts?


There is no easy way to do this.  Walter's argument against logical 
const-ness seems to be that it is misleading, as it's typically fairly 
easy to cast away the const qualifier and because even const operations 
are allowed to modify object state (mutable members or data referenced 
by pointers, most commonly).  A hack might be to store a 'fingerprint' 
of an object (basically a memcpy of the object data) in the in clause 
and compare against it in the out clause, but this may still miss things 
(if data managed by reference is modified, for example).


 Is there some syntax I could use inside the contract blocks to mark a method
 parameter or class member as read-only?


Not really.  You could do this cooperatively by adding setReadOnly and 
clearReadOnly properties to a class, but there's nothing in the language 
to support this.


 One really useful thing in specifying post conditions is to be able to get at
 the value of the parameters as they were when they were passed in. Is there
 syntax for that?


Not at the moment, though it would be nice.  Currently, the easiest 
thing here would be to use thread local storage to temporarily maintain 
copies of parameter data for comparison later.  I'm planning on adding 
TLS support to Ares and when I do I suppose I should submit a patch for 
Phobos as well.


Sean
Nov 17 2005
parent Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
Sean Kelly wrote:


 Munch wrote:

 One really useful thing in specifying post conditions is to be able to 
 get at
 the value of the parameters as they were when they were passed in. Is 
 there
 syntax for that?


 
 
 Not at the moment, though it would be nice.  Currently, the easiest 
 thing here would be to use thread local storage to temporarily maintain 
 copies of parameter data for comparison later.  I'm planning on adding 
 TLS support to Ares and when I do I suppose I should submit a patch for 
 Phobos as well.
 


Thanks. That's a possible workaround, but I'd be very nervous delivering 
code where the contracts had side effects like that. Looking at the 
level of responses on this vs the braces suggestion, I'm guessing nobody 
has really thought about this one before? It really would be very useful 
to be able to differentiate between the "in" and "out" values of 
parameters in an out block. I'm assuming it's Walter who we'd need to 
talk to about this?

Would it be useful to kick this off again in a separate thread so that 
people can see it through the braces argument?

Munch
Nov 18 2005