On Sunday, 5 May 2013 at 02:04:14 UTC, Walter Bright wrote:
> That wasn't my understanding. I thought we agreed that since rvalues would be copied to locals, and then the issue was one of escaping local references.

I think you, Manu and I agreed on this simplification, and thus consequently left rvalues out of the discussion entirely. The others might not even have commented on this though.

David

On Sunday, 5 May 2013 at 01:45:05 UTC, Jonathan M Davis wrote:
> On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
>> On 5/4/13 7:31 PM, Walter Bright wrote:
>> > On 5/4/2013 3:51 PM, w0rp wrote:
>> >> Does all of this also mean that a
>> >> function with a ref parameter will automagically work with r-values?
>> > 
>> > Yes.
>> 
>> This is new to me. My understanding is that the discussed design
>> addresses safety, and leaves the rvalue discussion for a future iteration.
>
> That is definitely where things were when we ended the discussion on Wednesday
> night. Walter favored making ref accept rvalues, but we never agreed on that.
> Manu was still in favor of scop ref (and David Nadlinger agreed with him
> IIRC),

I was mostly arguing against Andrei's (in my opinion) overhasty dismissal of anything involving scope ref, because I didn't buy his argument about it being a drastic increase in perceived language complexity.

I fully agree with runtime-supported escape checking being the cleanest design, and like the fact that it is simple.

> and you and I were arguing for auto ref to designate that a function
> accepts rvalues. We all agreed on the bounds check solution for @safety, but
> we explicitly tabled the discussion about accepting rvalues, because it was
> getting late, and we'd already been discussing it / arguing about it for quite
> some time. So, unless further discussion occurred after that which I missed,
> there is still no agreement on how to handle having a parameter accept both
> lvalues and rvalues by ref.

I'd argue that if ref can safely accept rvalues, it should – simplicity at its best.

David

On 5/4/2013 7:36 PM, Jonathan M Davis wrote:
> The trick is balancing it so that it's powerful enough and yet not too
> complicated to be useable by normal programmers. I think that we're okay, but
> I also think that we're pushing it as it is. Going with Bartosz proposal would
> almost certainly have been too much.

Consider also that the appeal of dynamic languages is people don't have to annotate things with types.

On 5/4/13 10:33 PM, Walter Bright wrote:
> Please explain your understanding of what we agreed on.

Just the factual events. We all said repeatedly in the beginning of the discussion that "we focus only on the safety aspect for now and then figure the rvalue references thing". I've heard you say it at least two times clear as day. We can't now construe a solution to the safety matter into a solution to binding rvalues to ref.

I'll post separately about the issues involved with binding rvalues to references, but I'm retorting to this rather strongly because we must be clear, before getting into any level of detail, that we are not done with rvalues and ref.


Thanks,

Andrei

On 5/4/2013 10:15 PM, Andrei Alexandrescu wrote:
> On 5/4/13 10:33 PM, Walter Bright wrote:
>> Please explain your understanding of what we agreed on.
>
> Just the factual events. We all said repeatedly in the beginning of the
> discussion that "we focus only on the safety aspect for now and then figure the
> rvalue references thing". I've heard you say it at least two times clear as day.
> We can't now construe a solution to the safety matter into a solution to binding
> rvalues to ref.
>
> I'll post separately about the issues involved with binding rvalues to
> references, but I'm retorting to this rather strongly because we must be clear,
> before getting into any level of detail, that we are not done with rvalues and ref.

What I was talking about was the "no-op" thing with rvalue references, and yes, we deferred that.

On 5/4/2013 10:15 PM, Andrei Alexandrescu wrote:
> Just the factual events. We all said repeatedly in the beginning of the
> discussion that "we focus only on the safety aspect for now and then figure the
> rvalue references thing". I've heard you say it at least two times clear as day.
> We can't now construe a solution to the safety matter into a solution to binding
> rvalues to ref.

Yes, I should have entitled the thread that it was a solution to the safety issue. I agree that we deferred the 'nop' issue.

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

On Sunday, 5 May 2013 at 07:22:06 UTC, Jonathan M Davis wrote:
> 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

Assuming:
1. functioning attribute inference
2. attributes are expanded in the *.di file

Then, it would be trivial to create a tool which, upon request, merges "a defined set of attributes" back to the original d source file, this would reduce some of the burden and with full IDE integration even more so.

On 2013-05-04 20:33, Walter Bright wrote:

> These checks would be omitted if the -noboundscheck compiler switch was provided.

Perhaps a new flag for this.

-- 
/Jacob Carlborg

On Sunday, 5 May 2013 at 09:26:54 UTC, Jacob Carlborg wrote:
> On 2013-05-04 20:33, Walter Bright wrote:
>
>> These checks would be omitted if the -noboundscheck compiler switch was provided.
>
> Perhaps a new flag for this.

Or just rename it in more general -noruntimesafetychecks