On 5/4/2013 4:03 PM, Andrej Mitrovic wrote:
> On 5/4/13, Walter Bright <newshound2@digitalmars.com> wrote:
>> Andrei & I argued that we needed to make it work with just ref annotations.
>
> So to recap, 2.063 turns slices into r-values which will break code
> that used ref, e.g.:
>
> -----
> void parse(ref int[] arr) { }
>
> void main()
> {
>      int[] arr = [1, 2];
>      parse(arr[]);  // ok in 2.062, error in 2.063
> }
> -----

Do you mean that is an error now with HEAD?


> Then the user might introduce a non-ref overload:
>
> -----
> void parse(ref int[] arr) { }
> void parse(int[] arr) { }  // picks this one
> -----
>
> And later down the road, maybe even in 2.064, ref will take r-values
> making the new code error because of ambiguity between the two
> functions.
>
> Has code breakage ever been taken into account during this dconf conversation?

I don't know of any code it would break.

On Saturday, 4 May 2013 at 23:31:39 UTC, 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 good, but not I'm a bit bitter with the whole code breakage of slice are rvalues that happened recently.

This is what I refers to when I complain about the way D is released. Both changes are super good, but we should have gotten both AT ONCE. And while the second isn't there, I should have none and still get bug fixes.

On 5/4/2013 4:34 PM, Walter Bright wrote:
>> And later down the road, maybe even in 2.064, ref will take r-values
>> making the new code error because of ambiguity between the two
>> functions.
>>
>> Has code breakage ever been taken into account during this dconf conversation?

I see what you mean now. You mean how does an rvalue overload if faced with T and ref T. Currently:

  void foo(ref int i);
  void foo(int i);

  void main() {
    int i;
    foo(i);    // matches ref int
    foo(1);    // matches int
  }

I don't think that should change with this proposal.

On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
> On 5/4/2013 4:34 PM, Walter Bright wrote:
>>> And later down the road, maybe even in 2.064, ref will take r-values
>>> making the new code error because of ambiguity between the two
>>> functions.
>>>
>>> Has code breakage ever been taken into account during this dconf conversation?
>
> I see what you mean now. You mean how does an rvalue overload if faced with T and ref T. Currently:
>
>   void foo(ref int i);
>   void foo(int i);
>
>   void main() {
>     int i;
>     foo(i);    // matches ref int
>     foo(1);    // matches int
>   }
>
> I don't think that should change with this proposal.

What about this:

void foo(ref int i);
void foo(ref const(int) i);

void main() {
    int i;
    foo(i);
    foo(1);
}

What do they match here?

On 05/05/2013 01:30 AM, Walter Bright wrote:
> On 5/4/2013 3:50 PM, deadalnix wrote:
>> Require isn't the right word, or you hav to explain yourself much more.
>
> You need an explicit annotation if a ref parameter is returned by ref by
> that function. This is what Rust's annotations do.
>
> Consider:
>
>      ref T foob(ref U u) { return u.t; }
>
>      ref U bar() { U u; return foob(u); }
>
> The compiler cannot know that the ref return of foob is referring to
> local u (as opposed to, say, a ref to a global) unless it is annotated
> to say so. Rust is no different.

What is the point? Rust conservatively assumes this by default.

On 5/4/2013 4:47 PM, Diggory wrote:
> What about this:
>
> void foo(ref int i);
> void foo(ref const(int) i);
>
> void main() {
>      int i;
>      foo(i);
>      foo(1);
> }
>
> What do they match here?

An rvalue ref is not const, so (1) would match the same as (i) does.

On 05/05/2013 01:47 AM, Diggory wrote:
> On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
>> On 5/4/2013 4:34 PM, Walter Bright wrote:
>>>> And later down the road, maybe even in 2.064, ref will take r-values
>>>> making the new code error because of ambiguity between the two
>>>> functions.
>>>>
>>>> Has code breakage ever been taken into account during this dconf
>>>> conversation?
>>
>> I see what you mean now. You mean how does an rvalue overload if faced
>> with T and ref T. Currently:
>>
>>   void foo(ref int i);
>>   void foo(int i);
>>
>>   void main() {
>>     int i;
>>     foo(i);    // matches ref int
>>     foo(1);    // matches int
>>   }
>>
>> I don't think that should change with this proposal.
>
> What about this:
>
> void foo(ref int i);
> void foo(ref const(int) i);
>
> void main() {
>      int i;
>      foo(i);
>      foo(1);
> }
>
> What do they match here?

Both match the first overload because that is an exact match whereas the second overload is only a match with conversion to const.

On 5/4/2013 4:36 PM, deadalnix wrote:
> This is good, but not I'm a bit bitter with the whole code breakage of slice are
> rvalues that happened recently.

I know that code breakage sux.

On Saturday, 4 May 2013 at 23:56:09 UTC, Walter Bright wrote:
> On 5/4/2013 4:36 PM, deadalnix wrote:
>> This is good, but not I'm a bit bitter with the whole code breakage of slice are
>> rvalues that happened recently.
>
> I know that code breakage sux.

And in this case, this was avoidable. We MUST get better at releasing versions of D.

On Saturday, 4 May 2013 at 23:30:01 UTC, Walter Bright wrote:
> On 5/4/2013 3:50 PM, deadalnix wrote:
>> Require isn't the right word, or you hav to explain yourself much more.
>
> You need an explicit annotation if a ref parameter is returned by ref by that function. This is what Rust's annotations do.
>
> Consider:
>
>     ref T foob(ref U u) { return u.t; }
>
>     ref U bar() { U u; return foob(u); }
>
> The compiler cannot know that the ref return of foob is referring to local u (as opposed to, say, a ref to a global) unless it is annotated to say so. Rust is no different.

This code sample won't require any annotation in Rust. And it illustrate wonderfully what I'm saying : most people in the discussion (and it has been shown now that this includes you) were unaware of how does Rust solve the problem.

I don't think excluding a solution that isn't understood is the smartest thing to do.