Rvalue references - The resolution

Jonathan M Davis jmdavisProg at gmx.com
Sun May 5 00:21:49 PDT 2013


On Sunday, May 05, 2013 06:10:34 David Nadlinger wrote:
> On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
> > Don was complaining that one reason that moving
> > to D2 at Sociomantic looks unappealing in spite of the benefits
> > is the fact
> > that they're going to have to add so many extra annotations to
> > their code.
> 
> When did he mention that?

It was during dinner Friday night when he and Manu were discussing stuff in D 
that was problematic for companies like the ones that they work for. You were 
far enough down the table that you wouldn't have heard.

> If I had noticed, I would have been
> interested in a closer rationale, as D2's extra annotations are
> pretty much opt-in only, even more so if you are using your own
> library anyway.

True, they're opt-in, but it's also true that we generally consider it good 
style to use them as much as possible, which tends to mean using them all over 
the place - to the point that it starts seeming very odd that @safe and pure 
aren't the default, particularly when @system code is generally supposed to be 
the minority of your program, and very few functions should need to access 
global state. The two reasons that they don't get used way more in Phobos is 
because it uses templates so heavily, and because some basic stuff that gets 
used all over the place isn't pure yet even though it's supposed to be.

I'm sure that Don could answer about his concerns better than I could, but I 
think that it pretty much came down to the fact that D2 had a bunch of new 
attributes that they then had to worry about, many of which more or less only 
provide theoretical benefits which may or may not materialize at some point in 
the future.

For instance, optimizations with pure don't really happen all that often. 
There just aren't enough cases where the arguments are immutable (or 
implicitly convertible to immutable) for it to apply frequently, and IIRC, 
optimizations are only applied within the same statement, meaning that when 
they _are_ applied, they don't generally remove many function calls. The 
compiler doesn't even try and optimize across multiple lines within the same 
function (since that would require flow analysis) let alone memoize the result 
(which it probably shouldn't be doing anyway, since that would require storing 
the result somewhere, but it's the sort of thing that people often think of 
with pure).

Now, I argued that pure's primary benefit isn't really in optimizations but 
rather in the fact that it guarantees that your code isn't accessing global 
state, but there's still the general concern that there's a lot of new 
attributes to worry about, whether you choose to use them or not. I don't 
think that it was a deal-breaker for Don or anything like that, but it was one 
of his concerns and one more item on the list of things that makes it more 
costly for them to move to D2, even if it alone doesn't necessarily add a huge 
cost.

- Jonathan M Davis


More information about the Digitalmars-d mailing list