• Jakub Schmidtke (21/21) Jan 03 2007 I started learning D language and I have a question - why doesn't it use...
• Daniel Keep (16/38) Jan 05 2007 Intellectually, I know that it's a good thing. It requires us to know
• Bruno Medeiros (7/20) Jan 06 2007 You might consider using this workaround:
• renoX (10/10) Jan 06 2007 As often, it is a matter of 'easy to write' vs 'easy to read'.

Jakub Schmidtke <tanis aster.net.pl> writes:

I started learning D language and I have a question - why doesn't it use 'out'

I have found topics about this feature (or a problem), but there was no real
discussion.
So my question is, why is it that way?
I think, that having mandatory 'out' or 'inout' or 'lazy' in front of
parameter (at call site)
which is treated in a different way than just to pass a value is a really good
way to avoid bugs.
Especially in group project, when someone decides that it would be a really
good idea to change
one of the parameters to 'lazy', it would be nice to have a compile error,
rather than
strange bug in the code, when something stops working and nobody knows why -
the bug similar
to having something like assert(a++); in Java - when assertions are switched
off, program stops
working properly. The difference is that 'assert' is known to be 'suspicious',
and in D every function
may behave differently than we expected (and worse - it may change the way it
treats its arguments).

Daniel Keep <daniel.keep+lists gmail.com> writes:

Jakub Schmidtke wrote:
 I started learning D language and I have a question - why doesn't it use 'out'

 I have found topics about this feature (or a problem), but there was no real
 discussion.
 So my question is, why is it that way?
 I think, that having mandatory 'out' or 'inout' or 'lazy' in front of
 parameter (at call site)
 which is treated in a different way than just to pass a value is a really good
 way to avoid bugs.
 Especially in group project, when someone decides that it would be a really
 good idea to change
 one of the parameters to 'lazy', it would be nice to have a compile error,
 rather than
 strange bug in the code, when something stops working and nobody knows why -
 the bug similar
 to having something like assert(a++); in Java - when assertions are switched
 off, program stops
 working properly. The difference is that 'assert' is known to be 'suspicious',
 and in D every function
 may behave differently than we expected (and worse - it may change the way it
 treats its arguments).
 

Intellectually, I know that it's a good thing.  It requires us to know 
what we're doing, and be explicit about it.


of me.  "out" this, "out" that: I know it's out!  Stop making me repeat 
myself just call the damn function!

Kinda like how you have to handle exceptions in Java: great idea in 
theory, but a complete pain in the arse in reality.  I must have spent 
about a third of my coding time in Java just writing the damn exception 
handlers; it eventually got to the point where I just used empty, 
catch(Exception)s to bypass the whole thing, just so I could get actual 
work done.

I'm not really sure if this falls into that category, but it's something 
to think about.  The question, I suppose, is whether the benefits 
outweigh the drawbacks.

	-- Daniel

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Daniel Keep wrote:
 
 Kinda like how you have to handle exceptions in Java: great idea in 
 theory, but a complete pain in the arse in reality.  I must have spent 
 about a third of my coding time in Java just writing the damn exception 
 handlers; it eventually got to the point where I just used empty, 
 catch(Exception)s to bypass the whole thing, just so I could get actual 
 work done.
 
 I'm not really sure if this falls into that category, but it's something 
 to think about.  The question, I suppose, is whether the benefits 
 outweigh the drawbacks.
 
     -- Daniel

You might consider using this workaround: 
http://www.mindview.net/Etc/Discussions/CheckedExceptions for checked 
exceptions, it is a little bit nicer.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

renoX <renosky free.fr> writes:

As often, it is a matter of 'easy to write' vs 'easy to read'.

Myself, I wonder why we don't use more often function call like this: 
f(x=1,y=2) instead of f(1,2): this would reduce the number of mistakes 
in the assignment of values to parameters..

For the lazy function call, I think that instead of using f(lazy x++), 
it is better to use {} instead: f({x++}).

After all, this is what happens when you call a function with a lazy 
parameter: in fact you're passing a chunk of code.

Regards,
renoX