View mode: basic / threaded / horizontal-split · Log in · Help
November 18, 2005
Re: Access parameter values in out clauses [was: Re: D - Looks great! Open to changes still?]
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
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
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?
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
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....
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
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
> 
>
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
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
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
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
>> 
>>
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
> 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
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
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
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?]
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
November 18, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
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
1 2 3 4 5
Top | Discussion index | About this forum | D home