D dropped in favour of C# for PSP emulator

[Jonathan M Davis]

On Saturday, May 12, 2012 13:03:26 Manu wrote:
> On 12 May 2012 12:37, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:
> > > On 05/12/2012 10:13 AM, Manu wrote:
> > > > On 11 May 2012 21:28, Mehrdad <wfunction at hotmail.com
> > > > 
> > > > <mailto:wfunction at hotmail.com>> wrote:
> > > >     Yes, I agree, but consider that D users should NOT have to work
> > 
> > with
> > 
> > > >     pointers to do something so basic
> > > > 
> > > > I'd like to think this were true, but the fact that 'ref' barely works
> > > > makes this almost immediately false when trying to write any
> > 
> > non-trivial
> > 
> > > > program.
> > > 
> > > It depends on the coding style.
> > 
> > I rarely end up passing by either ref or pointer, and the only issues that
> > I've ever had with ref relate to the fact that you can't pass it rvalues.
> > Obviously both pointers and ref have their uses, but I'd definitely have
> > to
> > concur that it depends on your coding style and what you're doing. Also, I
> > really don't know what's wrong with ref such that anyone could say that it
> > "barely works" other than the issues with rvalues and functions which take
> > ref
> > or const ref.
> 
> struct X
> {
> int i;
> 
> X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); }
> ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return
> this; }
> ...etc
> }
> 
> ref X func(ref X x)
> {
> return x;
> }
> 
> bool maybe()
> {
> return (time() & 1) != 0;
> }
> 
> void test()
> {
> X a,b,c;
> X v[];
> 
> func(a); // this is basically the only expression that works
> X t = a + (b + c); // fail
> a += b + c; // fail
> ref X t = func(a); // fail
> func(a + b); // fail
> func(maybe() ? a : b); // this generates bad code:
> http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy@forum.dlang.org
> ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())];
> // fail
> 
> foreach(i; 0..10)
> {
> ref X t = v[some + expression * involving - i]; // fail
> }
> }
> 
> Just a couple of extremely common usage patterns that come to mind. I'm
> sure there are many more...

So, basically it's just the issue with neither ref nor const ref taking 
lvalues. If you duplicate the functions (or use auto ref if they're templated 
functions), then it's not an issue. It sucks to have to duplicate stuff, but 
ref works just fine as long as you don't assume that it's going to allow you to 
pass rvalues to it. Personally, I almost always just have functions take 
structs by value, so it's a non-issue except for stuff like opEquals, which 
requires const ref (for at least one overload anyway).

However, given the ridiculousness of having to duplicate functions to make ref 
usuable for any case where you're specifically trying to avoid a copy rather 
than use it to pass a value out, Andrei and Walter are looking at making ref 
work with rvalues. They just have to sort out how to avoid the issues that C++ 
has due to allow const& to take rvalues (which is why const ref in D doesn't 
currently take rvalues). So, there's a good chance that the situation will 
improve considerably sometime soon.

- Jonathan M Davis