Thread overview
out/inout/lazy at call site
Jan 04, 2007
Jakub Schmidtke
Jan 06, 2007
Daniel Keep
Jan 06, 2007
Bruno Medeiros
Jan 06, 2007
renoX
January 04, 2007
I started learning D language and I have a question - why doesn't it use 'out'
the way C# does?
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).

January 06, 2007
Jakub Schmidtke wrote:
> I started learning D language and I have a question - why doesn't it use 'out'
> the way C# does?
> 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.

On the other hand, when I had to use it in C#, it annoyed the crap out 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
January 06, 2007
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
January 06, 2007
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